Alternate Tunnel Encapsulation for Data Frames in Control and Provisioning of Wireless Access Points (CAPWAP)
draft-ietf-opsawg-capwap-alt-tunnel-12
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2018-04-20
|
12 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2018-04-09
|
12 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2018-03-22
|
12 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2018-02-08
|
12 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2018-02-08
|
12 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2018-02-08
|
12 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2018-01-30
|
12 | (System) | RFC Editor state changed to EDIT |
2018-01-30
|
12 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2018-01-30
|
12 | (System) | Announcement was received by RFC Editor |
2018-01-30
|
12 | (System) | IANA Action state changed to In Progress |
2018-01-30
|
12 | Cindy Morgan | IESG state changed to Approved-announcement sent from IESG Evaluation::AD Followup |
2018-01-30
|
12 | Cindy Morgan | IESG has approved the document |
2018-01-30
|
12 | Cindy Morgan | Closed "Approve" ballot |
2018-01-30
|
12 | Cindy Morgan | Ballot writeup was changed |
2018-01-30
|
12 | Cindy Morgan | Ballot approval text was generated |
2018-01-30
|
12 | Cindy Morgan | Ballot writeup was changed |
2018-01-29
|
12 | Suresh Krishnan | [Ballot comment] Thanks for addressing my DISCUSS. |
2018-01-29
|
12 | Suresh Krishnan | [Ballot Position Update] Position for Suresh Krishnan has been changed to No Objection from Discuss |
2018-01-29
|
12 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2018-01-29
|
12 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2018-01-29
|
12 | Zongpeng Du | New version available: draft-ietf-opsawg-capwap-alt-tunnel-12.txt |
2018-01-29
|
12 | (System) | New version approved |
2018-01-29
|
12 | (System) | Request for posting confirmation emailed to previous authors: Zongpeng Du , Sri Gundavelli , Rong Zhang , Rajesh Pazhyannur , Zhen Cao , DENG Hui |
2018-01-29
|
12 | Zongpeng Du | Uploaded new revision |
2018-01-25
|
11 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2018-01-25
|
11 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2018-01-25
|
11 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2018-01-24
|
11 | Adam Roach | [Ballot comment] I have run out of time to fully review this document before the telechat, and it is sufficiently outside my area of expertise … [Ballot comment] I have run out of time to fully review this document before the telechat, and it is sufficiently outside my area of expertise that I do not believe that the input I could provide is valuable enough to warrant deferring. However, I want to put a fine point on Ben's comment ("§1, 3rd paragraph after figure 1: We should avoid using lawful intercept as a justification for protocol mechanisms.") The IETF has a long-established policy in this area, summarized in RFC 2804 as: "The IETF has decided not to consider requirements for wiretapping as part of the process for creating and maintaining IETF standards." If you can remove the mention of lawful intercept from this document and the justification for the described configuration still makes sense (as I believe it does), please do so. If you think that the removal of lawful intercept from this section tangibly changes the rationale for the design described in this document, please let me know, and I'll change my position to DISCUSS while we figure out what needs to happen. Thanks! |
2018-01-24
|
11 | Adam Roach | [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach |
2018-01-24
|
11 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2018-01-24
|
11 | Alia Atlas | [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas |
2018-01-24
|
11 | Terry Manderson | [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson |
2018-01-24
|
11 | Suresh Krishnan | [Ballot discuss] * Section 3.2. This should be easy to resolve but I would like this to be disambiguated before publication. RFC5844 specifies *two* different … [Ballot discuss] * Section 3.2. This should be easy to resolve but I would like this to be disambiguated before publication. RFC5844 specifies *two* different options for UDP encapsulation IPv4-UDP and IPv4-UDP-TLV. Please clarify which of these modes is intended when the Tunnel-Type is 4 4: PMIPv6-UDP. This refers to the UDP tunneling encapsulation described in [RFC5844]. |
2018-01-24
|
11 | Suresh Krishnan | [Ballot Position Update] New position, Discuss, has been recorded for Suresh Krishnan |
2018-01-23
|
11 | Ben Campbell | [Ballot comment] -1, 3rd paragraph after figure 1: We should avoid using lawful intercept as a justification for protocol mechanisms. -1.3: Serving as an "archival … [Ballot comment] -1, 3rd paragraph after figure 1: We should avoid using lawful intercept as a justification for protocol mechanisms. -1.3: Serving as an "archival record" seems like an odd use of "experimental". That sounds more "informational" to me. -7: I agree with Kathleen's comments about the security considerations. Editorial Comments and Nits: - The abbreviations that were expanded in the abstract should be expanded again on the body. -1, paragraph after figure 1: Missing article before the first occurrence of "CAPWAP". -1.3, first sentence: " Service Provider's " should either be " Service Providers' " or "the Service Provider's -2, 3rd paragraph after figure 5: Missing article before WTP (multiple occurrences). |
2018-01-23
|
11 | Ben Campbell | [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell |
2018-01-23
|
11 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2018-01-20
|
11 | Paul Kyzivat | Request for Telechat review by GENART Completed: Ready. Reviewer: Paul Kyzivat. |
2018-01-04
|
11 | Jean Mahoney | Request for Telechat review by GENART is assigned to Paul Kyzivat |
2018-01-04
|
11 | Jean Mahoney | Request for Telechat review by GENART is assigned to Paul Kyzivat |
2018-01-02
|
11 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2018-01-01
|
11 | Warren Kumari | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2018-01-01
|
11 | Warren Kumari | Placed on agenda for telechat - 2018-01-25 |
2018-01-01
|
11 | Warren Kumari | Ballot has been issued |
2018-01-01
|
11 | Warren Kumari | [Ballot Position Update] New position, Yes, has been recorded for Warren Kumari |
2018-01-01
|
11 | Warren Kumari | Ballot writeup was changed |
2017-12-18
|
11 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2017-12-18
|
11 | Zongpeng Du | New version available: draft-ietf-opsawg-capwap-alt-tunnel-11.txt |
2017-12-18
|
11 | (System) | New version approved |
2017-12-18
|
11 | (System) | Request for posting confirmation emailed to previous authors: Zongpeng Du , Sri Gundavelli , Rong Zhang , Rajesh Pazhyannur , Zhen Cao , DENG Hui |
2017-12-18
|
11 | Zongpeng Du | Uploaded new revision |
2017-12-13
|
10 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2017-12-11
|
10 | Paul Kyzivat | Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Paul Kyzivat. |
2017-12-04
|
10 | (System) | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2017-12-04
|
10 | Amanda Baber | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has completed its review of draft-ietf-opsawg-capwap-alt-tunnel-10. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has completed its review of draft-ietf-opsawg-capwap-alt-tunnel-10. If any part of this review is inaccurate, please let us know. We have a question about one of the actions in this document. See the last action listed below. The IANA Services Operator understands that, upon approval of this document, there are five actions which we must complete. First, in the CAPWAP Message Element Type registry on the Control And Provisioning of Wireless Access Points (CAPWAP) Parameters registry page located at: https://www.iana.org/assignments/capwap-parameters/ a single new message element type will be registered as follows: CAPWAP Control Message: Supported Alternate Tunnel Encapsulations Type Type Value: [ TBD-at-Registration ] Reference: [ RFC-to-be ] IANA notes that the Type Value needs to come from the 1-1023 range. The designated expert for CAPWAP Message Element Types has already reviewed and approved this registration. Second, also in the CAPWAP Message Element Type registry on the Control And Provisioning of Wireless Access Points (CAPWAP) Parameters registry page located at: https://www.iana.org/assignments/capwap-parameters/ another new message element type will be registered: CAPWAP Control Message: Alternate Tunnel Encapsulations Type Type Value: [ TBD-at-Registration ] Reference: [ RFC-to-be ] IANA notes that the Type Value needs to come from the 1-1023 range. The designated expert for CAPWAP Message Element Types has already reviewed and approved this registration. Third, also in the CAPWAP Message Element Type registry on the Control And Provisioning of Wireless Access Points (CAPWAP) Parameters registry page located at: https://www.iana.org/assignments/capwap-parameters/ another new message element type will be registered: CAPWAP Control Message: IEEE 802.11 WTP Alternate Tunnel Failure Indication Type Value: [ TBD-at-Registration ] Reference: [ RFC-to-be ] IANA notes that the Type Value needs to come from the 1024-2047 range. The designated expert for CAPWAP Message Element Types has already reviewed and approved this registration. Fourth, a new registry called CAPWAP Alternate Tunnel-Types will be created. This new registry is to be managed through the Specification Required policy defined by RFC 8126. IANA understands, based on correspondence with the authors, that the new registry is to be located on the registry page at: http://www.iana.org/assignments/capwap-parameters There are initial registrations in the new registry: Tunnel-Type Type Value Reference ---------------------+------------+-------------------- CAPWAP 0 [RFC5415],[RFC5416] L2TP 1 [RFC2661] L2TPv3 2 [RFC3931] IP-IP 3 [RFC2003] PMIPv6-UDP 4 [RFC5844] GRE 5 [RFC2784] GTPv1-U 6 [3GPP TS 29.281] Unassigned 7 - 65535 Fifth, a new registry called Alternate Tunnel Sub-elements will be created. This new registry is to be managed through the Expert Review policy defined by RFC 8126. IANA understands, based on correspondence with the authors, that the new registry is to be located on the registry page at: http://www.iana.org/assignments/capwap-parameters There are initial registrations in the new registry: Type Type Value Reference ---------------------------------+-----------+------------- AR IPv4 List 0 [ RFC-to-be ] AR IPv6 List 1 [ RFC-to-be ] Tunnel DTLS Policy 2 [ RFC-to-be ] IEEE 802.11 Tagging Mode Policy 3 [ RFC-to-be ] CAPWAP Transport Protocol 4 [ RFC-to-be ] GRE Key 5 [ RFC-to-be ] IPv6 MTU 6 [ RFC-to-be ] IANA QUESTION: What is the maximum value for this registry? The IANA Services Operator understands that these are the only actions required to be completed upon approval of this document. Thank you, Amanda Baber Lead IANA Services Specialist |
2017-11-30
|
10 | Jean Mahoney | Request for Last Call review by GENART is assigned to Paul Kyzivat |
2017-11-30
|
10 | Jean Mahoney | Request for Last Call review by GENART is assigned to Paul Kyzivat |
2017-11-29
|
10 | Amy Vezza | The following Last Call announcement was sent out (ends 2017-12-13): From: The IESG To: IETF-Announce CC: draft-ietf-opsawg-capwap-alt-tunnel@ietf.org, opsawg-chairs@ietf.org, Tianran Zhou , opsawg@ietf.org, … The following Last Call announcement was sent out (ends 2017-12-13): From: The IESG To: IETF-Announce CC: draft-ietf-opsawg-capwap-alt-tunnel@ietf.org, opsawg-chairs@ietf.org, Tianran Zhou , opsawg@ietf.org, zhoutianran@huawei.com, warren@kumari.net Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Alternate Tunnel Encapsulation for Data Frames in CAPWAP) to Experimental RFC The IESG has received a request from the Operations and Management Area Working Group WG (opsawg) to consider the following document: - 'Alternate Tunnel Encapsulation for Data Frames in CAPWAP' as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-12-13. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Control and Provisioning of Wireless Access Points (CAPWAP) defines a specification to encapsulate a station's data frames between the Wireless Transmission Point (WTP) and Access Controller (AC). Specifically, the station's IEEE 802.11 data frames can be either locally bridged or tunneled to the AC. When tunneled, a CAPWAP data channel is used for tunneling. In many deployments encapsulating data frames to an entity other than the AC (for example to an Access Router (AR)) is desirable. Furthermore, it may also be desirable to use different tunnel encapsulation modes between the WTP and the Access Router. This document defines extension to CAPWAP protocol for supporting this capability and refers to it as alternate tunnel encapsulation. The alternate tunnel encapsulation allows 1) the WTP to tunnel non-management data frames to an endpoint different from the AC and 2) the WTP to tunnel using one of many known encapsulation types such as IP-IP, IP-GRE, CAPWAP. The WTP may advertise support for alternate tunnel encapsulation during the discovery and join process and AC may select one of the supported alternate tunnel encapsulation types while configuring the WTP. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-alt-tunnel/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-alt-tunnel/ballot/ No IPR declarations have been submitted directly on this I-D. |
2017-11-29
|
10 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2017-11-29
|
10 | Amy Vezza | Last call announcement was generated |
2017-11-29
|
10 | Warren Kumari | Last call was requested |
2017-11-29
|
10 | Warren Kumari | IESG state changed to Last Call Requested from AD Evaluation |
2017-10-24
|
10 | Warren Kumari | IESG state changed to AD Evaluation from Publication Requested |
2017-10-24
|
10 | Warren Kumari | Document had already gone through IESG eval (2016) - manually setting WG state. |
2017-10-24
|
10 | Warren Kumari | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2017-10-23
|
10 | Warren Kumari | Ballot writeup was changed |
2017-10-23
|
10 | Benoît Claise | IESG state changed to Publication Requested from Waiting for AD Go-Ahead |
2017-10-17
|
10 | Tianran Zhou | IETF WG state changed to WG Consensus: Waiting for Write-Up from WG Document |
2017-10-17
|
10 | Tianran Zhou | Document: draft-ietf-opsawg-capwap-alt-tunnel WG: OpsAWG. Shepherd: Warren Kumari/Tianran Zhou (1) This experimental document is intended to serve as a historical reference for any future work as … Document: draft-ietf-opsawg-capwap-alt-tunnel WG: OpsAWG. Shepherd: Warren Kumari/Tianran Zhou (1) This experimental document is intended to serve as a historical reference for any future work as to the operational and deployment requirements. (2) The IESG approval announcement includes a Document Announcement Write-Up. The approval announcement contains the following sections: Technical Summary: CAPWAP defines a specification to encapsulate a station's data frames between the Wireless Transmission Point (WTP) and Access Controller (AC). In many deployments it is desirable to encapsulate date frames to an entity other than the AC (for example to an Access Router). This document provides a specification for this and allows 1) the WTP to tunnel non-management data frames to an endpoint different from the AC and 2) the WTP to tunnel using one of many known encapsulation types. Working Group Summary: There was no drama in the WG regarding this draft. The document was originally WGLCed in 2014, and submitted for publication in early 2015. Shortly after that we received draft-you-opsawg-capwap-separation-for-mp, which expands the technique in alt-tunnel. Having two, similar documents, with significant overlap would be confusing, and so we requested that the IESG return alt-tunnel to the WG and merged them into one. The draft was sent to IESG again in the middle of 2016. There were several issues raised during the IETF LC review. One major problem is on security. This document was improved by addressing all the comments received and passed the security directorate review. This has been completed, and so we are resubmitting it. Document Quality: A number of operators (including CMCC and AT&T) indicated that they need something like this. Cisco and Huawei has implemented this technology. Personnel: Tianran Zhou will be the document shepherd, Warren Kumari will be the responsible AD. (Last time, Warren Kumari was the document shepherd, and Joel Jaeggli was the responsible AD.) (3) Briefly describe the review of this document that was performed by the Document Shepherd: The DS is not an expert in the CAPWAP, but the document is easy to understand, and well written. The problem statement is clear, and operators have said that it is a real problem. The solution appears to solve the problem statement and has been implemented. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? OpsAWG is not focused on CAPWAP, but we provided a home for some CAPWAP documents (instead of spinning up a whole new working group). This means that the majority of participants are not passionate about CAPWAP, and so we only got a few reviews. That said, the reviews that we *did* get were clear, thorough and supportive. The document has also been presented and discussed at a number of in person meetings. Because the IETF and IEEE coordinate on CAPWAP work, we checked with the IEEE to make sure we were not stepping on their toes. (https://datatracker.ietf.org/liaison/1312/) Response below (also at https://datatracker.ietf.org/liaison/1350/): --- Thank you for the opportunity to review the "Alternate Tunnel Encapsulation for Data Frames in CAPWAP'" http://www.ietf.org/id/draft-zhang-opsawg-capwap-cds-02.txt document. The Alternate Tunnel Encapsulation draft appears to address implementation of the IEEE 802.11 Distribution System (DS). Implementation of the DS is outside the scope of the IEEE 802.11 standard. We will inform IEEE 802.11 members of this work, and welcome further requests from the OPSAWG for information or clarification of the IEEE 802.11 standard. Thank you, Bruce Kraemer (outgoing chair 802.11, March 2014) Adrian P Stephens (incoming chair 802.11, March 2014) Chair, IEEE 802.11 ------ (5) Do portions of the document need review from a particular or from broader perspective? Nope. (6) Describe any specific concerns or issues that the Document Shepherd has with this document. None. (7) Has each author confirmed all appropriate IPR disclosures? Yup! (8) Has an IPR disclosure been filed that references this document? Nope! (9) How solid is the WG consensus behind this document? There is strong consensus from a small group -- this group is the subset of OpsAWG that follows CAPWAP. The document went through 3 WGLCs. We are judging the level of interest / support from combing the results of both LCs. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? Nope, it's not that kind of document. Instead, it is the kind of document we had to ask people to care about :-P. (11) Identify any ID nits the Document Shepherd has found in this document. None. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. Not applicable. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement? Nope. (15) Are there downward normative references references? Nope. (16) Will publication of this document change the status of any existing RFCs? Nope. (17) Describe the Document Shepherd's review of the IANA considerations section. The registry name was originally missing. We've fixed that. (18) List any new IANA registries that require Expert Review for future allocations. None. We made the registry be Specification Required. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language. There are none. Can I please get a refund for that portion of the review? |
2017-10-17
|
10 | Tianran Zhou | Intended Status changed to Experimental from Proposed Standard |
2017-10-17
|
10 | Warren Kumari | Ballot writeup was changed |
2017-10-11
|
10 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2017-10-10
|
10 | Benoît Claise | IESG state changed to In Last Call from Dead |
2017-10-10
|
10 | Benoît Claise | Shepherding AD changed to Warren Kumari |
2017-10-10
|
10 | Benoît Claise | Notification list changed to warren@kumari.net, Tianran Zhou <zhoutianran@huawei.com> from warren@kumari.net |
2017-10-10
|
10 | Benoît Claise | Document shepherd changed to Tianran Zhou |
2017-09-08
|
10 | Zongpeng Du | New version available: draft-ietf-opsawg-capwap-alt-tunnel-10.txt |
2017-09-08
|
10 | (System) | New version approved |
2017-09-08
|
10 | (System) | Request for posting confirmation emailed to previous authors: Zongpeng Du , Sri Gundavelli , Rong Zhang , Rajesh Pazhyannur , Zhen Cao , DENG Hui |
2017-09-08
|
10 | Zongpeng Du | Uploaded new revision |
2017-08-10
|
09 | Tero Kivinen | Request for Early review by SECDIR Completed: Ready. Reviewer: Catherine Meadows. |
2017-06-15
|
09 | Tero Kivinen | Request for Early review by SECDIR is assigned to Catherine Meadows |
2017-06-15
|
09 | Tero Kivinen | Request for Early review by SECDIR is assigned to Catherine Meadows |
2017-06-13
|
09 | Tianran Zhou | Requested Early review by SECDIR |
2017-05-03
|
09 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2017-05-03
|
09 | Zhen Cao | New version available: draft-ietf-opsawg-capwap-alt-tunnel-09.txt |
2017-05-03
|
09 | (System) | New version approved |
2017-05-03
|
09 | (System) | Request for posting confirmation emailed to previous authors: Zhen Cao , Sri Gundavelli , Rong Zhang , opsawg-chairs@ietf.org, Jianjie You , DENG Hui , … Request for posting confirmation emailed to previous authors: Zhen Cao , Sri Gundavelli , Rong Zhang , opsawg-chairs@ietf.org, Jianjie You , DENG Hui , Rajesh Pazhyannur , Li Xue |
2017-05-03
|
09 | Zhen Cao | Uploaded new revision |
2017-02-02
|
08 | (System) | Document has expired |
2017-02-02
|
08 | (System) | IESG state changed to Dead from AD is watching |
2017-02-01
|
08 | Joel Jaeggli | IESG state changed to AD is watching from IESG Evaluation |
2017-01-13
|
08 | Sabrina Tanamal | IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK |
2016-11-03
|
08 | Gunter Van de Velde | Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Shucheng LIU. |
2016-10-24
|
08 | Joel Jaeggli | Removed from agenda for telechat |
2016-10-24
|
08 | Joel Jaeggli | [Ballot discuss] sorry we came to some comclusions on the basis of late review that make this hard to advance without correcting. this will be … [Ballot discuss] sorry we came to some comclusions on the basis of late review that make this hard to advance without correcting. this will be withdrawn from this review cycle. |
2016-10-24
|
08 | Joel Jaeggli | [Ballot Position Update] Position for Joel Jaeggli has been changed to Discuss from Yes |
2016-10-24
|
08 | Mirja Kühlewind | [Ballot comment] Nit: s/This specification defines the values from zero (0) to five (5)/This specification defines the values from zero (0) to six (6)/ |
2016-10-24
|
08 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2016-10-23
|
08 | Alexey Melnikov | [Ballot comment] +1 to Katleen's comment about optional data channel protection. In 3.3. IEEE 802.11 WTP Alternate Tunnel Failure Indication Length == 4, but should … [Ballot comment] +1 to Katleen's comment about optional data channel protection. In 3.3. IEEE 802.11 WTP Alternate Tunnel Failure Indication Length == 4, but should it be >4 due to IPv4/IPv6 address at the end? |
2016-10-23
|
08 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov |
2016-10-23
|
08 | Kathleen Moriarty | [Ballot comment] I'm surprised to see security is optional and an assertion that RFCs published in 2009 covers everything. Threats have evolved since then. In … [Ballot comment] I'm surprised to see security is optional and an assertion that RFCs published in 2009 covers everything. Threats have evolved since then. In looking at RFC5415, Section 12.1, I see: Within CAPWAP, DTLS is used to secure the link between the WTP and AC. In addition to securing control messages, it's also a link in this chain of trust for establishing link layer keys. Consequently, much rests on the security of DTLS. In some CAPWAP deployment scenarios, there are two channels between the WTP and AC: the control channel, carrying CAPWAP Control messages, and the data channel, over which client data packets are tunneled between the AC and WTP. Typically, the control channel is secured by DTLS, while the data channel is not. The use of parallel protected and unprotected channels deserves special consideration, but does not create a threat. There are two potential concerns: attempting to convert protected data into unprotected data and attempting to convert un-protected data into protected data. These concerns are addressed below. Wouldn't interception and tampering of that traffic pose a threat? How about gaining access to the control channel? While I don't think this is the right draft to make changes for RFC5415, I don't think it's adequate to say the control channel is optional for encryption. I could see how the data might be handled elsewhere. The description discusses this as talking to hundreds of thousands of access points, isn't that access a threat? This draft allows for additional encapsulation methods, we could require encryption for these new encapsulation methods. This should probably be a discuss, so I would appreciate some discussion on this to see if we have option here or if something will change in the referenced RFCs soon. Thank you. |
2016-10-23
|
08 | Kathleen Moriarty | Ballot comment text updated for Kathleen Moriarty |
2016-10-23
|
08 | Kathleen Moriarty | [Ballot comment] I'm surprised to see security is optional and an assertion that RFCs published in 2009 cover everything. That might be the case, but … [Ballot comment] I'm surprised to see security is optional and an assertion that RFCs published in 2009 cover everything. That might be the case, but threats have evolved since then. In looking at RFC5415, Section 12.1, I see: Within CAPWAP, DTLS is used to secure the link between the WTP and AC. In addition to securing control messages, it's also a link in this chain of trust for establishing link layer keys. Consequently, much rests on the security of DTLS. In some CAPWAP deployment scenarios, there are two channels between the WTP and AC: the control channel, carrying CAPWAP Control messages, and the data channel, over which client data packets are tunneled between the AC and WTP. Typically, the control channel is secured by DTLS, while the data channel is not. The use of parallel protected and unprotected channels deserves special consideration, but does not create a threat. There are two potential concerns: attempting to convert protected data into unprotected data and attempting to convert un-protected data into protected data. These concerns are addressed below. While I don't think this is the right draft to make changes for RFC5415, I don't think it's adequate to say the control channel is optional for encryption. I could see how the data might be handled elsewhere. The description discusses this as talking to hundreds of thousands of access points, isn't that access a threat? Maybe it is appropriate to require encryption for these new encapsulation methods. |
2016-10-23
|
08 | Kathleen Moriarty | [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty |
2016-10-21
|
08 | Paul Kyzivat | Request for Telechat review by GENART Completed: On the Right Track. Reviewer: Paul Kyzivat. |
2016-10-20
|
08 | Jean Mahoney | Request for Telechat review by GENART is assigned to Paul Kyzivat |
2016-10-20
|
08 | Jean Mahoney | Request for Telechat review by GENART is assigned to Paul Kyzivat |
2016-10-20
|
08 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Catherine Meadows. |
2016-10-03
|
08 | Joel Jaeggli | Placed on agenda for telechat - 2016-10-27 |
2016-10-03
|
08 | Joel Jaeggli | Changed consensus to Yes from Unknown |
2016-10-03
|
08 | Joel Jaeggli | IESG state changed to IESG Evaluation from Waiting for Writeup |
2016-10-03
|
08 | Joel Jaeggli | Ballot has been issued |
2016-10-03
|
08 | Joel Jaeggli | [Ballot Position Update] New position, Yes, has been recorded for Joel Jaeggli |
2016-10-03
|
08 | Joel Jaeggli | Created "Approve" ballot |
2016-10-03
|
08 | Joel Jaeggli | Ballot writeup was changed |
2016-09-30
|
08 | Paul Kyzivat | Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Paul Kyzivat. |
2016-09-30
|
08 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2016-09-29
|
08 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2016-09-29
|
08 | Amanda Baber | (Via drafts-lastcall@iana.org): |
2016-09-22
|
08 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Shucheng LIU |
2016-09-22
|
08 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Shucheng LIU |
2016-09-22
|
08 | Gunter Van de Velde | Assignment of request for Last Call review by OPSDIR to Bert Wijnen was rejected |
2016-09-22
|
08 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Catherine Meadows |
2016-09-22
|
08 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Catherine Meadows |
2016-09-22
|
08 | Jean Mahoney | Request for Last Call review by GENART is assigned to Paul Kyzivat |
2016-09-22
|
08 | Jean Mahoney | Request for Last Call review by GENART is assigned to Paul Kyzivat |
2016-09-21
|
08 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Bert Wijnen |
2016-09-21
|
08 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Bert Wijnen |
2016-09-16
|
08 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2016-09-16
|
08 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: "IETF-Announce" CC: warren@kumari.net, joelja@gmail.com, opsawg-chairs@ietf.org, draft-ietf-opsawg-capwap-alt-tunnel@ietf.org, opsawg@ietf.org Reply-To: ietf@ietf.org … The following Last Call announcement was sent out: From: The IESG To: "IETF-Announce" CC: warren@kumari.net, joelja@gmail.com, opsawg-chairs@ietf.org, draft-ietf-opsawg-capwap-alt-tunnel@ietf.org, opsawg@ietf.org Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Alternate Tunnel Encapsulation for Data Frames in CAPWAP) to Proposed Standard The IESG has received a request from the Operations and Management Area Working Group WG (opsawg) to consider the following document: - 'Alternate Tunnel Encapsulation for Data Frames in CAPWAP' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-09-30. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Control and Provisioning of Wireless Access Points (CAPWAP) defines a specification to encapsulate a station's data frames between the Wireless Transmission Point (WTP) and Access Controller (AC). Specifically, the station's IEEE 802.11 data frames can be either locally bridged or tunneled to the AC. When tunneled, a CAPWAP data channel is used for tunneling. In many deployments encapsulating data frames to an entity other than the AC (for example to an Access Router (AR)) is desirable. Furthermore, it may also be desirable to use different tunnel encapsulation modes between the WTP and the Access Router. This document defines extension to CAPWAP protocol for supporting this capability and refers to it as alternate tunnel encapsulation. The alternate tunnel encapsulation allows 1) the WTP to tunnel non-management data frames to an endpoint different from the AC and 2) the WTP to tunnel using one of many known encapsulation types such as IP-IP, IP-GRE, CAPWAP. The WTP may advertise support for alternate tunnel encapsulation during the discovery or join process and AC may select one of the supported alternate tunnel encapsulation types while configuring the WTP. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-alt-tunnel/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-alt-tunnel/ballot/ No IPR declarations have been submitted directly on this I-D. |
2016-09-16
|
08 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2016-09-16
|
08 | Amy Vezza | Last call announcement was generated |
2016-09-03
|
08 | Joel Jaeggli | Last call was requested |
2016-09-03
|
08 | Joel Jaeggli | Last call announcement was generated |
2016-09-03
|
08 | Joel Jaeggli | Ballot approval text was generated |
2016-09-03
|
08 | Joel Jaeggli | Ballot writeup was generated |
2016-09-03
|
08 | Joel Jaeggli | lets commence this on 9/6 thanks |
2016-09-03
|
08 | Joel Jaeggli | IESG state changed to Last Call Requested from AD Evaluation |
2016-08-08
|
08 | Joel Jaeggli | IESG state changed to AD Evaluation from Publication Requested |
2016-08-03
|
08 | Amy Vezza | IESG state changed to Publication Requested from Dead |
2016-08-03
|
08 | Warren Kumari | Notification list changed to warren@kumari.net |
2016-08-03
|
07 | Warren Kumari | Document: draft-ietf-opsawg-capwap-alt-tunnel WG: OpsAWG. Shepherd: Warren Kumari NOTE: This document was originally submitted to the IESG for publication in September 2014. Shortly after that we … Document: draft-ietf-opsawg-capwap-alt-tunnel WG: OpsAWG. Shepherd: Warren Kumari NOTE: This document was originally submitted to the IESG for publication in September 2014. Shortly after that we received draft-you-opsawg-capwap-separation-for-mp, which expands the technique in alt-tunnel. Having two, similar documents, with significant overlap would be confusing, and so we requested that the IESG return alt-tunnel to the WG and merged them into one. This has now (finally) been completed, and so we are (re)submitting it. (1) Proposed Standard This appears to be the correct / appropriate track. It is a weighty topic, and there are deployed implementations. (2) The IESG approval announcement includes a Document Announcement Write-Up. The approval announcement contains the following sections: Technical Summary: CAPWAP defines a specification to encapsulate a station's data frames between the Wireless Transmission Point (WTP) and Access Controller (AC). In many deployments it is desirable to encapsulate date frames to an entity other than the AC (for example to an Access Router). This document provides a specification for this and allows 1) the WTP to tunnel non-management data frames to an endpoint different from the AC and 2) the WTP to tunnel using one of many known encapsulation types. Working Group Summary: There was no drama in the WG regarding this draft. The document was originally WGLCed in 2014, and submitted for publication in early 2015. The WG then requested that the document to be returned to us, so that we could merge it with another, related draft. This has been completed, and so we are resubmitting it. Document Quality: A number of operators (including CMCC and AT&T) indicated that they need something like this. Cisco has implemented this technology. Personnel: Warren Kumari will be the document shepherd, Benoit Claise will be the AD. (3) Briefly describe the review of this document that was performed by the Document Shepherd: The DS is not an expert in the CAPWAP, but the document is easy to understand, and well written. The problem statement is clear, and operators have said that it is a real problem. The solution appears to solve the problem statement and has been implemented. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? OpsAWG is not focused on CAPWAP, but we provided a home for some CAPWAP documents (instead of spinning up a whole new working group). This means that the majority of partipants are not passionate about CAPWAP, and so we only got a few reviews. That said, the reviews that we *did* get were clear, thorough and supportive. The document has also been presented and discussed at a number of in person meetings. Because the IETF and IEEE coordinate on CAPWAP work, we checked with the IEEE to make sure we were not stepping on their toes. (https://datatracker.ietf.org/liaison/1312/) Response below (also at https://datatracker.ietf.org/liaison/1350/): --- Thank you for the opportunity to review the "Alternate Tunnel Encapsulation for Data Frames in CAPWAP'" http://www.ietf.org/id/draft-zhang-opsawg-capwap-cds-02.txt document. The Alternate Tunnel Encapsulation draft appears to address implementation of the IEEE 802.11 Distribution System (DS). Implementation of the DS is outside the scope of the IEEE 802.11 standard. We will inform IEEE 802.11 members of this work, and welcome further requests from the OPSAWG for information or clarification of the IEEE 802.11 standard. Thank you, Bruce Kraemer (outgoing chair 802.11, March 2014) Adrian P Stephens (incoming chair 802.11, March 2014) Chair, IEEE 802.11 ------ (5) Do portions of the document need review from a particular or from broader perspective? Nope. (6) Describe any specific concerns or issues that the Document Shepherd has with this document. None. (7) Has each author confirmed all appropriate IPR disclosures? Yup! (8) Has an IPR disclosure been filed that references this document? Nope! (9) How solid is the WG consensus behind this document? There is strong consensus from a small group -- this group is the subset of OpsAWG that follows CAPWAP. The document went through 2 WGLCs (see note at beginning of shepherd). We are judging the level of interest / support from combing the results of both LCs. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? Nope, it's not that kind of document. Instead, it is the kind of document we had to ask people to care about :-P. (11) Identify any ID nits the Document Shepherd has found in this document. None. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. Not appliciable. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement? Nope. (15) Are there downward normative references references? Nope. (16) Will publication of this document change the status of any existing RFCs? Nope. (17) Describe the Document Shepherd's review of the IANA considerations section. The registry name was originally missing. We've fixed that. (18) List any new IANA registries that require Expert Review for future allocations. None. We made the registry be Specification Required. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language. There are none. Can I please get a refund for that portion of the review? |
2016-07-08
|
08 | Sri Gundavelli | New version available: draft-ietf-opsawg-capwap-alt-tunnel-08.txt |
2016-06-08
|
07 | Sri Gundavelli | New version available: draft-ietf-opsawg-capwap-alt-tunnel-07.txt |
2016-04-21
|
06 | (System) | Document has expired |
2016-04-21
|
06 | (System) | IESG state changed to Dead from AD is watching |
2015-10-19
|
06 | Rajesh Pazhyannur | New version available: draft-ietf-opsawg-capwap-alt-tunnel-06.txt |
2015-10-14
|
05 | (System) | Notify list changed from warren@kumari.net, opsawg-chairs@ietf.org to (None) |
2015-09-07
|
05 | Joel Jaeggli | returned to the working group for a correction of an issue: Summary is that we would like you to return https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-alt-tunnel/ (sitting in "AD is … returned to the working group for a correction of an issue: Summary is that we would like you to return https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-alt-tunnel/ (sitting in "AD is watching" since 2015-04-26) so that we can merge in draft-you-opsawg-capwap-separation-for-mp. W |
2015-09-07
|
05 | Joel Jaeggli | IETF WG state changed to WG Document from Submitted to IESG for Publication |
2015-09-07
|
05 | Joel Jaeggli | Shepherding AD changed to Joel Jaeggli |
2015-04-26
|
05 | Sri Gundavelli | New version available: draft-ietf-opsawg-capwap-alt-tunnel-05.txt |
2015-02-25
|
04 | Benoît Claise | On 1/20/15, 5:40 AM, "Benoit Claise (bclaise)" wrote: > Dear draft-ietf-opsawg-capwap-alt-tunnel and > draft-xue-opsawg-capwap-alt-tunnel-information authors, > > Can you please a draft version according to … On 1/20/15, 5:40 AM, "Benoit Claise (bclaise)" wrote: > Dear draft-ietf-opsawg-capwap-alt-tunnel and > draft-xue-opsawg-capwap-alt-tunnel-information authors, > > Can you please a draft version according to Sri's plan below. > > Regards, Benoit >> wfm >> >>> On Dec 19, 2014, at 10:05 AM, Benoit Claise wrote: >>> >>> On 03/12/2014 08:59, Sri Gundavelli (sgundave) wrote: >>>> Hi Benoit, >>>> >>>>> Let me propose a solution: augment >>>>> draft-ietf-opsawg-capwap-alt-tunnel with the information elements for >>>>> CAPWAP (not the others one). >>>> The above draft defines number of encapsulation modes and that list >>>> includes, CAPWAP, L2TPv2, L2TPv3, IP-in-IP, PMIPv6, GREv4 and GREv6. >>>> Each of those tunnel types can be activated with a set of tunnel >>>> parameters. These parameters include source IP, destination IP, sport, >>>> dport, GRE key ..etc. To most part this is about identifying a common >>>> set of parameters, providing definition for those parameters and >>>> grouping the relevant one's for each of the encapsulation modes. >>>> Taking GREv4, GREv6, IP-in-IP or PMIP (uses GRE), each are not >>>> radically different from the others and the above common parameter set >>>> is sufficient for these modes. To create a tunnel with GRE with IPv4 >>>> transport is not any different from GRE with IPv6 transport, or for >>>> that matter for IP-in-IP mode. >>>> >>>> It is to be noted there are no proposed changes to any of these >>>> encapsulation modes, or to the control protocols activating those >>>> encap modes. Its mostly about activating a tunnel state with a >>>> set of parameters. If at all, CAPWAP data plane may be bit complex >>>> and even L2TP as its unclear if the control protocol has semantics for >>>> the L2TP peers to separate control and data plane. If not, it requires >>>> changes to the L2TP protocol. So, its easier to keep CAPWAP + >>>> GRE/IP-in-IP modes in the main spec as the work has a well defined >>>> scope. >>> If it works for the WG, it works for me. Any objections anybody? >>> That would imply a new draft and a new consensus call. >>> >>> Regards, Benoit |
2015-02-25
|
04 | Benoît Claise | IESG state changed to AD is watching from AD Evaluation::AD Followup |
2014-12-19
|
04 | Benoît Claise | Notification list changed to draft-ietf-opsawg-capwap-alt-tunnel.all@tools.ietf.org, opsawg@ietf.org, warren@kumari.net, opsawg-chairs@tools.ietf.org from opsawg-chairs@tools.ietf.org, draft-ietf-opsawg-capwap-alt-tunnel@tools.ietf.org |
2014-11-10
|
03 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2014-11-10
|
04 | Rajesh Pazhyannur | New version available: draft-ietf-opsawg-capwap-alt-tunnel-04.txt |
2014-10-27
|
03 | Benoît Claise | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
2014-09-28
|
03 | Benoît Claise | IESG state changed to AD Evaluation from Publication Requested |
2014-09-09
|
03 | Warren Kumari | Document: draft-ietf-opsawg-capwap-alt-tunnel WG: OpsAWG. Shepherd: Warren Kumari This version of the writeup is dated 24 February 2012. (1) Proposed Standard This appears to be the … Document: draft-ietf-opsawg-capwap-alt-tunnel WG: OpsAWG. Shepherd: Warren Kumari This version of the writeup is dated 24 February 2012. (1) Proposed Standard This appears to be the correct / appropriate track. It is a weighty topic, and there are deployed implementations. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: CAPWAP defines a specification to encapsulate a station's data frames between the Wireless Transmission Point (WTP) and Access Controller (AC). In many deployments it is desirable to encapsulate date frames to an entity other than the AC (for example to an Access Router). This document provides a specification for this and allows 1) the WTP to tunnel non-management data frames to an endpoint different from the AC and 2) the WTP to tunnel using one of many known encapsulation types. Working Group Summary: There was no drama in the WG regarding this draft. Document Quality: A number of operators (including CMCC and AT&T) indicated that they need something like this. Cisco has implemented this technology. Personnel: Warren Kumari will be the document shepherd, Benoit Claise will be the AD. (3) Briefly describe the review of this document that was performed by the Document Shepherd: The DS is not an expert in the CAPWAP, but the document is easy to understand, and well written. The problem statement is clear, and operators have said that it is a real problem. The solution appears to solve the problem statement and has been implemented. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? OpsAWG is not focused on CAPWAP, but we provided a home for some CAPWAP documents (instead of spinning up a whole new working group). This means that the majority of partipants are not passionate about CAPWAP, and so we only got a few reviews. That said, the reviews that we *did* get were clear, thorough and supportive. The document has also been presented and discussed at a number of in person meetings. Because the IETF and IEEE coordinate on CAPWAP work, we checked with the IEEE to make sure we were not stepping on their toes. (https://datatracker.ietf.org/liaison/1312/) Response below (also at https://datatracker.ietf.org/liaison/1350/): --- Thank you for the opportunity to review the "Alternate Tunnel Encapsulation for Data Frames in CAPWAP'" http://www.ietf.org/id/draft-zhang-opsawg-capwap-cds-02.txt document. The Alternate Tunnel Encapsulation draft appears to address implementation of the IEEE 802.11 Distribution System (DS). Implementation of the DS is outside the scope of the IEEE 802.11 standard. We will inform IEEE 802.11 members of this work, and welcome further requests from the OPSAWG for information or clarification of the IEEE 802.11 standard. Thank you, Bruce Kraemer (outgoing chair 802.11, March 2014) Adrian P Stephens (incoming chair 802.11, March 2014) Chair, IEEE 802.11 ------ (5) Do portions of the document need review from a particular or from broader perspective? Nope. (6) Describe any specific concerns or issues that the Document Shepherd has with this document. None. (7) Has each author confirmed all appropriate IPR disclosures? Yup! (8) Has an IPR disclosure been filed that references this document? Nope! (9) How solid is the WG consensus behind this document? There is strong consensus from a small group -- this group is the subset of OpsAWG that follows CAPWAP. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? Nope, it's not that kind of document. Instead, it is the kind of document we had to ask people to care about :-P. (11) Identify any ID nits the Document Shepherd has found in this document. The nit checks says: The document seems to lack the recommended RFC 2119 boilerplate. This is because the boilerplate has ""SHOULD NOT", "RECOMMENDED", "MAY"", but is missing "NOT RECOMMENDED". Instead of asking the authors to spin another copy, I'm going to let them fix it during IETF LC / RFC Ed. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. It does NOT meet any required formal review criteria, because there are no formal bits. So there! (13) Have all references within this document been identified as either normative or informative? Sure have. (14) Are there normative references to documents that are not ready for advancement? Nope. There is an informative ref to xue-opsawg-capwap-alt-tunnel-information... (15) Are there downward normative references references? Nope. (16) Will publication of this document change the status of any existing RFCs? Nope. (17) Describe the Document Shepherd's review of the IANA considerations section. The registry name was missing. We've fixed that. (18) List any new IANA registries that require Expert Review for future allocations. None. We made the registry be Specification Required. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language. There are none. Can I get a refund for that portion of the review? |
2014-09-08
|
03 | Warren Kumari | Document: draft-ietf-opsawg-capwap-alt-tunnel WG: OpsAWG. Shepherd: Warren Kumari This version of the writeup is dated 24 February 2012. (1) Proposed Standard This appears to be the … Document: draft-ietf-opsawg-capwap-alt-tunnel WG: OpsAWG. Shepherd: Warren Kumari This version of the writeup is dated 24 February 2012. (1) Proposed Standard This appears to be the correct / appropriate track. It is a weighty topic, and there are deployed implementations. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: CAPWAP defines a specification to encapsulate a station's data frames between the Wireless Transmission Point (WTP) and Access Controller (AC). In many deployments it is desirable to encapsulate date frames to an entity other than the AC (for example to an Access Router). This document provides a specification for this and allows 1) the WTP to tunnel non-management data frames to an endpoint different from the AC and 2) the WTP to tunnel using one of many known encapsulation types. Working Group Summary: There was no drama in the WG regarding this draft. Document Quality: A number of operators (including CMCC and AT&T) indicated that they need something like this. Cisco has implemented this technology. Personnel: Warren Kumari will be the document shepherd, Benoit Claise will be the AD. (3) Briefly describe the review of this document that was performed by the Document Shepherd: The DS is not an expert in the CAPWAP, but the document is easy to understand, and well written. The problem statement is clear, and operators have said that it is a real problem. The solution appears to solve the problem statement and has been implemented. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? OpsAWG is not focused on CAPWAP, but we provided a home for some CAPWAP documents (instead of spinning up a whole new working group). This means that the majority of partipants are not passionate about CAPWAP, and so we only got a few reviews. That said, the reviews that we *did* get were clear, thorough and supportive. The document has also been presented and discussed at a number of in person meetings. Because the IETF and IEEE coordinate on CAPWAP work, we checked with the IEEE to make sure we were not stepping on their toes. (https://datatracker.ietf.org/liaison/1312/) Response below (I'm also sending it to be added to the liaison page): --- Thank you for the opportunity to review the "Alternate Tunnel Encapsulation for Data Frames in CAPWAP'" http://www.ietf.org/id/draft-zhang-opsawg-capwap-cds-02.txt document. The Alternate Tunnel Encapsulation draft appears to address implementation of the IEEE 802.11 Distribution System (DS). Implementation of the DS is outside the scope of the IEEE 802.11 standard. We will inform IEEE 802.11 members of this work, and welcome further requests from the OPSAWG for information or clarification of the IEEE 802.11 standard. Thank you, Bruce Kraemer (outgoing chair 802.11, March 2014) Adrian P Stephens (incoming chair 802.11, March 2014) Chair, IEEE 802.11 ------ (5) Do portions of the document need review from a particular or from broader perspective? Nope. (6) Describe any specific concerns or issues that the Document Shepherd has with this document. None. (7) Has each author confirmed all appropriate IPR disclosures? Yup! (8) Has an IPR disclosure been filed that references this document? Nope! (9) How solid is the WG consensus behind this document? There is strong consensus from a small group -- this group is the subset of OpsAWG that follows CAPWAP. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? Nope, it's not that kind of document. Instead, it is the kind of document we had to ask people to care about :-P. (11) Identify any ID nits the Document Shepherd has found in this document. The nit checks says: The document seems to lack the recommended RFC 2119 boilerplate. This is because the boilerplate has ""SHOULD NOT", "RECOMMENDED", "MAY"", but is missing "NOT RECOMMENDED". Instead of asking the authors to spin another copy, I'm going to let them fix it during IETF LC / RFC Ed. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. It does NOT meet any required formal review criteria, because there are no formal bits. So there! (13) Have all references within this document been identified as either normative or informative? Sure have. (14) Are there normative references to documents that are not ready for advancement? Nope. There is an informative ref to xue-opsawg-capwap-alt-tunnel-information... (15) Are there downward normative references references? Nope. (16) Will publication of this document change the status of any existing RFCs? Nope. (17) Describe the Document Shepherd's review of the IANA considerations section. The registry name was missing. We've fixed that. (18) List any new IANA registries that require Expert Review for future allocations. None. We made the registry be Specification Required. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language. There are none. Can I get a refund for that portion of the review? |
2014-09-08
|
03 | Warren Kumari | State Change Notice email list changed to opsawg-chairs@tools.ietf.org, draft-ietf-opsawg-capwap-alt-tunnel@tools.ietf.org |
2014-09-08
|
03 | Warren Kumari | Responsible AD changed to Benoit Claise |
2014-09-08
|
03 | Warren Kumari | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2014-09-08
|
03 | Warren Kumari | IESG state changed to Publication Requested |
2014-09-08
|
03 | Warren Kumari | IESG process started in state Publication Requested |
2014-09-08
|
03 | Warren Kumari | Document shepherd changed to Warren Kumari |
2014-09-08
|
03 | Warren Kumari | Changed document writeup |
2014-09-08
|
03 | Rajesh Pazhyannur | New version available: draft-ietf-opsawg-capwap-alt-tunnel-03.txt |
2014-09-04
|
02 | Warren Kumari | Tag Revised I-D Needed - Issue raised by WGLC cleared. |
2014-08-28
|
02 | Rajesh Pazhyannur | New version available: draft-ietf-opsawg-capwap-alt-tunnel-02.txt |
2014-08-27
|
01 | Warren Kumari | Tag Revised I-D Needed - Issue raised by WGLC set. |
2014-08-27
|
01 | Warren Kumari | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2014-08-27
|
01 | Warren Kumari | Intended Status changed to Proposed Standard from None |
2014-08-11
|
01 | Warren Kumari | IETF WG state changed to In WG Last Call from WG Document |
2014-07-25
|
01 | Rajesh Pazhyannur | New version available: draft-ietf-opsawg-capwap-alt-tunnel-01.txt |
2014-07-16
|
00 | Warren Kumari | This document now replaces draft-zhang-opsawg-capwap-cds instead of None |
2014-05-05
|
00 | Rajesh Pazhyannur | New version available: draft-ietf-opsawg-capwap-alt-tunnel-00.txt |