Re: [Gen-art] Gen-ART Telechat review of draft-ietf-opsawg-capwap-alt-tunnel-08

Warren Kumari <> Fri, 21 October 2016 21:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5D8C512964D for <>; Fri, 21 Oct 2016 14:04:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WBijCpoQ6JZ7 for <>; Fri, 21 Oct 2016 14:04:23 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c0d::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 03C87129640 for <>; Fri, 21 Oct 2016 14:04:22 -0700 (PDT)
Received: by with SMTP id m5so96182197qtb.3 for <>; Fri, 21 Oct 2016 14:04:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mr//l3UO6avzsuZRlT0otz4GuMfk/nJPdmB8lHqjJUg=; b=E7G1lyBUPvDmD4MNd1H9EJ1K+y+fIYWIUfOGOr49oUeYc+bZBaUVfjFLipXYHFyZAP RkaEZ+bxnv3L1efReDXHmBJxuReUxcOP8LmFxQfHx+3SkG3qBgfkcX6tIZiIMG6yYcKp +VzvUwwyWdr7P/UljG3EKTkmLOg6xrnIy3qGGmA7kElTmC7pH+QfJejhyrBdguAADXQU 46DFZDnwgx4URvwnN7sZCwPmaNCCnT6+zmYNHictSTzhdb4rlk3dQgf5ECq0LZ5lJN+G +1hCD+FG1qErqiIYBdt+8hfAVIg/xjnwMtZbt6P+eIb5S7e0Bmc5dZjSlg9SW+gENaDM 9Ytg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mr//l3UO6avzsuZRlT0otz4GuMfk/nJPdmB8lHqjJUg=; b=h2kG1Ibf6EWNtTEyrGCYUw8dMHepPXC+yM0kRN3qMy9yXcuRspDmF9KdsJ+ryK3uWk 4KJLXEJ+Rf5+VJ9Oa/NWd+fDO3+jU/3YFurzLE7S1eA7eIA9x/7TXybSln/usKghVo8I +QiSYqVqOtgwSaMb+UiJEC5yrMiZdNHj1fxS6QzhmwPIGcaOVT6AlbpkrCU3YyUjhKz6 Hrvzx5bw+n/g55ScVkhubmWvEOZ1hVGINM/I8AC0UJpNZT+sL1xHwFuB96185B0OGqY4 OrVqFeOTV/QdEBkkl1A/47Wph6htPEcNN5OAabZwEcPrCTMb1QWN6+omr4tbcat7EaZL wphg==
X-Gm-Message-State: ABUngvdU/7v6+MTZ2Q0zkWfsqrgfo+zf8+9x5bTfw2CnqI1cA5r7W4fdibT/gaFZSghMIIfYWlIg1cTIc04q+XuD
X-Received: by with SMTP id p28mr3532081qte.62.1477083861986; Fri, 21 Oct 2016 14:04:21 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 21 Oct 2016 14:04:21 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Warren Kumari <>
Date: Fri, 21 Oct 2016 17:04:21 -0400
Message-ID: <>
To: Paul Kyzivat <>
Content-Type: multipart/alternative; boundary="94eb2c190964e5c5cf053f666218"
Archived-At: <>
Cc: General Area Review Team <>, "" <>
Subject: Re: [Gen-art] Gen-ART Telechat review of draft-ietf-opsawg-capwap-alt-tunnel-08
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 21 Oct 2016 21:04:26 -0000

A very quick note (I'm on a plane, door about to close).

We recognize that this document has issues; the primary author has become
busy with other stuff, and many of the other authors have changed companies
/ roles. The chairs are finding some additional authors to provide

Your comments are important / will be addressed, but it may take some time
(or we may end up having to abandon the document, which would be sad).


On Friday, October 21, 2016, Paul Kyzivat <> 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 wait for direction from your document shepherd or AD
> before posting a new version of the draft. For more information, please see
> the FAQ at <​>.
> Document: draft-ietf-opsawg-capwap-alt-tunnel-08
> Reviewer: Paul Kyzivat
> Review Date: 2016-10-21
> IETF LC End Date: 2016-09-30
> IESG Telechat date: 2016-10-27
> Summary:
> (Note: the document is unchanged since last call, so this is a repeat of
> my last-call review.)
> 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 (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 (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.

I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of