Hi Eric, do the proposed updates address your comments satisfactorily? The attached diff highlights the latest changes.
Regards, Greg On Wed, Feb 19, 2025 at 11:17 PM Greg Mirsky <gregimir...@gmail.com> wrote: > Hi Éric, > thank you for the expedient response and helpful comments. Please find my > notes below tagged GIM>>. I attached the diff highlighting updates applied > in the new working version. > > Regards, > Greg > > On Mon, Feb 17, 2025 at 11:07 PM Éric Vyncke via Datatracker < > nore...@ietf.org> wrote: > >> Éric Vyncke has entered the following ballot position for >> draft-ietf-nvo3-geneve-oam-15: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to >> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ >> for more information about how to handle DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-nvo3-geneve-oam/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Thanks for addressing my previous blocking DISCUSS at: >> https://mailarchive.ietf.org/arch/msg/nvo3/iB6bhzYMgegIqIgphhhY5NBmQGM/ >> >> Nevertheless, I have some new COMMENTS to be addressed before the >> publication. >> >> ## NEW COMMENTS (non-blocking) >> >> ### Section 2.3 >> >> s/from the Dummy IPv6 Range for IPv6 [I-D.ietf-mpls-p2mp-bfd]/from the >> Dummy >> IPv6 Range for IPv6 *dummy_prefix*/ + add a paragraph with a note to the >> RFC >> editor to reply *dummy_prefix* but the IANA allocation for IPv6 Dummy >> Prefix + >> remove draft-ietf-mpls-p2mp-bfd from the reference list. >> >> Note: I think that the above is cleaner and also 'breaks' the cluster >> assuming >> that IANA acts faster than RFC Editor. >> >> ### Use of a source-only address >> >> Some text about using a source-only address as destination on purpose to >> generate an exception may be useful, perhaps in the introduction. >> > GIM>> I propose the following update: > OLD TEXT: > For IPv6, the address MUST be > selected from the Dummy IPv6 Range for IPv6 > [I-D.ietf-mpls-p2mp-bfd]. > NEW TEXT: > For IPv6, the address MUST be > selected from the Dummy IPv6 Prefix for IPv6 *Dummy-IPv6-Prefix*. > A source-only IPv6 dummy address is used as the destination to > generate an exception and a reply message to the request message > received. > > [Note to RFC Editor: Please replace *Dummy-IPv6-Prefix* with the > actual value allocated (requested in draft-ietf-mpls-p2mp-bfd) in > IANA IPv6 Special-Purpose Address Registry.] > > Would these updates address your concerns? > >> >> ## PREVIOUS COMMENTS (non-blocking) >> >> ### Section 2.1 >> >> Isn't requirement #1 implied by requirement #2 ? I.e., all packets >> complying to >> requirement #2 also complies to requirement #1 ? >> >> ### Section 2.2 >> >> Is `Management VNI` the right term for active probing OAM traffic ? I.e., >> I >> would not use 'management' for ping and would reserve it for netconf or >> other >> configuration/telemetry traffic. >> >> `A packet received over the control channel MUST be forwarded` forwarded >> by >> whom and to whom ? >> >> ### Section 2.3 >> >> Is there any recommendation for inner source IP address/UDP port ? >> >> ## NITS (non-blocking / cosmetic) >> >> ### Use of SVG graphics >> >> To make a much nicer HTML rendering, suggest using the aasvg too to >> generate >> SVG graphics. It is worth a try ;-) >> >> >> >>
<<< text/html; charset="US-ASCII"; name="draft-ietf-nvo3-geneve-oam-16.diff.html": Unrecognized >>>
_______________________________________________ nvo3 mailing list -- nvo3@ietf.org To unsubscribe send an email to nvo3-le...@ietf.org
