Last Call Review of draft-ietf-mpls-residence-time-12

Request Review of draft-ietf-mpls-residence-time
Requested rev. no specific revision (document currently at 15)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2017-01-17
Requested 2017-01-03
Draft last updated 2017-01-11
Completed reviews Rtgdir Early review of -11 by He Jia (diff)
Genart Last Call review of -12 by Robert Sparks (diff)
Secdir Last Call review of -12 by Benjamin Kaduk (diff)
Opsdir Last Call review of -12 by Jürgen Schönwälder (diff)
Secdir Telechat review of -14 by Benjamin Kaduk (diff)
Genart Telechat review of -13 by Robert Sparks (diff)
Genart Telechat review of -14 by Robert Sparks (diff)
Assignment Reviewer Robert Sparks
State Completed
Review review-ietf-mpls-residence-time-12-genart-lc-sparks-2017-01-11
Reviewed rev. 12 (document currently at 15)
Review result Ready with Nits
Review completed: 2017-01-11


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-mpls-residence-time-12
Reviewer: Robert Sparks
Review Date: 2017-01-10
IETF LC End Date: 2017-01-17
IESG Telechat date: 2017-02-02

Summary: Ready (with nits) for publication as a Proposed Standard

I have two primary comments. I expect both are rooted in the authors 
and working group knowing what the document means instead of seeing what
it says or doesn't say:

1) The document is loose with its use of 'packet', and where TTLs appear when
they are discussed. It might be helpful to rephrase the text that speaks
of RTM packets in terms of RTM messages that are encoded as G-ACh messages and
not refer to packets unless you mean the whole encapsulated packet with MPLS
header, ACH, and G-ACh message.

2) Since this new mechanic speaks in terms of fractional nanoseconds, some
discussion of what trigger-point you intend people to use for taking the
precise time of a packet's arrival or departure seems warranted. (The first and
last bit of the whole encapsulated packet above are going to appear at the
physical layer many nanoseconds apart at OC192 speeds if I've done the math
right). It may be obvious to the folks discussing this, but it's not obvious
from the document.  If it's _not_ obvious and variation in technique is
expected, then some discussion about issues that might arise from different
implementation choices would be welcome.

The rest of these are editorial nits:

It would help to pull an overview description of the difference between
one-step and two-step much earlier in the document. I suggest in the overview
in section 2. Otherwise, the reader really has to jump forward and read section
7 before section 3's 5th bullet makes any sense. 

In section 3, "IANA will be asked" should be made active. Say "This document 
asks IANA to" and point to the IANA consideration section. Apply similar 
treatment to the other places where you talk about future IANA actions. 

There are several places where there are missing words (typically articles or
prepositions). You're less likely to end up with misinterpretations during the
RFC Editor phase if you provide them before the document gets that far in the
process. The spots I found most disruptive were these (this is not intended to
be exhaustive): 

  Section 3: "set 1 according" -> "set to 1 according" 
  Section 3: "the Table 19 [IEEE..." -> "Table 19 of [IEEE..."
  Section 4.2: "Detailed discussion of ... modes in Section 7." 
                        -> "Detailed discussion of ... modes appears in Section 7."
  Section 10: "most of" -> "most of all"   

In Setion 3.1 at "identity of the source port", please point into the document
that defines this identity and its representation. I suspect this is a pointer
into a specific section in IEEE.1588.2008].