[Gen-art] Genart last call review of draft-ietf-tls-tls13-24

[Dale Worley]

Reviewer: Dale Worley
Review result: Ready with Nits

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
.

Document:  draft-ietf-tls-tls13-24
Reviewer:  Dale R. Worley
Review Date:  2018-03-02
IETF LC End Date:  2018-03-02
IESG Telechat date:  2018-03-08

Summary:

   This draft is basically ready for publication, but has nits
   that should be fixed before publication.

This review only covers the general properties of the proposed
protocol and the exposition, as I am unqualified to assess its
security properties.

There are various places where the exposition could be made clearer,
especially to readers not immersed in security matters.  In many
places, it is mostly a matter of making clearer the connections
between different points in the exposition.

In a few places, there seems to be ambiguity regarding the
specification that has technical significance.  In particular:

- There is inexactness about "transcript", "handshake context", and
  "context".

- When a server receives ClientHello, is it obligated to promptly send
  not just the ServerHello, but all first-flight messages from
  ServerHello through Finished?  (section 4.2.11.3)  I ask this
  because the client is only obligated/permitted to send
  EndOfEarlyData when it receives the server's Finished.

- It seems inconsistent that the client can send an empty Certificate
  message, but the server cannot, even though the server can omit
  sending the Certificate message.  (section 4.4.2.4)

- Comparing sections 4.2.10 and 4.6.1, when a PSK was established in
  an earlier connection, exactly what are the limitations on the
  cryptographic parameters that can be used when the PSK is used in a
  resumption connection?  4.2.10 suggests that the following must be
  the same in both connections:  TLS version, cipher suite, ALPN.  But
  4.6.1 suggests that different cipher suites can be used, as long as
  they use the same hash algorithm.

- In regard to section 4.6.1, it seems to require that a client MAY
  NOT resume a connection using a ticket issued during a connection in
  which the server did not present a certificate for itself, because
  in the handshake of the resumption connection, the client is required
  to verify that the SNI is compatible with the certificate the server
  presented in the original connection.  But that constraint isn't
  stated in section 2.2, despite being a global constraint on the
  structure of sessions.

- Presumably implementations MUST NOT send zero-length fragments of alert
  messages for the same reasons that they cannot send zero-length
  fragments of handshake messages (whatever those reasons are).

- There are about 28 error codes but nearly 150 places where the text
  require the connection to be aborted with an error -- and hence,
  nearly 150 distinct constraints that can be violated.  There are 19
  alone for "illegal_parameter".  I would like to see an "alert
  extension value" which assigns a distinct "minor" code to each
  statement in the text that requires an error response (with
  implementations being allowed to be a bit sloppy in providing the
  correct minor code).

- I take it that there is no "close read side" operation.  (If that
  existed, TLS could generate the "broken pipe" error.)

There are a number of issues which span the whole text:

The interaction of this draft with extensions defined for previous
versions of TLS is not laid out clearly.  It seems safe enough for
this draft to import data structures from earlier extensions with only
a reference to the earlier RFC, but if an extension defines behavior
(e.g., a negotiation process), exactly what is the specification of
that behavior in TLS 1.3, given that the referenced RFC only defines
its use in TLS 1.2 or earlier?  At the least, there should be an
explicit statement that the behaviors are carried forward in the
"obvious way".

It's also not clear exactly which previously defined extensions are
brought forward into TLS 1.3.  I suspect that they are all listed in
section 4.2, but is it clearly stated that those, and only those, are
grandfathered in?

Presumably, for any referenced extension, the placement of values in
messages in TLS 1.2 has a "natural" analog in TLS 1.3 that at most
involves moving the value from one field to another in certain
messages.  But it would be reassuring to have a clear statement of
this, and an enumeration of any more complex cases.

There are about 28 error codes but nearly 150 places where the text
require the connection to be aborted with an error.  There are 19
alone for "illegal_parameter".  I would like to see an "alert
extension value" which assigns a distinct "minor" code to each
statement in the text that 

[Gen-art] Genart telechat review of draft-ietf-trill-multi-topology-05

[Brian Carpenter]

Reviewer: Brian Carpenter
Review result: Ready

Gen-ART Last Call + Telechat review of draft-ietf-trill-multi-topology-05

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
.

Document: draft-ietf-trill-multi-topology-05.txt
Reviewer: Brian Carpenter
Review Date: 2018-03-02
IETF LC End Date: 2018-03-06
IESG Telechat date: 2018-03-08

Summary: Ready


Comment:


This is a rushed review for reasons outside my control. Also, only
a TRILL expert could review it effectively. As far as I can tell,
it's a well written document.

This is a case where I wish RFC1264 still applied. I'm disappointed
not to see an RFC 7942 Implementation Status section.



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

[Gen-art] Genart telechat review of draft-ietf-trill-transport-over-mpls-07

[Stewart Bryant]

Reviewer: Stewart Bryant
Review result: Ready with Issues

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-trill-transport-over-mpls-07
Reviewer: Stewart Bryant
Review Date: 2018-03-02
IETF LC End Date: 2018-03-06
IESG Telechat date: 2018-03-08

Summary: An understandable document. The only comment of note is the conflation
of PW headers and MPLS headers. There are a couple of easy to fix nits.

Major issues: None

Minor issues:

6. Packet Processing Between Pseudowires

 In this section you conflate PW headers and MPLS headers.
The PW label is a type of  MPLS label, although it has its own forwarding
instruction, but the control word is not part of MPLS.

Nits/editorial comments:

There is an ASCII art error in Fig 1 on the line containing Tenant1 Site1

The terms PE device and PE router seem to be used interchangeably.  Is this an
error, or are they distinct devices.

The VTSD must be capable of forming TRILL adjacency with the
SB> Should be "forming a TRILL adjacency"


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

[Gen-art] Genart telechat review of draft-ietf-i2rs-rib-data-model-10

[Stewart Bryant]

Reviewer: Stewart Bryant
Review result: Ready

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-i2rs-rib-data-model-10
Reviewer: Stewart Bryant
Review Date: 2018-03-02
IETF LC End Date: 2018-03-30
IESG Telechat date: 2018-04-05

Summary: Read this from the perspective of a generalist rather that as a
routing specialist in the expectation that other routing specialist would read
the YANG model in detail and compare it to the text and there experience of
operational routers. From that perspective this seems ready to be published.

Major issues: None

Minor issues: None

Nits/editorial comments: None


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

Re: [Gen-art] Gen-art LC Review of draft-ietf-anima-autonomic-control-plane-13

[Elwyn Davies]

Just taking up one point for the time being  
Even if the reference model is informational, I was relying on RFC 8067, s1, 
para 3:
   Section 2 of [RFC3967] lists some conditions under which downrefs may
   make sense.  In addition to those, it has become common for working
   groups to produce foundational documents (which contain important
   information such as terminology definitions and architectural design
   and considerations) at Informational status, and those documents are
   often needed as normative references in the Standards Track protocol
   documents that follow. 
I would say that sombody implementing ACP really needs to have read and 
understood the reference model and so I would argue:1. That it needs to be 
normative,and2. The downref is sanctioned by the language in RFC 8067. 
I am on holiday for a week and others are fighting the draft deadline so 
perhaps we can postpone discussion of the other points until the draft panic 
has subsided.
Cheers,Elwyn
Sent from Samsung tablet.
 Original message From: Brian E Carpenter 
 Date: 01/03/2018  02:45  (GMT+01:00) To: Elwyn 
Davies , gen-art@ietf.org Cc: 
draft-ietf-anima-autonomic-control-plane@ietf.org Subject: Re: [Gen-art] 
Gen-art LC Review of
  draft-ietf-anima-autonomic-control-plane-13 
Replying as a protagonist -

First thanks for the really thorough review with many good points.

Now a few replies in-line:

On 28/02/2018 15:24, Elwyn Davies wrote:
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> you need a stand-by generator, you need a stand-by
enrollment server).


 
> s15.2: I think some of these references are normative:
> especially  ietf-anima-reference-model, 

Definitely not, it's an informational document.

Regards
    Brian

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

[Gen-art] Genart last call review of draft-ietf-rmcat-sbd-10

[Dan Romascanu]

Reviewer: Dan Romascanu
Review result: Almost Ready

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

.

Document: draft-ietf-rmcat-sbd-10
Reviewer: Dan Romascanu
Review Date: 2018-03-01
IETF LC End Date: 2018-03-16
IESG Telechat date: 2018-04-05

Summary:

Almost Ready

This is an interesting and well-written document. The method described in the
document have a proposed status of Experimental that seems appropriate, and I
liked the fact that the expected feedback from the experiments is mentioned in
Section 6. I believe that the document is almost ready for publication from the
Gen-ART perspective, but lacks reference and relation to existing work in the
IETF related to the definitions and measurement methods for metrics like packet
loss or one-way delay. Adding this information would make clear what is
currently missing and why this work is needed.

Major issues:

1. The document does not refer or relate to existing work in the IETF. Metrics
like packet loss or one-way-delay have been defined in IETF WGs like IPPM and
dealt with in real-time applications context by XRBLOCK. For example Packet
Loss is defined by  RFC 2680, OWD by RFC 7679. Are these applicable? What is
missing and why new work is necessary? I assume that there are good answers to
these questions, but these are not included in the document.

Minor issues:

1. It would be useful to explain what the authors mean in this document by
'signal' as the usage of the term is different than in other context. For
example in section 1.2, or more specifically in section 1.2.1 where a sentence
like 'Packet loss is often a relatively rare signal.' is hard to understand
without such context explanation.

Nits/editorial comments:

1. Several acronyms are not expanded at first occurrence - for example, but not
limited to: RTP, ECN, etc.


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

Re: [Gen-art] Genart early review of draft-ietf-opsawg-ipfix-bgp-community-04

[Dongjie (Jimmy)]

Hi Ignas,

Thanks a lot for the suggestion.

The authors will work together to resolve the comments received and provide 
further clarification on the operational aspects.

Also we will try to collect more feedbacks from the operator communities and 
incorporate them into the next revision.

Some operators have joined the recent discussion on this list and gave valuable 
feedbacks (many thanks!). More feedbacks are always welcome.

Best regards,
Jie

From: Ignas Bagdonas [mailto:ibagd...@gmail.com]
Sent: Friday, March 02, 2018 12:59 AM
To: li zhenqiang ; Joel Halpern Direct 
; Dongjie (Jimmy) ; 
gen-art@ietf.org
Cc: draft-ietf-opsawg-ipfix-bgp-community@ietf.org; opsawg 
Subject: Re: Genart early review of draft-ietf-opsawg-ipfix-bgp-community-04


Dear authors of draft-ietf-opsawg-ipfix-bgp-community document,

This document is a WG document, and you have received community feedback on it 
stating that there are unclear aspects and questionable approaches described in 
it. Please address the comments to have the document cover the concerns raised.

The comments specifically on the operational aspects of how this proposed 
mechanism is expected to be used tend to repeat - this seems to be an area that 
is not clear to the community. Please focus on addressing it in substantial 
detail.

It would be beneficial to bring this document to the attention of the 
operations community too (as any other document - there is nothing specific to 
your document in this regard). Try to talk to Apricot, RIPE, NANOG, regional 
NOGs communities to sense the need and the details of this proposed mechanism, 
and then incorporate the feedback received there to the document.

Thank you.

Ignas



On 01/03/2018 15:39, li zhenqiang wrote:
Hi Joel,

Thank you for your prompt reply and sorry for the confusing words.

Let me try to explain it clearly in simple words again. BGP community 
attributes, such as standard community, extended community, large community, 
have already  been defined by IDR working group. Operaters use those already 
defined BGP communities in their field networks with their own plans to 
represent the groups of customers, peers, geographical and topological regions. 
For example, using standard community XXX to represent fixed line customers,  
YYY for WLAN customers, and ZZZ for mobile customers, using community AAA for 
state L, BBB for state M, CCC for state N. Now we want to know the traffic 
generated by the WLAN customer in state N. So we need the community information 
related to the traffic flow exported by IPFIX. If IPFIX can export BGP 
community information using the IEs introduced in my doc, the  IPFIX collector, 
without running BGP protocol, can easily figure up the traffic in BGP community 
granularity, i.e. the traffic from different customers, from different states, 
from different customers in different states, and so on.

Best Regards,
Zhenqiang Li

li_zhenqi...@hotmail.com

From: Joel Halpern Direct
Date: 2018-02-28 23:19
To: li zhenqiang; Dongjie 
(Jimmy); gen-art@ietf.org
CC: 
draft-ietf-opsawg-ipfix-bgp-community@ietf.org;
 opsawg
Subject: Re: Genart early review of draft-ietf-opsawg-ipfix-bgp-community-04
I am having trouble reconciling two of your comments.
In you rlast email you said that this is for "planed communities
represent the groups of customers peers an geographical and topological
related information".  Planned communities is presumably a new behavior,
not existing behavior.

In this email you say that these are "already defined BGP communities".

You reference RFC 4384, which talks about several kinds of communities.
maybe you intend the regional or national communities mentioned as being
possible, but not defined, in that document.  This document's
descriptions do not align well enough with RFC 4384 for me to say.

Let's be clear.  The working group asked for an early review.  The WG
now has my review, indicating that this document is unclear in multiple
regards and could use improvement.

It is now up to the WG and the chairs.
Yours,
Joel

On 2/28/18 6:22 AM, li zhenqiang wrote:
> Hi Joel,
>
> This is not for one operator, instead it is a common practice. Please
> refer to RFC4384 and comments from Thomas who are from Swisscom.
>
> One clarification for this doc is it is not to introduce any new BGP
> communities but to report the already defined BGP communities related to
> a traffic flow through IPFIX, thus the IPFIX collector can analyze the
> traffic in BGP community granularity without running BGP protocol.
>
> BGP community is a transitive attibute, thus the exporter can report all
> the communities