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?