Re: [mpls] Review of draft-ietf-mpls-residence-time-12

[Greg Mirsky <[e-mail]>]

Hi Jurgen,
I've prepared updated version and would greatly appreciate if you review
the changes and let us know whether your comments been addressed. Attached
are diff and the new version.

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.
>
> - 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?
>
>
>