Hi Eric, I uploaded the new version. Thank you for your help in improving this document.
Regards, Greg On Wed, Feb 26, 2025 at 9:59 AM Eric Vyncke (evyncke) <evyn...@cisco.com> wrote: > Hello Greg and NVO3 WG, > > > > The proposed change indeed fully addresses my comments, thanks for the > change. > > > > Regards > > > > -éric > > > > *From: *Greg Mirsky <gregimir...@gmail.com> > *Date: *Wednesday, 26 February 2025 at 09:29 > *To: *Eric Vyncke (evyncke) <evyn...@cisco.com> > *Cc: *The IESG <i...@ietf.org>, draft-ietf-nvo3-geneve-...@ietf.org < > draft-ietf-nvo3-geneve-...@ietf.org>, nvo3-cha...@ietf.org < > nvo3-cha...@ietf.org>, nvo3@ietf.org <nvo3@ietf.org>, > aldrin.i...@gmail.com <aldrin.i...@gmail.com>, matthew.bo...@nokia.com < > matthew.bo...@nokia.com> > *Subject: *Re: Éric Vyncke's No Objection on > draft-ietf-nvo3-geneve-oam-15: (with COMMENT) > > 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 ;-) > > >
_______________________________________________ nvo3 mailing list -- nvo3@ietf.org To unsubscribe send an email to nvo3-le...@ietf.org
