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

[Greg Mirsky <[e-mail]>]

Hi Robert,
thank you for the most expedient review and comments. I'll make changes in
Section 2 per your suggestion.

Regards,
Greg

On Wed, Jan 18, 2017 at 10:34 AM, Robert Sparks <[e-mail]>
wrote:

> The changes all look good.
>
> I still think you should say something in the document about what "the
> time of packet arrival" and "transmission" means, and call out the point
> you made about being careful to not introduce apparent jitter by not making
> those measurements consistently. (The definitions you point to in your
> earlier mail from G.8013 don't really help - they just say "time of packet
> arrival". Again, the first and last bit are likely to be several
> nanoseconds apart so I think it matters. Perhaps you're saying it doesn't
> matter as long as each node is consistent (there will be error in the
> residence time measurement, but it will be constant at each node, so the
> sum of errors will be constant, and the clocks will be ok?)
>
> Please look at the new first paragraph of section 2 - there's a mix of "as
> case" and "in case" that should be made consistent. I suspect it would be
> easiest to simply say "referred to as using a one-step clock" and "referred
> to as using a two-step clock" or similar.
>
> RjS
>
> On 1/18/17 12:03 PM, Greg Mirsky wrote:
>
> Hi Robert,
> Sasha Vainshtein came with elegant idea to address disconnection between
> discussion of one-step and two-step modes that you've pointed out. We've
> moved Section 7 as sub-section into Section 2 now. Attached are updated
> diff and the proposed new version -13.
>
> Regards,
> Greg
>
> On Wed, Jan 18, 2017 at 8:13 AM, Greg Mirsky <[e-mail]>
> wrote:
>
>> Hi Robert,
>> once again, thank you for your thorough review and the most detailed
>> comments. 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 Wed, Jan 11, 2017 at 7:48 AM, Robert Sparks <[e-mail]>
>> wrote:
>>
>>> Reviewer: Robert Sparks
>>> Review result: Ready with Nits
>>>
>>> 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
>>> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
>>>
>>> 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].
>>>
>>>
>>>
>>>
>>
>
>