Subject: Re: [Capwap] CAPWAP and RFID

From: "Scott G. Kelly" <[email-masked]>
Date: Wed, 12 Jul 2006 13:59:09 -0700 (GMT-07:00)

Hi Margaret,

I agree that both goals you mention below are important.  I'll leave it to the chairs to respond to the notion of separating the 802.11 functionality into its own document, but I think clean separation is imperative if we are to support other bindings.

Scott

-----Original Message-----
>From: Margaret Wasserman <[email-masked]>
>Sent: Jul 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