Re: [Last-Call] Genart last call review of draft-ietf-ippm-ioam-ipv6-options-08

Shwetha Bhandari <shwetha.bhandari@xxxxxxxxxxxxxxx> · Fri, 28 Oct 2022 07:41:20 +0530

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 <jmh@xxxxxxxxxxxxxxx> 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 <noreply@xxxxxxxx>
            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

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call