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

From: "Saravanan Govindan" <[email-masked]>
Date: Mon, 4 Sep 2006 09:45:45 +0800

I have concerns with this proposal. In principle, I support the
proposal. However, in practice, I think we should wait until all the
technical issues are sorted out before making the split. I am concerned
that separating the documents at this relatively early stage may
complicate technical resolution. Furthermore, splitting the document
seems to be an editorial issue, which can be best done after content has
been finalized. 

So I support the proposal but would like it to be pursued after content
has been finalized.

Saravanan

 

________________________________

From: Pat Calhoun (pacalhou) [mailto:[email-masked]] 
Sent: Friday, September 01, 2006 7:25 AM
To: Dorothy Stanley; Mani, Mahalingam (Mani)
Cc: [email-masked]
Subject: Re: [Capwap] Proposed Resolution for Issue #201:
CleanSeparationBetween Base and Binding/was Re: CAPWAP and RFID

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