Re: [OPSAWG] Ben Campbell's No Objection on draft-ietf-opsawg-capwap-alt-tunnel-11: (with COMMENT)

Duzongpeng <duzongpeng@huawei.com> Thu, 25 January 2018 07:07 UTC

Return-Path: <duzongpeng@huawei.com>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D61AD12E055; Wed, 24 Jan 2018 23:07:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.23
X-Spam-Level:
X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dvVr06-bdGJ6; Wed, 24 Jan 2018 23:07:39 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44F8E12E042; Wed, 24 Jan 2018 23:07:39 -0800 (PST)
Received: from lhreml708-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id E315E445479A; Thu, 25 Jan 2018 07:07:35 +0000 (GMT)
Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 25 Jan 2018 07:07:36 +0000
Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0361.001; Thu, 25 Jan 2018 15:07:26 +0800
From: Duzongpeng <duzongpeng@huawei.com>
To: Ben Campbell <ben@nostrum.com>, The IESG <iesg@ietf.org>
CC: "draft-ietf-opsawg-capwap-alt-tunnel@ietf.org" <draft-ietf-opsawg-capwap-alt-tunnel@ietf.org>, Tianran Zhou <zhoutianran@huawei.com>, "warren@kumari.net" <warren@kumari.net>, "opsawg-chairs@ietf.org" <opsawg-chairs@ietf.org>, Tianran Zhou <zhoutianran@huawei.com>, "opsawg@ietf.org" <opsawg@ietf.org>
Thread-Topic: Ben Campbell's No Objection on draft-ietf-opsawg-capwap-alt-tunnel-11: (with COMMENT)
Thread-Index: AQHTlMSzoVllslzMbEi9+5EMV7DcFaOD8o+Q
Date: Thu, 25 Jan 2018 07:07:26 +0000
Message-ID: <BAFEC9523F57BC48A51C20226A55895764823A26@nkgeml514-mbx.china.huawei.com>
References: <151676505752.24181.16152395977449682862.idtracker@ietfa.amsl.com>
In-Reply-To: <151676505752.24181.16152395977449682862.idtracker@ietfa.amsl.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.149.226]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/gfaIFu0A508u_rBXato9krkHHT0>
Subject: Re: [OPSAWG] Ben Campbell's No Objection on draft-ietf-opsawg-capwap-alt-tunnel-11: (with COMMENT)
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jan 2018 07:07:42 -0000

Hi, Ben Campbell

	Thank you for proposing the problems.

	Please see inline.

	If no objections, I will update the draft accordingly.

	If any future problems, please connect me. Thanks.

Best Regards
Zongpeng Du

-----Original Message-----
From: Ben Campbell [mailto:ben@nostrum.com] 
Sent: Wednesday, January 24, 2018 11:38 AM
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-opsawg-capwap-alt-tunnel@ietf.org; Tianran Zhou <zhoutianran@huawei.com>; warren@kumari.net; opsawg-chairs@ietf.org; Tianran Zhou <zhoutianran@huawei.com>; opsawg@ietf.org
Subject: Ben Campbell's No Objection on draft-ietf-opsawg-capwap-alt-tunnel-11: (with COMMENT)

Ben Campbell has entered the following ballot position for
draft-ietf-opsawg-capwap-alt-tunnel-11: No Objection

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-alt-tunnel/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

-1, 3rd paragraph after figure 1: We should avoid using lawful intercept as a justification for protocol mechanisms.

[zongpeng]
Accept. We can delete the unnecessary explanations.

Old:
   Figure 1 describes a system with Local Bridging.  The AC is in a
   centralized location.  The data plane is locally bridged by the WTPs
   leading to a system with centralized control plane with distributed
   data plane.  This system has two benefits: 1) reduces the scale
   requirement on data traffic handling capability of the AC and 2)
   leads to more efficient/optimal routing of data traffic while
   maintaining centralized control/management.
New:
   Figure 1 describes a system with Local Bridging.  The AC is in a
   centralized location.  The data plane is locally bridged by the WTPs
   leading to a system with centralized control plane with distributed
   data plane.  

Would it be ok ?
[/zongpeng]


-1.3: Serving as an "archival record" seems like an odd use of "experimental".
That sounds more "informational" to me.

[zongpeng] 
There have been discussions about it among the authors, chairs, and the ADs. 
Finally, the "Experimental" type is decided.
It a hard decision to make whether the document should be "Experimental", "Informational" or "Historic".

Some personally understanding about it to share:

According to https://tools.ietf.org/html/rfc2026#section-4.2, the Informational type means:
   An "Informational" specification is published for the general
   information of the Internet community, and does not represent an
   Internet community consensus or recommendation.  The Informational
   designation is intended to provide for the timely publication of a
   very broad range of responsible informational documents from many
   sources, subject only to editorial considerations and to verification
   that there has been adequate coordination with the standards process
   (see section 4.2.3).

Our document is not for a timely publication of new information.
So it is not very proper for us to declare an Informational type.

Also in RFC2026, it is said that  
   The "Experimental" designation typically denotes a specification that
   is part of some research or development effort.  Such a specification
   is published for the general information of the Internet technical
   community and as an archival record of the work, subject only to
   editorial considerations and to verification that there has been
   adequate coordination with the standards process (see below).

So we consider that the "Experimental" type is more suitable here.
[/zongpeng]

-7: I agree with Kathleen's comments about the security considerations.

[zongpeng] 
We have answered the comments from Kathleen, and made some changes to the section 7.  Security Considerations.
[/zongpeng]

Editorial Comments and Nits:

- The abbreviations that were expanded in the abstract should be expanded again on the body.

[zongpeng]
Old:
   Service Providers are deploying very large Wi-Fi deployments (ranging
   from hundreds of thousands of Access Points, APs (referred to as WTPs
   in CAPWAP terminology) to millions of APs.
New:
	Service Providers are deploying very large Wi-Fi network containing 
   hundreds of thousands of Access Points (APs), which are referred to as 
	Wireless Transmission Points (WTPs) in Control and Provisioning of 
	Wireless Access Points (CAPWAP) terminology.

Old:
   o  802.3 Tunnel: All data frames are tunneled to the AC in 802.3
      format.
New:
   o  802.3 Tunnel: All data frames are tunneled to the Access Controller 
      (AC) in 802.3 format.

Old:
   Figure 2 shows a system where the tunnel mode is configured to tunnel
   data frames between the WTP and the AC either using 802.3 Tunnel or
   802.11 Tunnel configurations.  Operators deploy this configuration
   when they need to tunnel the user traffic.  The tunneling requirement
   may be driven by the need to apply policy at the AC or a legal
   requirement to support lawful intercept of user traffic.  This
   requirement could be met in the locally bridged system (Figure 1) if
   the access router implemented the required policy.
New:
	Figure 2 shows a system where the tunnel mode is configured to tunnel
   data frames between the WTP and the AC either using 802.3 Tunnel or
   802.11 Tunnel configurations.  Operators deploy this configuration
   when they need to tunnel the user traffic.  The tunneling requirement
   may be driven by the need to apply policy at the AC or a legal
   requirement to support lawful intercept of user traffic.  This
   requirement could be met in the locally bridged system (Figure 1) if
   the Access Router (AR) implemented the required policy.

[/zongpeng]

-1, paragraph after figure 1: Missing article before the first occurrence of "CAPWAP".

[zongpeng] 
I think the first one of the modifications above can solve the problem. Is it OK?
[/zongpeng]

-1.3, first sentence: " Service Provider's " should either be " Service Providers' " or "the Service Provider's


[zongpeng] 
Agree. We prefer the " Service Providers' ". Thanks.
[/zongpeng]


-2, 3rd paragraph after figure 5: Missing article before WTP (multiple occurrences).
[zongpeng] 
If we have modified it in the section 1, I think it would be ok to use the WTP directly here. Can you agree?
[/zongpeng]