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

From: "James Kempf" <[email-masked]>
Date: Mon, 28 Aug 2006 10:13:35 -0700

I support this change. Though it is not so important, I would suggest 
calling the 802.11 binding something like 
draft-ietf-capwap-protocol-802dot11-binding.txt.

            jak

----- Original Message ----- 
From: "Dorothy Stanley" <[email-masked]>
To: "Mani, Mahalingam (Mani)" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, August 28, 2006 9:36 AM
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]]
>> > 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 

_________________________________________________________________
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: Mon, 28 Aug 2006 09:36:51 -0700

All,

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

Comments please.

Thanks,

Dorothy Stanley

Issue 201:

On 7/14/06, Dorothy Stanley <[email-masked]> wrote:
> > The WG should consider The #1 as a bug-level issue given that there will
> > updates (provisioning/lifecycle management action) separated from reboot
> >
> > and editors can make a choice on adopting them based on issue-priorities