Alternate Tunnel Encapsulation for Data Frames in Control and Provisioning of Wireless Access Points (CAPWAP)
draft-ietf-opsawg-capwap-alt-tunnel-12

[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!

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

[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).

(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

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.

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?

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

[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.

[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?

[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.

[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.

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.

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?

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

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

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?

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?