MIME-Version: 1.0
In-Reply-To: <f650f9ff-24ff-836f-a2d9-9b8e50b5e43f@alum.mit.edu>
References: <e529d886-eefe-bf21-7bef-99c2add33abf@alum.mit.edu>
 <f650f9ff-24ff-836f-a2d9-9b8e50b5e43f@alum.mit.edu>
From: Warren Kumari <warren@kumari.net>
Date: Fri, 21 Oct 2016 17:04:21 -0400
Message-ID: <CAHw9_iLfCV1cUQOR=bT_GSUdA5RRRO+HcX=n1wf+G8VNyfkgtQ@mail.gmail.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
Content-Type: multipart/alternative; boundary=94eb2c190964e5c5cf053f666218
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/G5G9ko7Oi0Q59wHpzC6LJKi_KIc>
Cc: General Area Review Team <gen-art@ietf.org>,
 "draft-ietf-opsawg-capwap-alt-tunnel.all@ietf.org"
 <draft-ietf-opsawg-capwap-alt-tunnel.all@ietf.org>
Subject: Re: [Gen-art] Gen-ART Telechat review of
 draft-ietf-opsawg-capwap-alt-tunnel-08
Precedence: list

--94eb2c190964e5c5cf053f666218
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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
assistance.

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).

W

On Friday, October 21, 2016, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

> I am the assigned Gen-ART reviewer for this draft. The General Area Revie=
w
> 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 s=
ee
> the FAQ at <=E2=80=8Bhttp://wiki.tools.ietf.org/area/gen/trac/wiki/GenArt=
faq>.
>
> 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 informatio=
n
> 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 an=
d
> 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 definiti=
on
> of the others is deferred to future documents.) The definitions of these
> are also direct subsections of section 3, though they are a very differen=
t
> 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 ful=
ly
> 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 us=
e.
> 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 fo=
r
> 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 tha=
t
> 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 bot=
h
> 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. B=
ut
> 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 t=
o
> the WTP. Yet this section says that it is intended to be sent from the WT=
P
> 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 i=
s
> also necessary to know the format of the associated Information Element f=
or
> 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 forma=
t
> 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.
>


--=20
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
pants.
   ---maf

--94eb2c190964e5c5cf053f666218
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

A very quick note (I&#39;m on a plane, door about to close).<div><br></div>=
<div>We recognize that this document has issues; the primary author has bec=
ome busy with other stuff, and many of the other authors have changed compa=
nies / roles. The=C2=A0chairs are finding some additional authors to provid=
e assistance.=C2=A0</div><div><br></div><div>Your comments are important / =
will be addressed, but it may take some time (or we may end up having to ab=
andon the document, which would be sad).</div><div><br></div><div>W<span></=
span><br><br>On Friday, October 21, 2016, Paul Kyzivat &lt;<a href=3D"mailt=
o:pkyzivat@alum.mit.edu">pkyzivat@alum.mit.edu</a>&gt; wrote:<br><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex">I am the assigned Gen-ART reviewer for this draft. The=
 General Area Review Team (Gen-ART) reviews all IETF documents being proces=
sed by the IESG for the IETF Chair. Please wait for direction from your doc=
ument shepherd or AD before posting a new version of the draft. For more in=
formation, please see the FAQ at &lt;=E2=80=8B<a href=3D"http://wiki.tools.=
ietf.org/area/gen/trac/wiki/GenArtfaq" target=3D"_blank">http://wiki.tools.=
ietf.org/a<wbr>rea/gen/trac/wiki/GenArtfaq</a>&gt;.<br>
<br>
Document: draft-ietf-opsawg-capwap-alt-t<wbr>unnel-08<br>
Reviewer: Paul Kyzivat<br>
Review Date: 2016-10-21<br>
IETF LC End Date: 2016-09-30<br>
IESG Telechat date: 2016-10-27<br>
<br>
Summary:<br>
<br>
(Note: the document is unchanged since last call, so this is a repeat of my=
 last-call review.)<br>
<br>
This draft is on the right track but has open issues, described in the revi=
ew.<br>
<br>
General Impression: I was able to generally understand what this document i=
s trying to do, and the details generally seem to be there. But I was unabl=
e to put all the pieces together to make the entire thing work. I think thi=
s is due to problems with the organization of the document and possibly som=
e missing pieces of information. I feel this document needs some reorganiza=
tion if it is to be understood by somebody new to it.<br>
<br>
Issues:<br>
<br>
Major: 5<br>
Minor: 9<br>
Nits:=C2=A0 0<br>
<br>
(NOTE: I had a lot of trouble classifying the level of the issues. I finall=
y decided to classify the Major if there is insufficient information to do =
an implementation. But take these classifications with a grain of salt.)<br=
>
<br>
(1) MINOR: Normative language:<br>
<br>
This document clearly intends to use normative language - there are numerou=
s occurrences of &quot;MUST&quot;. However I also find a number of uses of =
&quot;shall&quot; (never upper case) that appear to me to be intended as no=
rmative statements.<br>
<br>
(2) MINOR: Figure 4:<br>
<br>
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 route=
d to one or the other of these two tunnels. But I could find no discussion =
of any logic for doing this.<br>
<br>
(3) MAJOR: Section 3 (Protocol Considerations):<br>
<br>
This section has some organizational problems that make the document diffic=
ult to. This is hinted at by the very vague title.<br>
<br>
It defines three new CAPWAP message Elements, to be included in certain CAP=
WAP messages:<br>
<br>
- Supported Alternate Tunnel Encapsulations: is intended for inclusion in a=
 CAPWAP Join Request from a WTP to an AC.<br>
<br>
- Alternate Tunnel Encapsulations: is intended for inclusion in an IEEE 802=
.11 WLAN Configuration Request message from an AC to a WTP.<br>
<br>
- IEEE 802.11 WTP Alternate Tunnel Failure Indication: is intended for incl=
usion in a CAPWAP messages from a WTP to an AC. The message type(s) that sh=
ould carry this were unclear to me, though probably evident to someone fami=
liar with CAPWAP.<br>
<br>
An extensible set of Alternate Tunnel Encapsulation types is defined. These=
 are referenced by both Supported Alternate Tunnel Encapsulations and Alter=
nate Tunnel Encapsulations.<br>
<br>
Each of these requires specification of an Information Element used to conf=
igure it. The document defines only three of the these. (The definition of =
the others is deferred to future documents.) The definitions of these are a=
lso direct subsections of section 3, though they are a very different sort =
of thing than the earlier subsections.<br>
<br>
Of these three, two are quite simple and understandable. The third (GRE) ap=
pears to be very complex, with nested sub-elements. I was unable to fully d=
ecipher this. (More below.)<br>
<br>
(4) MINOR: Section 3.2 (Alternate Tunnel Encapsulations Type):<br>
<br>
Section 3.1 shows the Tunnel-Type being carried in an 8-bit field, while se=
ction 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. Th=
e IANA Considerations section defines this as a 16-bit value.<br>
<br>
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:<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A01=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A02=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A03<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 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<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<wbr>+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-<wbr>+-+-+<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A00=C2=A0 =C2=A0 =C2=
=A0|=C2=A0 Tunnel-Type=C2=A0 |=C2=A0 Info Element Length=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 |<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<wbr>+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-<wbr>+-+-+<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0Info Element<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+<br>
<br>
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 d=
efining new values.<br>
<br>
Also, I had trouble figuring out which portions of this document are defini=
ng Information Elements for use in this message, and which are defining som=
ething else. It would help if the description of each tunnel type in the li=
st in this section had a cross reference to the section that defines the In=
formation Element for that type. (But a more major reorganization would be =
better.)<br>
<br>
(5) MAJOR: Section 3.4 (CAPWAP based Alternate Tunnel):<br>
<br>
For the CAPWAP Transport Protocol Element the description mentions two poss=
ible values (UDP and UDP-Lite), but fails to state what encoding is used to=
 designate them.<br>
<br>
(6) MAJOR: Section 3.6 (GRE based Alternate Tunnel):<br>
<br>
Based on section 3.2, I was expecting the definition of *one* information e=
lement format for GRE tunnels. But this section says &quot;The information =
element*s* needed for supporting this mode are defined in Section 3.7 and S=
ection 3.7.6.&quot; and proceeds to define more than one. And referencing b=
oth 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.<br>
<br>
(7) MAJOR: Section 3.7 (Alternate Tunnel Information Elements):<br>
<br>
It appears that sections 3.7.n define sub-elements of an overall GRE Inform=
ation Element, but I find no definition of that overall element.<br>
<br>
(8) MINOR: Section 3.7.1 (Access Router Information Elements):<br>
<br>
This says: &quot;The AR information may be IPv4 address, IPv6 address, or A=
R domain name.&quot; Then it has subsections defining IPv4 and IPv6 address=
es. But I can find nothing that says how to specify a domain name.<br>
<br>
(9) MAJOR: Section 3.7.1.1 (AR IPv4 List Element):<br>
<br>
This section seems to call for a constant value designating &quot;AR IPv4 E=
lement Type&quot; but I find no specification of what that value might be.<=
br>
<br>
(10) MAJOR: Section 3.7.1.2 (AR IPv6 List Element):<br>
<br>
This section seems to call for a constant value designating &quot;AR IPv6 E=
lement Type&quot; but I find no specification of what that value might be.<=
br>
<br>
(11) MAJOR: Section 3.7.2 (IEEE 802.11 WLAN Configuration Response):<br>
<br>
I thought this section should be defining part of the Information Element f=
or the Alternate Tunnel Encapsulation Type message element from the AC to t=
he WTP. Yet this section says that it is intended to be sent from the WTP t=
he the AC. This left me scratching my head as to what it is and where it go=
es.<br>
<br>
(12) MAJOR: Section 3.7.3 (Tunnel DTLS Policy Element):<br>
<br>
I don&#39;t understand where this element is intended to be inserted.<br>
<br>
The title of this section is &quot;Tunnel DTLS Policy Element&quot;, but in=
 figure 13 the type field is called &quot;Tunnel DTLS Element Type&quot;. W=
hy are these different? Also, I find no defined numeric value for this fiel=
d.<br>
<br>
(13) MAJOR: Section 3.7.4 (IEEE 802.11 Tagging Mode Policy Element):<br>
<br>
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 me=
ssage.<br>
<br>
(14) MINOR: Section 4 (IANA Considerations):<br>
<br>
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 friend=
ly name, and a reference. The references are to the definitions of the unde=
rlying tunnel protocols.<br>
<br>
I understand, this isn&#39;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, presu=
mably in some new document.<br>
<br>
The registry needs to have a reference to a document specifying the format =
of the Information Element for the type.<br>
<br>
Also, it would be very helpful if there was a template for how to specify t=
he Information Element for a type, and for this document to follow that for=
mat for the ones it defines.<br>
</blockquote></div><br><br>-- <br>I don&#39;t think the execution is releva=
nt when it was obviously a bad idea in the first place.<br>This is like put=
ting rabid weasels in your pants, and later expressing regret at having cho=
sen those particular rabid weasels and that pair of pants.<br>=C2=A0 =C2=A0=
---maf<br>

--94eb2c190964e5c5cf053f666218--