Wireless LAN Control Protocol (WiCoP)
draft-iino-capwap-wicop-02

[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 WiCoP 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 WiCoP 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 WiCoP 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 WiCoP 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'd like to see whether these documents ought to be delayed at least, and consider if this is reasonably in line with previous agreements made with the WG.

[Ballot discuss]
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.

My review of this document was light, and I don't have any specific complaints to list here. It does seem to have a smaller scope than the other capwap specifications on the telechat this week (which probably helps, though it clearly remains incomplete).

[Ballot comment]
If this is going to be published I do really expect that there are a strong note that says that this our only an outline to a protocol and can't be implemented or used in its current form.

This protocol doesn't seem to discuss how the messages actually are transported between the entities. The rate control of messages seems to be underspecified part. At least exponential back off of any retransmissions exist. But MTU, RTT measurements, and other functions may be of importance if the messages are transported over for example UDP or raw IP.

[Ballot discuss]
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.

My review of this document was light, and I don't have any specific complaints to list here. It does seem to have a smaller scope than the other capwap specifications on the telechat this week (which probably helps).

[Ballot discuss]
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.

My review of this document was light, and I don't have any specific complaints to list here.

IANA Evaluation Comments:

This document does not contain IANA considerations section.

This docment defines a new packet format and number of
fields  that seem to require a registry as future
expansion seems to  be allowed. (version field)

The document is has no policy statements about allocation
polices in the registries.

Before this document is advanced the open issues below
marked by XXX must be addressed:

The actions IANA has determined are the following:

Action #1:
Upon approval of this document, the IANA will create the
following
registry "WiCoP Paramters Registry " located at
http://www.iana.org/assignments/TBD
Initial contents of this registry will be:


WiCoP Packet format [RFC-iino-capwap-wicop-02]
0 31
| 7 15 23 |
|-------|-------|-------|-------|-------|-------|-------|-------|
| Version |M|D|C|R|E|F|L| | Reserve |
+---------------+-+-+-+-+-+-+-+-+-------------------------------+
| Fragment ID | Fragment No. | Length |
+---------------+---------------+-------------------------------+


Action #2:
Upon approval of this document, the IANA will in the
following registry WiCoP Paramters Registry " located at

http://www.iana.org/assignments/TBD

create a new sub-registry "WiCoP versions"
Initial contents of this registry will be:

Registry allocaion policy is XXX !!!!

0 Initial version [RFC-iino-capwap-wicop-02]
1-255 Avaliable for assignment XXX

Action #3:
Upon approval of this document, the IANA will in the
following registry WiCoP Paramters Registry " located at

http://www.iana.org/assignments/TBD

create a new sub-registry "WiCoP Flags"
The flags field is 3 octets long. XXX ???

Registry allocaion policy is XXX !!!!

XXX do flags change between versions ???

Initial contents of this registry will be:

bit Id Name Reference
0 M  [RFC-iino-capwap-wicop-02]
1 D  [RFC-iino-capwap-wicop-02]
2 C Control/Data [RFC-iino-capwap-wicop-02]
3 R Retransmission [RFC-iino-capwap-wicop-02]
4 E Encrypted
5 F Fragment
6 L Last Fragment
7-23 avaialable for assignment XXX

Action #4:
Upon approval of this document, the IANA will in the
following registry WiCoP Paramters Registry " located at

http://www.iana.org/assignments/TBD
create a new sub-registry "WiCoP Control Packet Message
Types"


Registry allocaion policy is XXX !!!!

Val Name Ref
0 Reserved XXX ???? [RFC-iino-capwap-wicop-02]
1 Capabilities [RFC-iino-capwap-wicop-02]
2 Capabilities Response [RFC-iino-capwap-wicop-02]
3 Connection [RFC-iino-capwap-wicop-02]
4 Connection Response [RFC-iino-capwap-wicop-02]
5 Configuration Request [RFC-iino-capwap-wicop-02]
6 Configuration Response [RFC-iino-capwap-wicop-02]
7 Configuration Data [RFC-iino-capwap-wicop-02]
8 Configuration Data Response [RFC-iino-capwap-wicop-02]
9 Configuration Trigger [RFC-iino-capwap-wicop-02]
10 Configuration Trigger Response [RFC-iino-capwap-wicop-02]
11 Feedback [RFC-iino-capwap-wicop-02]
12 Feedback Response [RFC-iino-capwap-wicop-02]
13 Reset [RFC-iino-capwap-wicop-02]
14 Reset Response [RFC-iino-capwap-wicop-02]
15 Firmware Download [RFC-iino-capwap-wicop-02]
16 Firmware Download Response [RFC-iino-capwap-wicop-02]
17 Terminal Addition [RFC-iino-capwap-wicop-02]
18 Terminal Addition Response [RFC-iino-capwap-wicop-02]
19 Terminal Deletion [RFC-iino-capwap-wicop-02]
20 Terminal Deletion Response [RFC-iino-capwap-wicop-02]
21 Key Configuration [RFC-iino-capwap-wicop-02]
22 Key Configuration Response [RFC-iino-capwap-wicop-02]
23 Notification [RFC-iino-capwap-wicop-02]
24 Notification Response [RFC-iino-capwap-wicop-02]
25-255 Available for assignment



Action #5

Upon approval of this document, the IANA will in the
following registry WiCoP Paramters Registry " located at

http://www.iana.org/assignments/TBD
create a new sub-registry "WiCoP Data Packet Message Types"

Registry allocaion policy is XXX !!!!




Action #6
Upon approval of this document, the IANA will in the
following registry WiCoP Paramters Registry " located at

http://www.iana.org/assignments/TBD
create a new sub-registry "WiCoP Message Elements"


Registry allocaion policy is XXX !!!!

Initial Contents:
val name reference
0 Reserved [RFC-iino-capwap-wicop-02]
1 WTP-Info [RFC-iino-capwap-wicop-02]
2 Cap-from-WTP [RFC-iino-capwap-wicop-02]
3 Conf-If-WTP [RFC-iino-capwap-wicop-02]
4 Conf-WTP-Data [RFC-iino-capwap-wicop-02]
5 Cap-to_WTP [RFC-iino-capwap-wicop-02]
6 QoS-Value [RFC-iino-capwap-wicop-02]
7 Timer-Init-Value [RFC-iino-capwap-wicop-02]
8 Terminal-Data
9 BSSID [RFC-iino-capwap-wicop-02]
10 Encryption-Data [RFC-iino-capwap-wicop-02]
11 EAP-Frame [RFC-iino-capwap-wicop-02]
12 Statistics [RFC-iino-capwap-wicop-02]
13 Interface-Error [RFC-iino-capwap-wicop-02]
14 FROM-Error [RFC-iino-capwap-wicop-02]
15 QoS-Capability [RFC-iino-capwap-wicop-02]
16 TFTP-Data [RFC-iino-capwap-wicop-02]
17 Result [RFC-iino-capwap-wicop-02]
18 OID [RFC-iino-capwap-wicop-02]
19 GTK-Flag [RFC-iino-capwap-wicop-02]
20-255 Available for Assignemnt XXX


We understand the above to be the only IANA Action for
this document.

IANA Evaluation Comments:

This document does not contain IANA considerations
section.

This docment defines a new packet format and number of
fields that seem to require a registry as future expansion
seems to be allowed.
(version field)

The document is has no policy statements about allocation
polices in the registries.

Before this document is advanced the open issues below
marked by XXX must be addressed:

The actions IANA has determined are the following:

Action #1:
Upon approval of this document, the IANA will create
the following registry "WiCoP Paramters Registry "
located at

http://www.iana.org/assignments/TBD

Initial contents of this registry will be:


WiCoP Packet format [RFC-iino-capwap-wicop-02]
0 31
| 7 15 23 |
|-------|-------|-------|-------|-------|-------|-------|-------|
| Version |M|D|C|R|E|F|L| | Reserve |
+---------------+-+-+-+-+-+-+-+-+-------------------------------+
| Fragment ID | Fragment No. | Length |
+---------------+---------------+-------------------------------+


Action #2:
Upon approval of this document, the IANA will in
the following registry WiCoP Paramters Registry "
located at

http://www.iana.org/assignments/TBD

create a new sub-registry "WiCoP versions"

Initial contents of this registry will be:

Registry allocaion policy is XXX !!!!

0 Initial version [RFC-iino-capwap-wicop-02]
1-255 Avaliable for assignment XXX

Action #3:
Upon approval of this document, the IANA will in
the following registry WiCoP Paramters Registry "
located at

http://www.iana.org/assignments/TBD

create a new sub-registry "WiCoP Flags"

The flags field is 3 octets long. XXX ???

Registry allocaion policy is XXX !!!!

XXX do flags change between versions ???

Initial contents of this registry will be:

bit Id Name Reference
0 M  [RFC-iino-capwap-wicop-02]
1 D  [RFC-iino-capwap-wicop-02]
2 C Control/Data [RFC-iino-capwap-wicop-02]
3 R Retransmission [RFC-iino-capwap-wicop-02]
4 E Encrypted
5 F Fragment
6 L Last Fragment
7-23 avaialable for assignment XXX

Action #4:
Upon approval of this document, the IANA will in
the following registry WiCoP Paramters Registry "
located at

http://www.iana.org/assignments/TBD

create a new sub-registry "WiCoP Control Packet
Message Types"


Registry allocaion policy is XXX !!!!

Val Name Ref
0 Reserved XXX ???? [RFC-iino-capwap-wicop-02]
1 Capabilities [RFC-iino-capwap-wicop-02]
2 Capabilities Response [RFC-iino-capwap-wicop-02]
3 Connection [RFC-iino-capwap-wicop-02]
4 Connection Response [RFC-iino-capwap-wicop-02]
5 Configuration Request [RFC-iino-capwap-wicop-02]
6 Configuration Response [RFC-iino-capwap-wicop-02]
7 Configuration Data [RFC-iino-capwap-wicop-02]
8 Configuration Data Response [RFC-iino-capwap-wicop-02]
9 Configuration Trigger [RFC-iino-capwap-wicop-02]
10 Configuration Trigger Response [RFC-iino-capwap-wicop-02]
11 Feedback [RFC-iino-capwap-wicop-02]
12 Feedback Response [RFC-iino-capwap-wicop-02]
13 Reset [RFC-iino-capwap-wicop-02]
14 Reset Response [RFC-iino-capwap-wicop-02]
15 Firmware Download [RFC-iino-capwap-wicop-02]
16 Firmware Download Response [RFC-iino-capwap-wicop-02]
17 Terminal Addition [RFC-iino-capwap-wicop-02]
18 Terminal Addition Response [RFC-iino-capwap-wicop-02]
19 Terminal Deletion [RFC-iino-capwap-wicop-02]
20 Terminal Deletion Response [RFC-iino-capwap-wicop-02]
21 Key Configuration [RFC-iino-capwap-wicop-02]
22 Key Configuration Response [RFC-iino-capwap-wicop-02]
23 Notification [RFC-iino-capwap-wicop-02]
24 Notification Response [RFC-iino-capwap-wicop-02]
25-255 Available for assignment

Action #5

Upon approval of this document, the IANA will in the
following registry WiCoP Paramters Registry "
located at

http://www.iana.org/assignments/TBD

create a new sub-registry "WiCoP Data Packet Message Types"

Registry allocaion policy is XXX !!!!




Action #6
Upon approval of this document, the IANA will in
the following registry WiCoP Paramters Registry "
located at

http://www.iana.org/assignments/TBD

create a new sub-registry "WiCoP Message Elements"


Registry allocaion policy is XXX !!!!

Initial Contents:
val name reference
0 Reserved [RFC-iino-capwap-wicop-02]
1 WTP-Info [RFC-iino-capwap-wicop-02]
2 Cap-from-WTP [RFC-iino-capwap-wicop-02]
3 Conf-If-WTP [RFC-iino-capwap-wicop-02]
4 Conf-WTP-Data [RFC-iino-capwap-wicop-02]
5 Cap-to_WTP [RFC-iino-capwap-wicop-02]
6 QoS-Value [RFC-iino-capwap-wicop-02]
7 Timer-Init-Value [RFC-iino-capwap-wicop-02]
8 Terminal-Data
9 BSSID [RFC-iino-capwap-wicop-02]
10 Encryption-Data [RFC-iino-capwap-wicop-02]
11 EAP-Frame [RFC-iino-capwap-wicop-02]
12 Statistics [RFC-iino-capwap-wicop-02]
13 Interface-Error [RFC-iino-capwap-wicop-02]
14 FROM-Error [RFC-iino-capwap-wicop-02]
15 QoS-Capability [RFC-iino-capwap-wicop-02]
16 TFTP-Data [RFC-iino-capwap-wicop-02]
17 Result [RFC-iino-capwap-wicop-02]
18 OID [RFC-iino-capwap-wicop-02]
19 GTK-Flag [RFC-iino-capwap-wicop-02]
20-255 Available for Assignemnt XXX


We understand the above to be the only IANA Action
for this document.

[Ballot discuss]
This is a discuss discuss: As I read the IESG note, a standards track protocol is forthcoming for capwap.  Publication of the wicop 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?

IANA Evaluation Comments:

This document does not contain IANA considerations
section.

This docment defines a new packet format and number of
fields that seem to require a registry as future expansion
seems to be allowed.
(version field)

The document is has no policy statements about allocation
polices in the registries.

Before this document is advanced the open issues below
marked by XXX must be addressed:

The actions IANA has determined are the following:

Action #1:
Upon approval of this document, the IANA will create
the following registry "WiCoP Paramters Registry "
located at

http://www.iana.org/assignments/TBD

Initial contents of this registry will be:


WiCoP Packet format [RFC-iino-capwap-wicop-02]
0 31
| 7 15 23 |
|-------|-------|-------|-------|-------|-------|-------|-------|
| Version |M|D|C|R|E|F|L| | Reserve |
+---------------+-+-+-+-+-+-+-+-+-------------------------------+
| Fragment ID | Fragment No. | Length |
+---------------+---------------+-------------------------------+


Action #2:
Upon approval of this document, the IANA will in
the following registry WiCoP Paramters Registry "
located at

http://www.iana.org/assignments/TBD

create a new sub-registry "WiCoP versions"

Initial contents of this registry will be:

Registry allocaion policy is XXX !!!!

0 Initial version [RFC-iino-capwap-wicop-02]
1-255 Avaliable for assignment XXX

Action #3:
Upon approval of this document, the IANA will in
the following registry WiCoP Paramters Registry "
located at

http://www.iana.org/assignments/TBD

create a new sub-registry "WiCoP Flags"

The flags field is 3 octets long. XXX ???

Registry allocaion policy is XXX !!!!

XXX do flags change between versions ???

Initial contents of this registry will be:

bit Id Name Reference
0 M  [RFC-iino-capwap-wicop-02]
1 D  [RFC-iino-capwap-wicop-02]
2 C Control/Data [RFC-iino-capwap-wicop-02]
3 R Retransmission [RFC-iino-capwap-wicop-02]
4 E Encrypted
5 F Fragment
6 L Last Fragment
7-23 avaialable for assignment XXX

Action #4:
Upon approval of this document, the IANA will in
the following registry WiCoP Paramters Registry "
located at

http://www.iana.org/assignments/TBD

create a new sub-registry "WiCoP Control Packet
Message Types"


Registry allocaion policy is XXX !!!!

Val Name Ref
0 Reserved XXX ???? [RFC-iino-capwap-wicop-02]
1 Capabilities [RFC-iino-capwap-wicop-02]
2 Capabilities Response [RFC-iino-capwap-wicop-02]
3 Connection [RFC-iino-capwap-wicop-02]
4 Connection Response [RFC-iino-capwap-wicop-02]
5 Configuration Request [RFC-iino-capwap-wicop-02]
6 Configuration Response [RFC-iino-capwap-wicop-02]
7 Configuration Data [RFC-iino-capwap-wicop-02]
8 Configuration Data Response [RFC-iino-capwap-wicop-02]
9 Configuration Trigger [RFC-iino-capwap-wicop-02]
10 Configuration Trigger Response [RFC-iino-capwap-wicop-02]
11 Feedback [RFC-iino-capwap-wicop-02]
12 Feedback Response [RFC-iino-capwap-wicop-02]
13 Reset [RFC-iino-capwap-wicop-02]
14 Reset Response [RFC-iino-capwap-wicop-02]
15 Firmware Download [RFC-iino-capwap-wicop-02]
16 Firmware Download Response [RFC-iino-capwap-wicop-02]
17 Terminal Addition [RFC-iino-capwap-wicop-02]
18 Terminal Addition Response [RFC-iino-capwap-wicop-02]
19 Terminal Deletion [RFC-iino-capwap-wicop-02]
20 Terminal Deletion Response [RFC-iino-capwap-wicop-02]
21 Key Configuration [RFC-iino-capwap-wicop-02]
22 Key Configuration Response [RFC-iino-capwap-wicop-02]
23 Notification [RFC-iino-capwap-wicop-02]
24 Notification Response [RFC-iino-capwap-wicop-02]
25-255 Available for assignment

Action #5

Upon approval of this document, the IANA will in the
following registry WiCoP Paramters Registry "
located at

http://www.iana.org/assignments/TBD

create a new sub-registry "WiCoP Data Packet Message Types"

Registry allocaion policy is XXX !!!!




Action #6
Upon approval of this document, the IANA will in
the following registry WiCoP Paramters Registry "
located at

http://www.iana.org/assignments/TBD

create a new sub-registry "WiCoP Message Elements"


Registry allocaion policy is XXX !!!!

Initial Contents:
val name reference
0 Reserved [RFC-iino-capwap-wicop-02]
1 WTP-Info [RFC-iino-capwap-wicop-02]
2 Cap-from-WTP [RFC-iino-capwap-wicop-02]
3 Conf-If-WTP [RFC-iino-capwap-wicop-02]
4 Conf-WTP-Data [RFC-iino-capwap-wicop-02]
5 Cap-to_WTP [RFC-iino-capwap-wicop-02]
6 QoS-Value [RFC-iino-capwap-wicop-02]
7 Timer-Init-Value [RFC-iino-capwap-wicop-02]
8 Terminal-Data
9 BSSID [RFC-iino-capwap-wicop-02]
10 Encryption-Data [RFC-iino-capwap-wicop-02]
11 EAP-Frame [RFC-iino-capwap-wicop-02]
12 Statistics [RFC-iino-capwap-wicop-02]
13 Interface-Error [RFC-iino-capwap-wicop-02]
14 FROM-Error [RFC-iino-capwap-wicop-02]
15 QoS-Capability [RFC-iino-capwap-wicop-02]
16 TFTP-Data [RFC-iino-capwap-wicop-02]
17 Result [RFC-iino-capwap-wicop-02]
18 OID [RFC-iino-capwap-wicop-02]
19 GTK-Flag [RFC-iino-capwap-wicop-02]
20-255 Available for Assignemnt XXX


We understand the above to be the only IANA Action
for this document.

[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 WiCoP 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 Yoshiko Chong

[Ballot discuss]
This is a discuss discuss: As I read the IESG note, a standards track protocol is forthcoming for capwap.  Publication of the wicop 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 WiCoP 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 WiCoP 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