Subject: Re: [Capwap] CAPWAP and RFID

From: "Mani, Mahalingam (Mani)" <[email-masked]>
Date: Thu, 13 Jul 2006 14:30:59 -0600

<!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]] 
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

---

From: "Dorothy Stanley" <[email-masked]>
Date: Fri, 14 Jul 2006 08:29:29 -0700

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