Hi Robert,
thank you for your the most detailed review and helpful comments. I'll prepare -13 version based on your suggestions.
Please find my responses, notes in-lined and tagged GIM>>
Regards,
Greg
On Wed, Jan 11, 2017 at 7:48 AM, Robert Sparks <rjsparks@xxxxxxxxxxx> 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.
GIM>> Will use "message" as you've suggested. Indeed, interchangeable use of packet and message does confuse.
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.
GIM>> G.8013, formerly Y.1731, does not require or define when a time stamp must be taken. The document only indicates during which process time been taken, e.g.:
TxTimeStampf: Timestamp at the transmission time of ETH-DM frame
RxTimeStampf: Timestamp at the time of receiving frame with ETH-DM request information.
What is important for quality of measurement is for an implementation to be reading and writing in timestamp at the same stage of processing the RTM packet and avoiding queuing/de-queuing in order to avoid impact of jitter caused by queuing/de-queuing.
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.
GIM>> Will try.
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.
GIM>> Will make changes accordingly.
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"
GIM>> Thank you, will make the changes.
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].
GIM>> Will add the reference.