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]