Thanks for the changes. A few comments also inline. - J > On 17 Jan 2022, at 11:06, <mohamed.boucadair@xxxxxxxxxx> <mohamed.boucadair@xxxxxxxxxx> wrote: > > Hi James, > > Thank you for the review. > > Please see inline. > > Cheers, > Med > >> -----Message d'origine----- >> De : James Gruessing via Datatracker <noreply@xxxxxxxx> >> Envoyé : samedi 15 janvier 2022 19:50 >> À : art@xxxxxxxx >> Cc : dots@xxxxxxxx; draft-ietf-dots-telemetry.all@xxxxxxxx; last- >> call@xxxxxxxx >> Objet : Artart last call review of draft-ietf-dots-telemetry-19 >> >> Reviewer: James Gruessing >> Review result: Ready with Nits >> >> This is my review of draft-ietf-dots-telemetry-19 as requested by ARTART >> chairs. >> >> Overall this is a well written document that explains its purpose, >> rationale, and technical details for someone like myself with no >> previous knowledge of DOTS or its underlying dependent protocols. As >> such my focus in this review has been looking at the readability of the >> document through the eyes of a future implementer. > > [Med] Thanks. > >> >> Comments: >> >> 3.2 - At a few points in this section, the concept of "measurements >> should be taken when traffic is 'normal'" is repeated a few times and >> done in a way not as clear as it could be. The authors should consider >> editing this section to be more concise and avoid repetition. > > [Med] Found and fixed one sentence that I think is redundant. Not sure if you have identified others. [James] I haven't identified anything else specific, however your change is a good improvement. > >> >> 3.3 - Perhaps a clear definition for the word "pipe" belongs in the >> terminology section? Although it may appear obvious as to what it means, >> it is jargon that is not used in RFC 9132 nor 9133. Consider that a >> client split with multiple interfaces/networks/DOTS domains etc may >> affect interpretation of the word, and thus the potential value it >> should calculate and send. > > [Med] Sure. Added a new entry to Section 2. [James] Thank you, that's clearer. As an aside to this definition, around 6.2 and later I cannot find any text that covers clients not sending a pipe capacity figure greater than actual* available capacity - in a simple example, a client with 1Gbit probably shouldn't announce 10Gbit. Did I miss it, or is that something to consider? > >> >> 4.2 - This section could be expanded to cover quite a few duplicate >> pieces of normative language listed throughout later sections - for >> example there are many references to 'cuid' being mandatory and should >> not be present in PUT/DELETE request bodies. Putting common details in >> this section, and exceptions throughout should make interpretation by >> implementers easier particularly for the structure of Uri-Path values. > > [Med] Thank you for the proposal, but we prefer the current version as we have key information in one single place. [James] Okay, I still think there's details that are repeated throughout that will impact overall readability of the interfaces. But I'm not going to press this matter any further. > >> >> 9 - It may be beneficial to implementers if this section provides >> guidance on the use of plain text diagnostic payloads for the additional >> error cases this document defines. >> > > [Med] OK. Added a new text to cover this. [James] Thanks, not trying to be nitpicky but perhaps it should be "...plain text diagnostic payloads (...) to help troubleshooting _may be_ returned..." > > >> Nit: >> >> 8.2 - Figure 48 shows the target of "https1" not "http1", the text above >> refers to the latter. >> > > [Med] Thank you for catching this. Fixed. > > FWIW, we will ACK your review in the next iteration. A diff to track the changes to address your review can be seen at: https://tinyurl.com/dots-telemetry-latest. > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
