Thank you for the detailed review and sorry for a very late response. I am creating a revision of the draft based on this feedback. Responses and clarifications inline @SB
On Wed, Jun 29, 2022 at 1:39 AM 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://urldefense.com/v3/__https://trac.ietf.org/trac/gen/wiki/GenArtfaq__;!!MZ3Fw45to5uY!NoSxZQbYffG7SJV0yDCTEy7dKRhLkASqrXTvmSZYhuyCrik6ftQvulTvbfT6xyFBWdoxk_7S4nD87nOYMkJnckbF$ > >. > > 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. > [SB] Agreed. Will change to MUST in the revision. > > 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. > [SB] Will refer to RFC 9197 for the definition of IOAM. > 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? > [SB] This was an important consideration for implementation and deployment that came up during the workgroup discussions. Would renaming the sesion to deployment and implementation considerations work? > 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??) > [SB] Added text to this effect. > > 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? > [SB] This is not addressed in the current draft. A future draft could add IOAM field to indicate the AS that added the IOAM data. > 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". > [SB] done. > > 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. > [SB] done > > 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. > [SB] The deployment options elaborates this option, it is difficult to summarize that and add it as part of the requirement. I would prefer to keep this context in the deployment options section. Thanks, Shwetha
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
