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 <rjspa...@nostrum.com> 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 <gregimir...@gmail.com> > 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 <rjspa...@nostrum.com> >> 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]. >>> >>> >>> >>> >> > >
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
