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" <pkyzi...@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 mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
