Joel, thank you for your review. I have entered a No Objection ballot for this document.
Lars > On Jun 28, 2022, at 23:09, Joel Halpern via Datatracker <nore...@ietf.org> > wrote: > > Reviewer: Joel Halpern > Review result: Ready with Issues > > 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-ipv6-options-08 > Reviewer: Joel Halpern > Review Date: 2022-06-28 > IETF LC End Date: 2022-07-01 > IESG Telechat date: Not scheduled for a telechat > > Summary: If the issues identified below are addressed, this document will be > ready for publication as a Proposed Standard RFC. > > Major issues: > Why is the domain boundary expectation in section 4 only a SHOULD? Either > there is no need to restrict it, or it is important and it is a MUST? This > comes up again in section 5.1 item C4. > > Minor issues: > The document uses the term IOAM extensively. It expands the term as > "In-situ Operations, Administration, and Maintenance". While a good start, > it would be very helpful if the document either defined IOAM or cited a > definition. The expansion does not explain what the difference is between > IOAM and other forms of OAM, nor indicate what sorts of packets IOAM > applies to. > > Section 5.1 (Considerations for IOAM deployment in IPv6 networks) > requirement C1 seems to be an implementation requirement not a deployment > requirement. The text even ends with "Implementations of IOAM SHOULD..." > Why is this in a deployment considerations section? > > Requirement C3 in section 5.1 is very oddly worded. It seems to say "X > should not happen" but does not tell the implementor or deployer how to > avoid having X occur. I would recommend rewording. (At a guess, something > about how entities sending errors outside of an IOAM domain should remove > any IOAM data??) > > Requirement C5 in 5.1 says that leaks need to be easily identified and > attributed. That's nice. It doesn't seem to say HOW that is to be done. > So how does an implementor or deployer comply with the requirement? > > Could the description clause of the two IANA entries please use "IOAM > destination option" and "IOAM hop-by-hop option" rather than describing > them both just as "IOAM". > > Nits/editorial comments: > Given the problems of acronym overload and the sparse need for it, I would > recommend not using the acronym ION (IOAM Overlay Network), and simply > spelling that out in the few places it is needed. > > It would be helpful if section 5.3 (IOAM domains bounded by network > devices) restated that such ingress edge devices will encapsulate the user > packet, and put the IOAM option in the resulting encapsulating header. And > decapsulate at the egress. > > > > -- > last-call mailing list > last-c...@ietf.org > https://www.ietf.org/mailman/listinfo/last-call
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
