Received changes through RFC Editor sync (changed abstract to 'In recent years, there has been a shift in wireless LAN (WLAN) product architectures from autonomous access points to centralized control of lightweight access points. The general goal has been to move most of the traditional wireless functionality such as access control (user authentication and authorization), mobility, and radio management out of the access point into a centralized controller.

The IETF's CAPWAP (Control and Provisioning of Wireless Access Points) WG has identified that a standards-based protocol is necessary between a wireless Access Controller and Wireless Termination Points (the latter are also commonly referred to as Lightweight Access Points). This specification defines the Lightweight Access Point Protocol (LWAPP), which addresses the CAPWAP's (Control and Provisioning of Wireless Access Points) protocol requirements. Although the LWAPP protocol is designed to be flexible enough to be used for a variety of wireless technologies, this specific document describes the base protocol and an extension that allows it to be used with the IEEE's 802.11 wireless LAN protocol. This document defines a Historic Document for the Internet community.')

[Note]: 'This document is an independent submission via the RFC Editor.  In conformance with RFC 3932, Section 4, the IESG requests the
  publication of the following note:  "This RFC documents the LWAPP protocol as it was when submitted to
  the IETF as a basis for further work in the CAPWAP WG, and therefore
  it may resemble the CAPWAP protocol specification (RFC XXXX), as well
  as other current IETF work in progress or published IETF work.
  This RFC is being published solely for the historical record. The  protocol described in this RFC has not been thoroughly reviewed and may
  contain errors and omissions.  RFC XXXX documents the standards track solution for the CAPWAP
  Working Group and obsoletes any and all mechanisms defined in this RFC.
  This RFC itself is not a candidate for any level of Internet  Standard and should not be used as a basis for any sort of deployment  in the Internet.  The IETF disclaims any knowledge of the fitness of this
  RFC for any purpose, and in particular notes that it has not had
  complete IETF review for such things as security, congestion control,
  or inappropriate interaction with deployed protocols.  The RFC Editor
  has chosen to publish this document at its discretion."' added by Amy Vezza

[Note]: 'This document is an independent submission via the RFC Editor.  In conformance with RFC 3932, Section 4, the IESG requests the
  publication of the following note:  "This RFC documents the LWAPP protocol as it was when submitted to
  the IETF as a basis for further work in the CAPWAP WG, and therefore
  it may resemble the CAPWAP protocol specification (RFC XXXX), as well
  as other current IETF work in progress or published IETF work.
  This RFC is being published solely for the historical record. The  protocol described in this RFC has not been thoroughly reviewed and may
  contain errors and omissions.  RFC XXXX documents the standards track solution for the CAPWAP
  Working Group and obsoletes any and all mechanisms defined in this RFC.
  This RFC itself is not a candidate for any level of Internet  Standard and should not be used as a basis for any sort of deployment  in the Internet.  The IETF disclaims any knowledge of the fitness of this
  RFC for any purpose, and in particular notes that it has not had
  complete IETF review for such things as security, congestion control,
  or inappropriate interaction with deployed protocols.  The RFC Editor
  has chosen to publish this document at its discretion."' added by Amy Vezza

[Note]: 'This document is an independent submission via the RFC Editor.  In conformance with RFC 3932, Section 4, the IESG requests the
  publication of the following note:   "This RFC documents the LWAPP protocol as it was when submitted to
  the IETF as a basis for further work in the CAPWAP WG, and therefore
  it may resemble the CAPWAP protocol specification (RFC XXXX), as well
  as other current IETF work in progress or published IETF work.
  This RFC is being published solely for the historical record. The   protocol described in this RFC has not been thoroughly reviewed and may
  contain errors and omissions.   RFC XXXX documents the standards track solution for the CAPWAP
  Working Group and obsoletes any and all mechanisms defined in this RFC.
  This RFC itself is not a candidate for any level of Internet   Standard and should not be used as a basis for any sort of deployment   in the Internet.   The IETF disclaims any knowledge of the fitness of this
  RFC for any purpose, and in particular notes that it has not had
  complete IETF review for such things as security, congestion control,
  or inappropriate interaction with deployed protocols.  The RFC Editor
  has chosen to publish this document at its discretion."' added by Amy Vezza

[Note]: 'This document is an independent submission via the RFC Editor.   In conformance with RFC 3932, Section 4, the IESG requests the
  publication of the following note:

  "This RFC documents the LWAPP protocol as it was when submitted to
  the IETF as a basis for further work in the CAPWAP WG, and therefore
  it may resemble the CAPWAP protocol specification (RFC XXXX), as well
  as other current IETF work in progress or published IETF work.
  This RFC is being published solely for the historical record. The
  protocol described in this RFC has not been thoroughly reviewed and may
  contain errors and omissions.

  RFC XXXX documents the standards track solution for the CAPWAP
  Working Group and obsoletes any and all mechanisms defined in this RFC.
  This RFC itself is not a candidate for any level of Internet
  Standard and should not be used as a basis for any sort of deployment
  in the Internet.

  The IETF disclaims any knowledge of the fitness of this
  RFC for any purpose, and in particular notes that it has not had
  complete IETF review for such things as security, congestion control,
  or inappropriate interaction with deployed protocols.  The RFC Editor
  has chosen to publish this document at its discretion."

' added by Dan Romascanu

[Ballot discuss]
I believe this document is clearly overlapping with capwap, and could be harmful to the work done there, at least meriting option 3 from section 3 of RFC3932:

  3. The IESG thinks that publication is harmful to the IETF work done
      in WG capwap and recommends not publishing the document at this time.

I understand that there is precedent for publication of overlapping input into the standards process (IPFIX was identified) but remain unconvinced. There is plenty of other precedent showing that overlapping independent work is delayed until standards track work is finished, and is a significant part of the spirit of the IESG review procedures instilled in RFC 3932.

This is a long document, and seems complete in its specification. I don't have any specific technical compliants beyond the lack of detail associated with the use of DHCP Option 43 and DNS for discovery. If the "LWAPP-AC-Address" referred to in the one sentence devoted to DNS Discovery is a "Magic Name" this could be harmful and should either be clarified or removed from the document.

[Ballot discuss]
I believe this document is clearly overlapping with capwap, and could be harmful to the work done there, at least meriting option 3 from section 3 of RFC3932:

  3. The IESG thinks that publication is harmful to the IETF work done
      in WG capwap and recommends not publishing the document at this time.

I understand that there is precedent for publication of overlapping input into the standards process (IPFIX was identified) but remain unconvinced. There is plenty of other precedent showing that overlapping independent work is delayed until standards track work is finished, and is a significant part of the spirit of the IESG review procedures instilled in RFC 3932.

This is a long document, and seems complete in its specification. I don't have any specific technical compliants beyond the lack of detail associated with the use of DHCP Option 43 and DNS for discovery.

IANA Evaluation Comments:


IANA considerations section says no actions but the document is
full of definitions.

There is a new packet format defined, with a version field and
number of flags, type field etc.

In section 4.2.2 it says the the "Message Type field" is managed
by IANA the initial contents of that registry seems to be in
section 4.2.1.1 but it says nothing about allocation polices for
new values.

Section 5, 6, 7, 8, 9, 11 are defining messages (or message use)
it is not clear if they are reusing some IEEE 802.? meesages or
defining new ones.


IANA would like you to rewrite the IANA considerations section
to reflect the document as required by the Proto guide.

The document says nothing about if/how header changes with versions
nor the policy for defining new versions.

[Ballot discuss]
This is a discuss discuss: As I read the IESG note, a standards track protocol is forthcoming for capwap.  Publication of the lwapp specification as "Informational" may cause confusion, particularly since the standards track protocol is still under development.  (1) Wouldn't it be better to progress this specification as "Historic"? (2) Should we delay publication of this spec until the standards track protocol is published?

[Note]: 'This document is an independent submission via the RFC Editor. In conformace with RFC 3932, Section 4, the IESG requests the publication of the following note: "This RFC documents the LWAPP protocol as it was when submitted to the IETF as a basis for further work in the CAPWAP WG, and therefore it may resemble a current IETF work in progress or a published IETF work. This RFC itself is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose, and in particular notes that it has not had complete IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion."' added by Dan Romascanu

[Note]: 'This document is an independent submission via the RFC Editor. In conformace with RFC 3932, Section 4, the IESG requests the publication of the following note:

   "This RFC documents the LWAPP protocol as it was when submitted to the
   IETF as a basis for further work in the CAPWAP WG, and therefore it
   may resemble a current IETF work in progress or a published IETF work.

   This RFC itself is not a candidate for any level of Internet
   Standard.  The IETF disclaims any knowledge of the fitness of this
   RFC for any purpose, and in particular notes that it has not had
   complete IETF review for such things as security, congestion control,
   or inappropriate interaction with deployed protocols.  The RFC Editor
   has chosen to publish this document at its discretion."

' added by Dan Romascanu