Hi Martin, This is to confirm that -09 version of the draft has been published a few days ago that addresses all the comments per the discussion in this thread.
Thanks Shwetha On Sun, Sep 25, 2022, 9:56 AM Joel Halpern <[email protected]> wrote: > Thank you for addressing my comments. trimmed, responses where needed in > line. > > Yours, > > Joel > On 9/24/2022 10:01 PM, Shwetha Bhandari wrote: > > 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 < > [email protected]> 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 > > >> Minor issues: > > > >> 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? > > <jmh>Yes, renaming the section to "deployment and implementation > considerations" would resolve this concern. </jmh> > > > >> >> 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. > > <jmh>I marked this as minor, so if you really can't say anything else, I > guess I can live with it. But it seems more than a little odd to have a > requirement in a draft with no way to meet it.</jmh> > > > Nits/editorial comments: > > >> 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. > > <jmh>Okay.</jmh> > > > > Thanks, > Shwetha > > >
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
