Hi Pascal, Thanks for the quick reply and update - this works for me! Cheers Sarah > On Feb 1, 2020, at 6:06 AM, Pascal Thubert (pthubert) <pthubert@xxxxxxxxx> wrote: > > Hello Sarah: > > Many thanks for your review : ) > > > >> -----Original Message----- >> From: Sarah Banks via Datatracker <noreply@xxxxxxxx> >> Sent: vendredi 31 janvier 2020 17:40 >> To: ops-dir@xxxxxxxx >> Cc: draft-ietf-6lo-minimal-fragment.all@xxxxxxxx; last-call@xxxxxxxx; >> 6lo@xxxxxxxx >> Subject: Opsdir last call review of draft-ietf-6lo-minimal-fragment-09 >> >> Reviewer: Sarah Banks >> Review result: Ready >> >> Hi, >> Thanks for a well written, technical draft. I have no comments that stop >> publication, however, I do have a couple of editorial comments to make, >> focused mostly at the top of the document. Also, thanks for a doc clean of >> nits, much appreciated! >> >> - While I find the language overall to be very approachable, in the 1. >> Introduction section, you wrote "till" - please consider replacing with "until". - > > Done > >> Also in the Introduction section, you wrote "performances may fall behind..." - >> it wasn't clear which multiples of performances you were referring to - be >> specific, or consider revising "performances" to "performance". - I found the > > Changed "performances" to "latency", so we end up with > "may be misused to the point that the end-to-end latency falls behind that of per-hop recomposition" > > >> draft assumes serious familiarity of the reader on the subject. For example, in >> Section 2.2, first para, "Past experience with fragmentation" - I found myself >> wondering "whose past experience"? You might consider tightening up the >> language here to be clear. > > Suggest to change the paragraph as below: > " > > Past experience with fragmentation, e.g., as described in "IPv4 > Reassembly Errors at High Data Rates" [RFC4963] and references > therein, has shown that mis-associated or lost fragments can lead to > poor network behavior and, occasionally, trouble at application > layer. That experience led to the definition of "Path MTU discovery" > [RFC8201] (PMTUD) protocol that limits fragmentation over the > Internet. > " > > > I'll also add that including a decent list of follow up >> docs was greatly appreciated, thanks! That will be helpful to a broader >> audience. > > Cool : ) > > Many thanks again, Sarah. > > I posted v10 to reflect this discussion. Please let me know if all the above fits your expectations. > > All the best, > > Pascal > > -- > last-call mailing list > last-call@xxxxxxxx > https://www.ietf.org/mailman/listinfo/last-call -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
