Re: [Gen-art] Gen-ART Last Call review of draft-ietf-opsawg-capwap-alt-tunnel-08
"Sri Gundavelli (sgundave)" <sgundave@cisco.com> Fri, 30 September 2016 22:17 UTC
Return-Path: <sgundave@cisco.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBE87127735; Fri, 30 Sep 2016 15:17:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.837
X-Spam-Level:
X-Spam-Status: No, score=-16.837 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 iGx0fdMTgsZB; Fri, 30 Sep 2016 15:17:01 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8277E1200DF; Fri, 30 Sep 2016 15:17:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12316; q=dns/txt; s=iport; t=1475273821; x=1476483421; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=pca+9oQdoclDQH/fjF83fXuzJPZ3zWzCTmk9PywGEbo=; b=gnla6eLfwStaOGSLUm9sZMehLJxzrZp4cX3v3uZ8AanYNPu3GT90N0H0 GEoyK1QUVCSBncpLQ01JVNhjk8nXOeYhsVQ0gQKPsZehgn2XAMhi/2NKZ xGV0yUMoosQ/Tkz7jb8nQXpbPRWiwGvhRxuQ4D/Cwyf7SJMq3rWn3Hrjr E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0D8AQD/4u5X/5ldJa1dDgwBAQEBAgEBAQEIAQEBAYM9AQEBAQEeVy1PAQaNK5Z+lCOCBiSFegIcgUI4FAECAQEBAQEBAV4nhGIBAQQdBhEzEhACAQgOBgYCJgICAjAVEAIEAQ0FiE0OrwOMZwEBAQEBAQEBAQEBAQEBAQEBAQEBARyBB4UxhFWEW4JtgloFjjaLQgGGJolKgW5OhBiJHoxug30BHjaEUDtyAYZ6gQABAQE
X-IronPort-AV: E=Sophos;i="5.31,423,1473120000"; d="scan'208";a="330172237"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Sep 2016 22:17:00 +0000
Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u8UMH0uQ019204 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 30 Sep 2016 22:17:00 GMT
Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 30 Sep 2016 17:16:59 -0500
Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1210.000; Fri, 30 Sep 2016 17:16:59 -0500
From: "Sri Gundavelli (sgundave)" <sgundave@cisco.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, "draft-ietf-opsawg-capwap-alt-tunnel.all@ietf.org" <draft-ietf-opsawg-capwap-alt-tunnel.all@ietf.org>
Thread-Topic: Gen-ART Last Call review of draft-ietf-opsawg-capwap-alt-tunnel-08
Thread-Index: AQHSG2enUnaz1pDbw0WXnFGoHeeQAqCSeGEA
Date: Fri, 30 Sep 2016 22:16:59 +0000
Message-ID: <D41431F8.21B2DD%sgundave@cisco.com>
References: <e529d886-eefe-bf21-7bef-99c2add33abf@alum.mit.edu>
In-Reply-To: <e529d886-eefe-bf21-7bef-99c2add33abf@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.6.5.160527
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.154.162.89]
Content-Type: text/plain; charset="utf-8"
Content-ID: <EBB464EA4C696F4199FF24C007A674FB@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/atvFvScvHy0IJRFpWo-Wt0G7POA>
Cc: General Area Review Team <gen-art@ietf.org>
Subject: Re: [Gen-art] Gen-ART Last Call review of draft-ietf-opsawg-capwap-alt-tunnel-08
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Sep 2016 22:17:04 -0000
Hi Paul, Thanks for the review and the feedback. I agree with your comment that we could have organized the document better. Its many thing and bad starting point that put us here. I tried to do that but was not ready to make so much changes. But, I will try again to see if I can address your comment and resolve the issue to your satisfaction. Regards Sri On 9/30/16, 3:11 PM, "Paul Kyzivat" <pkyzivat@alum.mit.edu> wrote: >I am the assigned Gen-ART reviewer for this draft. The General Area >Review Team (Gen-ART) reviews all IETF documents being processed by the >IESG for the IETF Chair. Please treat these comments just like any other >last call comments. For more information, please see the FAQ at ><http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > >Document: draft-ietf-opsawg-capwap-alt-tunnel-08 >Reviewer: Paul Kyzivat >Review Date: 2016-09-30 >IETF LC End Date: 2016-09-30 >IESG Telechat date: Not yet > >Summary: > >This draft is on the right track but has open issues, described in the >review. > >General Impression: I was able to generally understand what this >document is trying to do, and the details generally seem to be there. >But I was unable to put all the pieces together to make the entire thing >work. I think this is due to problems with the organization of the >document and possibly some missing pieces of information. I feel this >document needs some reorganization if it is to be understood by somebody >new to it. > >Issues: > >Major: 5 >Minor: 9 >Nits: 0 > >(NOTE: I had a lot of trouble classifying the level of the issues. I >finally decided to classify the Major if there is insufficient >information to do an implementation. But take these classifications with >a grain of salt.) > >(1) MINOR: Normative language: > >This document clearly intends to use normative language - there are >numerous occurrences of "MUST". However I also find a number of uses of >"shall" (never upper case) that appear to me to be intended as normative >statements. > >(2) MINOR: Figure 4: > >This figure shows the WTP having two distinct Alternate Tunnels for >SSID1. This seems to imply that data traffic to/from SSID1 be classified >and routed to one or the other of these two tunnels. But I could find no >discussion of any logic for doing this. > >(3) MAJOR: Section 3 (Protocol Considerations): > >This section has some organizational problems that make the document >difficult to. This is hinted at by the very vague title. > >It defines three new CAPWAP message Elements, to be included in certain >CAPWAP messages: > >- Supported Alternate Tunnel Encapsulations: is intended for inclusion >in a CAPWAP Join Request from a WTP to an AC. > >- Alternate Tunnel Encapsulations: is intended for inclusion in an IEEE >802.11 WLAN Configuration Request message from an AC to a WTP. > >- IEEE 802.11 WTP Alternate Tunnel Failure Indication: is intended for >inclusion in a CAPWAP messages from a WTP to an AC. The message type(s) >that should carry this were unclear to me, though probably evident to >someone familiar with CAPWAP. > >An extensible set of Alternate Tunnel Encapsulation types is defined. >These are referenced by both Supported Alternate Tunnel Encapsulations >and Alternate Tunnel Encapsulations. > >Each of these requires specification of an Information Element used to >configure it. The document defines only three of the these. (The >definition of the others is deferred to future documents.) The >definitions of these are also direct subsections of section 3, though >they are a very different sort of thing than the earlier subsections. > >Of these three, two are quite simple and understandable. The third (GRE) >appears to be very complex, with nested sub-elements. I was unable to >fully decipher this. (More below.) > >(4) MINOR: Section 3.2 (Alternate Tunnel Encapsulations Type): > >Section 3.1 shows the Tunnel-Type being carried in an 8-bit field, while >section 3.2 uses a 16-bit field. The actual values are defined in >section 3.2 and include only values 0-6, with other values reserved for >future use. The IANA Considerations section defines this as a 16-bit >value. > >It might be wise to restrict this to 8-bits in the IANA considerations, >and in section 3.2 reserve the first 8 bits of the type field, as in: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 0 | Tunnel-Type | Info Element Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Info Element > +-+-+-+-+-+-+-+-+-+ > >While this section defines a new registry of tunnel types, and formats >for descriptive information element about each, there seem to be no >rules for defining new values. > >Also, I had trouble figuring out which portions of this document are >defining Information Elements for use in this message, and which are >defining something else. It would help if the description of each tunnel >type in the list in this section had a cross reference to the section >that defines the Information Element for that type. (But a more major >reorganization would be better.) > >(5) MAJOR: Section 3.4 (CAPWAP based Alternate Tunnel): > >For the CAPWAP Transport Protocol Element the description mentions two >possible values (UDP and UDP-Lite), but fails to state what encoding is >used to designate them. > >(6) MAJOR: Section 3.6 (GRE based Alternate Tunnel): > >Based on section 3.2, I was expecting the definition of *one* >information element format for GRE tunnels. But this section says "The >information element*s* needed for supporting this mode are defined in >Section 3.7 and Section 3.7.6." and proceeds to define more than one. >And referencing both 3.7 and 3.7.6 seems at least odd. I suspect the >reference to 3.7.6 is a mistake because there seems nothing special >about it. > >(7) MAJOR: Section 3.7 (Alternate Tunnel Information Elements): > >It appears that sections 3.7.n define sub-elements of an overall GRE >Information Element, but I find no definition of that overall element. > >(8) MINOR: Section 3.7.1 (Access Router Information Elements): > >This says: "The AR information may be IPv4 address, IPv6 address, or AR >domain name." Then it has subsections defining IPv4 and IPv6 addresses. >But I can find nothing that says how to specify a domain name. > >(9) MAJOR: Section 3.7.1.1 (AR IPv4 List Element): > >This section seems to call for a constant value designating "AR IPv4 >Element Type" but I find no specification of what that value might be. > >(10) MAJOR: Section 3.7.1.2 (AR IPv6 List Element): > >This section seems to call for a constant value designating "AR IPv6 >Element Type" but I find no specification of what that value might be. > >(11) MAJOR: Section 3.7.2 (IEEE 802.11 WLAN Configuration Response): > >I thought this section should be defining part of the Information >Element for the Alternate Tunnel Encapsulation Type message element from >the AC to the WTP. Yet this section says that it is intended to be sent >from the WTP the the AC. This left me scratching my head as to what it >is and where it goes. > >(12) MAJOR: Section 3.7.3 (Tunnel DTLS Policy Element): > >I don't understand where this element is intended to be inserted. > >The title of this section is "Tunnel DTLS Policy Element", but in figure >13 the type field is called "Tunnel DTLS Element Type". Why are these >different? Also, I find no defined numeric value for this field. > >(13) MAJOR: Section 3.7.4 (IEEE 802.11 Tagging Mode Policy Element): > >This references the 802.11 Tagging Mode Policy in RFC5416. But I was >unable to decipher how that relates to the Alternate Tunnel >Encapsulation Type message. > >(14) MINOR: Section 4 (IANA Considerations): > >This asks IANA to create a new registry of Alternate tunnel types. The >only values in the registry for each type are the numeric value, a human >friendly name, and a reference. The references are to the definitions of >the underlying tunnel protocols. > >I understand, this isn't sufficient information to use these values. It >is also necessary to know the format of the associated Information >Element for each type. For *some* of the types that information is >present in this document. For others that information is left for future >definition, presumably in some new document. > >The registry needs to have a reference to a document specifying the >format of the Information Element for the type. > >Also, it would be very helpful if there was a template for how to >specify the Information Element for a type, and for this document to >follow that format for the ones it defines. >
- [Gen-art] Gen-ART Last Call review of draft-ietf-… Paul Kyzivat
- Re: [Gen-art] Gen-ART Last Call review of draft-i… Sri Gundavelli (sgundave)
- [Gen-art] Gen-ART Telechat review of draft-ietf-o… Paul Kyzivat
- Re: [Gen-art] Gen-ART Telechat review of draft-ie… Warren Kumari
- [Gen-art] Gen-ART Last Call review of draft-ietf-… Paul Kyzivat
- Re: [Gen-art] Gen-ART Last Call review of draft-i… Duzongpeng
- Re: [Gen-art] Gen-ART Last Call review of draft-i… Duzongpeng
- Re: [Gen-art] Gen-ART Last Call review of draft-i… Paul Kyzivat
- Re: [Gen-art] Gen-ART Last Call review of draft-i… Warren Kumari
- Re: [Gen-art] Gen-ART Last Call review of draft-i… Paul Kyzivat
- Re: [Gen-art] Gen-ART Last Call review of draft-i… Duzongpeng
- Re: [Gen-art] Gen-ART Last Call review of draft-i… Paul Kyzivat
- [Gen-art] Gen-ART Telechat review of draft-ietf-o… Paul Kyzivat
- Re: [Gen-art] Gen-ART Telechat review of draft-ie… Tianran Zhou
- Re: [Gen-art] Gen-ART Telechat review of draft-ie… Alissa Cooper