Last Call Review of draft-ietf-mpls-residence-time-12
review-ietf-mpls-residence-time-12-opsdir-lc-schoenwaelder-2017-01-13-00

Request Review of draft-ietf-mpls-residence-time
Requested rev. no specific revision (document currently at 15)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2017-01-17
Requested 2017-01-03
Draft last updated 2017-01-13
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 Jürgen Schönwälder
State Completed
Review review-ietf-mpls-residence-time-12-opsdir-lc-schoenwaelder-2017-01-13
Reviewed rev. 12 (document currently at 15)
Review result Has Nits
Review completed: 2017-01-13

Review
review-ietf-mpls-residence-time-12-opsdir-lc-schoenwaelder-2017-01-13

I do not see any major OPS related issues. I am not an MPLS expert and
this will likely show in my comments. Most of my comments below are
editorial or trying to make the document easier to read for first time
readers not deeply involved in the work.

- Consider to avoid acronyms in the Abstract. I had to lookup what
  G-ACh and PTP resolve to in order to read the abstract, which I
  think should be avoided.

- The sentence starting 'I.e.' in parenthesis in the Introduction
  almost reads like a definition of Residence Time. Is it useful to
  have this sentence in parenthesis and starting with 'I.e.'? It would
  be nice to have a clear definition of Residence Time. In fact, my
  reading is that residence time sometimes refers to the per hop
  residence them and sometimes to the accumulated per path residence
  time. Does it make sense to distinguish a Node Residence Time from a
  Path Residence Time? Or a Residence Time from an Accumulated
  Residence Time?

- While reading section 3, I was wondering what are 1-step nodes and
  what are 2-step nodes? This is later explained in detail inq section
  7. Perhaps it makes sense to introduce the concept earlier and to
  provide a forward pointer to section 7 for the details.

- I suggest to either always write one-step and two-step or 1-step and
  2-step. Mixing writing styles makes searching in the text a bit more
  complicated.

- The document seems to be PTP specific even though there are
  provisions to support other time synchronization protocols. I
  wonder, though, to what extend this would work for lets say NTP.
  There is quite some text refering to the correctionField, which
  seems to be a PTP-specific field.

- s/Scratch Pad filed/Scratch Pad field/

- Does the Interface ID related to other interface numbers, e.g.,
  SNMP's ifIndex? Or is this an entirely separate number space? Or
  does it depend on the implementor's choice?

- In section 7, enumerated item 1, there is a hanging open parenthesis
  which seem to have to sub-items inside. I suggest to change this by
  s/forthcoming (this/forthcoming. This/

- In section 8.3: s/.  .  /.  /

- It may be useful to add instructions that the RFC editor is expected
  to replace TBAx in the text once IANA has done the assignments.

- What does 'particularly as applied to use related to PTP' mean?