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

[Greg Mirsky <[e-mail]>]

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