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

[Warren Kumari]

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  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 <​http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>
> 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
> 

[Gen-art] Gen-ART IETF Last Call review for draft-ietf-stox-7248bis-12

[Ralph Droms]

I am the assigned Gen-ART reviewer for draft-ietf-stox-7248bis-12. 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 

. 

Document: draft-ietf-stox-7248bis-12
Reviewer: Ralph Droms
Review Date: 2016-10-21
IETF LC End Date:  2016-10-06
IESG Telechat date: 2016-11-03

Summary: Ready for publication as a Proposed Standard

I apologize for the late submission of this review.

I am not well-versed in either SIP or XMPP, so I could only give the
technical content of the document a cursory review.  I found no
issues to report in that review.

I'll make two small editorial suggestions:

1) There are possibly anachronistic references to "this series" of
documents.  The members of that "series" will be less obvious with the
publication of rfc7248bis.  It would likely be helpful to list the
members of the document series explicitly.

2) It might be useful to add a short section on the history of the
document, to give readers of this document an understanding of the
motivation for the publication of 7248bis.

- Ralph Droms

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Paul Kyzivat]

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 
<​http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.


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):

Re: [Gen-art] Gen-ART telechat review of draft-ietf-l3sm-l3vpn-service-model-17

[stephane.litkowski]

Hi Brian,

I missed this point in my updates. Sorry for that, next version will take it 
into account.

Brgds,


-Original Message-
From: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com] 
Sent: Friday, October 21, 2016 05:42
To: draft-ietf-l3sm-l3vpn-service-model@ietf.org; General Area Review Team
Subject: Gen-ART telechat review of draft-ietf-l3sm-l3vpn-service-model-17

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-l3sm-l3vpn-service-model-17.txt
Reviewer: Brian Carpenter
Review Date: 2016-10-21
IETF LC End Date: 2016-10-11
IESG Telechat date: 2016-10-27

Summary: Almost ready


Comments:
-

Thanks for responding to my LC comments. I have not checked the details of the 
yang.

Minor Issues:
-

This is a point I missed originally but I mentioned it during the discussion:
The model says:

  | | |   | | +--rw match-flow
  | | |   | |   +--rw dscp?inet:dscp
  | | |   | |   +--rw tos? uint8

but tos was obsoleted when dscp was defined by RFC 2474. I don't think you 
should include tos. You don't mention ECN, which are the two bits from tos that 
are not included in dscp. Those bits are no good for flow matching because they 
are variable.  If an operator tries to use the 8 TOS bits for flow matching but 
a user supports ECN, the matching will not work consistently. So I think it's 
misleading to include this.

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art