Subject: Re: [Capwap] Proposed Resolution for Issue #201: Clean SeparationBetween Base and Binding/was Re: CAPWAP and RFID

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Thu, 31 Aug 2006 16:24:36 -0700

Works for me. Note that some of the references may be harder to make
when they occur across documents. Today they are simple to make, because
our xml2rfc allows for internal references, allowing us to reference a
specific section. In the new document, we will only be able to reference
the accompanying specification.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

________________________________

	From: Dorothy Stanley [mailto:[email-masked]] 
	Sent: Monday, August 28, 2006 9:37 AM
	To: Mani, Mahalingam (Mani)
	Cc: [email-masked]
	Subject: [Capwap] Proposed Resolution for Issue #201: Clean
SeparationBetween Base and Binding/was Re: CAPWAP and RFID

	All,
	 
	The proposed resolution for Issue #201, listed below is to
separate the
	specification of the CAPWAP base protocol and the
802.11-specific binding into two documents:
	(a) draft-ietf-capwap-protocol-specification and 
	(b) draft-ietf-capwap-wlan-binding-specification (or similar
name). 
	 
	This will 
	- enable easy reference to each component separately
	- ensure a clean separation between the protocol and the initial
802.11/subsequent bindings
	- provide focus on what is essential for the CAPWAP protocol vs
the bindings
	 
	If agreed, this coulld be accomplished In the next editing cycle
by producing
	draft-ietf-capwap-protocol-specification-03 and 
	draft-ietf-capwap-wlan-binding-specification-00
	 
	At a first cut, the binding specification document would include
-02 text:
	- Duplicated Section 1, with modifications to indicate that this
is the binding document, and reference the CAPWAP protocol spec
	- Section 11, with updates per issue resolution
	- Additional sections, per list agreement
	 
	Comments please.
	 
	Thanks,
	 
	Dorothy Stanley
	 
	Issue 201:
	 
	(2) Clean separation between CAPWAP "base" protocol and 802.11-
	specific control messages.  Ideally, we'd like to see the CAPWAP
base
	protocol and the 802.11-specific controls in separate documents,
but 
	it would also be possible for us to reference a portion of a
	monolithic document, as long as the base protocol is
cleanly-enough 
	separated from the 802.11-specific portions to allow us to
	unambiguously and normatively reference the base protocol. 

	 
	On 7/14/06, Dorothy Stanley <[email-masked]> wrote: 

		All,
		
		Issues 
		
		#200 - Trickle Firmware Download
		#201 - Clean Separation between base and binding
		
		are now created in the issue database to track these
items.

		Dorothy Stanley

		On 7/13/06, Mani, Mahalingam (Mani) <[email-masked] >
wrote: 

			<!chair>
			The WG should consider The #1 as a bug-level
issue given that there will
			be usage models and applications that require
scheduling of firmware
			updates (provisioning/lifecycle management
action) separated from reboot 
			(operational management action) to switch to the
new firmware.
			
			Requiring reboot to be synchronous with a
firmware update is 
			restrictive.
			
			Above may have implications of having room in
stable-store for at least 
			two images (a best practice followed by all
well-designed embedded
			systems anyway) - hopefully a non-issue nowadays
even on thin WTPs. 
			</!chair>
			
			The second request is on first providing logical
separation more than 
			physically separate documents, as I read it. The
WG & editors have done
			a good job on that beginning with the base
protocol. 
			
			The persuasion to consider the physically split
the document becomes
			more appealing when an additional media binding
becomes a reality. The 
			latter needs to be preceded by a re-charter at
the minimum, as I
			understand it, given the current charter. (One
of the charter goals has
			been extensibility, however).
			
			Any inputs towards improving logical separation
is welcome; and the WG 
			and editors can make a choice on adopting them
based on issue-priorities 
			in queue. That could serve us well now and for a
physical separation at
			a later time (whenever it may be).
			
			Thanks,
			-mani
			-----Original Message----- 
			From: Margaret Wasserman [mailto:
[email-masked] <mailto:[email-masked]> ]
			Sent: Wednesday, July 12, 2006 11:44 AM
			To: [email-masked]
			Subject: [Capwap] CAPWAP and RFID 

			Hi All,
			
			For background on why I'm raising the next few
issues, please see the
			slides (in the proceedings for IETF 66) that I
did not get a chance
			to present in the WG meeting.  The primary point
of those slides was 
			that the Reader Operations WG of the EPCglobal
standards body (an
			RFID industry standards body) is considering
reusing the base
			protocol portions of CAPWAP as a discovery and
control protocol for
			RFID systems.  Bob O'Hara and I are both active
in that group, and 
			we've been asked to communicate some
requirements from that group to
			the CAPWAP WG.
			
			NOTE:  We are not talking about adding
RFID-specific control messages
			to CAPWAP.  In fact, the group is not currently
planning to use 
			CAPWAP as the control channel.  So, these are
not RFID-specific
			requirements.
			
			In our scenario, an RFID controller (or
"client") would act in the
			role of a WTP, and RFID readers would act in the
AP role. 
			
			The two requirements we've been asked to
communicate are:
			
			(1) Trickle firmware download with separate
reboot.  In other words,
			we need to be able to download the firmware
while our CAPWAP
			connection remains in the running state, and
later be able to trigger 
			a reboot, which will result in a switch to the
new firmware.  It
			seems very likely that some 802.11 systems will
require this feature,
			as well.  In fact, it is my understanding that
some systems already
			do it this way.  But, the current state diagram
and CAPWAP text don't 
			seem to support this -- you leave the running
state to move to the
			firmware download state and can only exit the
firmware download state
			through the reboot state.
			
			(2) Clean separation between CAPWAP "base"
protocol and 802.11-
			specific control messages.  Ideally, we'd like
to see the CAPWAP base
			protocol and the 802.11-specific controls in
separate documents, but
			it would also be possible for us to reference a
portion of a
			monolithic document, as long as the base
protocol is cleanly-enough 
			separated from the 802.11-specific portions to
allow us to
			unambiguously and normatively reference the base
protocol.
			
			Would the CAPWAP WG support making these changes
so that the
			EPCglobal RO WG can reuse this technology? 
			
			Thanks,
			Margaret
			
			Margaret Wasserman
			Vice President
			ThingMagic
			[email-masked] 
	
_________________________________________________________________ 
			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