Dan, thank you for your review. I have entered a Discuss ballot for this document based on my own review. Lars > On 2020-12-5, at 12:05, Dan Romascanu via Datatracker <noreply@xxxxxxxx> wrote: > > Reviewer: Dan Romascanu > 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-ippm-ioam-data-11 > Reviewer: Dan Romascanu > Review Date: 2020-12-05 > IETF LC End Date: 2020-12-08 > IESG Telechat date: Not scheduled for a telechat > > Summary: > > This is a very useful and rather complex document that discusses the data > fields and associated data types for IOAM that can be encapsulated into a > variety of protocols. It's well written, detailed and accurate. It is READY > from a Gen-ART perspective, with a few editorial comments that I suggest being > addressed before approval or as part of the final editorial process. > > Major issues: > > Minor issues: > > Nits/editorial comments: > > 1. How are specific IOAM encapsulations being defined? Will specifications that > define IOAM encapsulations into various protocols be within the scope of the > IPPM WG? of the IETF? Do they require to be RFCs? Some clarification text would > be useful. > > 2. In Section 5.4.2.12 I found the following: > >> The authors > acknowledge that in some operational cases there is a need for the > units to be consistent across a packet path through the network, > hence RECOMMEND the implementations to use standard units such as > Bytes. > > 'The authors ... RECOMMEND' seems a little bit odd. The active verb form is not > within the list of keywords as per [RFC2119], also mentioned in Section 3 of > this document. To be on the safe side I would recommend reformulating the > sentence so that the RECOMMENDED form is used. Alternatively, just do not use > capitalization here. > > 3. In Section 8.7 I found: > >> The expert will post the request on the IPPM mailing list, and > possibly on other relevant mailing lists, to allow for community > feedback. > > I assume that this means the IPPM WG mailing list. The abbreviation of IPPM may > be very familiar for the current audiences, but the situation may change in the > future. The scope even of this document may outlive the WG. I suggest to expand > IPPM in Section 3 and possibly reformulate the sentence so that posting the > request on the IPPM list does not sound as the eternal procedure. > > > > -- > last-call mailing list > last-call@xxxxxxxx > https://www.ietf.org/mailman/listinfo/last-call
Attachment:
signature.asc
Description: Message signed with OpenPGP
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
