Last Call Review of draft-ietf-conex-destopt-09
review-ietf-conex-destopt-09-opsdir-lc-bradner-2015-10-09-00

Request Review of draft-ietf-conex-destopt
Requested rev. no specific revision (document currently at 12)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2015-09-29
Requested 2015-08-23
Authors Suresh Krishnan, Mirja Kühlewind, Bob Briscoe, Carlos Ucendo
Draft last updated 2015-10-09
Completed reviews Genart Last Call review of -09 by Robert Sparks (diff)
Genart Last Call review of -09 by Robert Sparks (diff)
Secdir Last Call review of -09 by Robert Sparks (diff)
Opsdir Last Call review of -09 by Scott Bradner (diff)
Assignment Reviewer Scott Bradner 
State Completed
Review review-ietf-conex-destopt-09-opsdir-lc-bradner-2015-10-09
Reviewed rev. 09 (document currently at 12)
Review result Has Nits
Review completed: 2015-10-09

Review
review-ietf-conex-destopt-09-opsdir-lc-bradner-2015-10-09

I did an OPSDIR review of IPv6 Destination Option for Congestion Exposure (ConEx) (draft-ietf-conex-destopt-09).

As an experiment this should have few operational concerns for any network not involved in the experiment but if the 
technology becomes standardized at some later time it will add somewhat to the complexity of configuring network 
devices (i.e. routers).

Bottom line, technology-wise this ID seems ready to publish.

But I do have some comments on the use of rfc 2119 terminology in the ID.

I do not think I’ve seen a case where a document says SHOULD NOT and MAY in the same paragraph referring to the same thing:

   As with any destination option, an ingress tunnel endpoint will not
   natively copy the CDO when adding an encapsulating outer IP header.
   In general an ingress tunnel SHOULD NOT copy the CDO to the outer
   header as this would changed the number of bytes that would be
   counted.  However, it MAY copy the CDO to the outer header in order
   to facilitate visibility by subsequent on-path ConEx functions if the
   configuration of the tunnel ingress and the ConEx nodes is co-
   ordinated.  This trades off the performance of ConEx functions
   against that of tunnel processing.

I suggest that this be reworded to say something like “SHOULD NOT unless xxx, in which case it MAY xxx”

The next paragraph says

   An egress tunnel endpoint SHOULD ignore any CDO on decapsulation of
   an outer IP header.  The information in any inner CDO will always be
   considered correct, even if it differs from any outer CDO.
   Therefore, the decapsulator can strip the outer CDO without
   comparison to the inner.

Why is this a SHOULD rather than a MUST?

imo, SHOULDs should only be used when there is a known reason that an otherwise MUST behavior 
might not be followed – in that case the reason should be explained


Scott