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 revision | No specific revision (document currently at 15) | |
Type | Last Call Review | |
Team | Ops Directorate (opsdir) | |
Deadline | 2017-01-17 | |
Requested | 2017-01-03 | |
Authors | Greg Mirsky , Stefano Ruffini , Eric Gray , John Drake , Stewart Bryant , Sasha Vainshtein | |
I-D 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 | |
Request | Last Call review on draft-ietf-mpls-residence-time by Ops Directorate Assigned | |
Reviewed revision | 12 (document currently at 15) | |
Result | Has nits | |
Completed | 2017-01-13 |
review-ietf-mpls-residence-time-12-opsdir-lc-schoenwaelder-2017-01-13-00
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?