Hi Jurgen,
thank you for the thorough review and the most detailed and helpful comments.
We're preparing -13 version and will address your comments promptly. Please find my responses in-lined and tagged GIM>>.
Regards,
Greg
On Fri, Jan 13, 2017 at 12:47 AM, <"Jürgen Schönwälder <j.schoenwaelder@jac"@ietfa.amsl.com > wrote:
Reviewer: Jürgen Schönwälder
Review result: Has Nits
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.
GIM>> Will use full versions in the Abstract.
- 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?
GIM>> Perhaps if parenthesis removed and the sentence starts with "Residence Time can be calculated as the sum ..."
- 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.
GIM>> Will try to re-arrange the text to make the flow more logical.
- 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.
GIM>> Will pick and use one form throughout the document.
- 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.
GIM>> Yes, NTP doesn't use residence time and thus no need for correctionField. We assume that there may be interest in using RT by NTP at some time.
- s/Scratch Pad filed/Scratch Pad field/
GIM>> Great catch, thank you!
- 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?
GIM>> This comes from PTP. AFAIK, it is different from SNMP index.
- 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/
GIM>> Accepted, thank you.
- In section 8.3: s/. . /. /
GIM>> Done
- 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?
GIM>> My interpretation would be "when used to measure the residence time on behalf of PTP"