Greg and Gunter (as AD)*, 

* Gunter, please review and let us know if you approve this change in Section 
2.1 (which is also shown in the diff files below). This is per Greg's reply to 
#4 below.

Original:
      Requirement 2: The encapsulation of OAM control messages and data
      packets in the underlay network MUST be indistinguishable from
      each other from the underlay network IP forwarding point of view.

Current:
   Requirement 2:  The encapsulation of OAM control messages and data
                   packets in the underlay network MUST be
                   indistinguishable.


Greg, 

Thank you for your reply. Re: #5, you wrote:

> > Should a reference to draft-ietf-mpls-p2mp-bfd be added?
> GIM>> Thank you for pointing it out to me. Yes, I provide one option below.


Should it be informative or normative? Also, what short name is good for the 
reference?  It has been added as informative and [P2MP-BFD] for now; we will 
update it per your reply. (That document is currently in RFC-EDITOR state.) 
Please let us know any further changes.

Original:
   For IPv6, the address MUST be
   selected from the Dummy IPv6 Prefix for IPv6 *Dummy-IPv6-Prefix*.

Current:
   For IPv6, the address MUST be
   selected from the Dummy IPv6 Prefix 100:0:0:1::/64 [P2MP-BFD].


The revised files are here (please refresh):
  https://www.rfc-editor.org/authors/rfc9772.html
  https://www.rfc-editor.org/authors/rfc9772.txt
  https://www.rfc-editor.org/authors/rfc9772.pdf
  https://www.rfc-editor.org/authors/rfc9772.xml

This diff file shows all changes from the approved I-D:
  https://www.rfc-editor.org/authors/rfc9772-diff.html
  https://www.rfc-editor.org/authors/rfc9772-rfcdiff.html (side by side)

This diff file shows the changes made during AUTH48 thus far:
  https://www.rfc-editor.org/authors/rfc9772-auth48diff.html
  https://www.rfc-editor.org/authors/rfc9772-auth48rfcdiff.html (side by side)

We will wait to hear from you again and from your coauthors
before continuing the publication process. This page shows 
the AUTH48 status of your document:
  https://www.rfc-editor.org/auth48/rfc9772

Thank you.
RFC Editor/ar

> On Apr 30, 2025, at 2:09 PM, Greg Mirsky <gregimir...@gmail.com> wrote:
> 
> Hi Alice,
> thank you for your kind reminder. Please find my answers below tagged GIM>>.
> 
> Regards,
> Greg
> 
> On Tue, Apr 29, 2025 at 11:12 AM Alice Russo <aru...@staff.rfc-editor.org> 
> wrote:
> Authors,
> 
> This is a reminder that we await word from you regarding the questions below 
> and this document's readiness for publication as an RFC. The files are here:
> 
>   https://www.rfc-editor.org/authors/rfc9772.html
>   https://www.rfc-editor.org/authors/rfc9772.pdf
>   https://www.rfc-editor.org/authors/rfc9772.txt
>   https://www.rfc-editor.org/authors/rfc9772.xml (source)
> 
> Diff files of all changes from the approved Internet-Draft:
>   https://www.rfc-editor.org/authors/rfc9772-diff.html 
>   https://www.rfc-editor.org/authors/rfc9772-rfcdiff.html (side by side)
> 
> This page shows the AUTH48 status of your document:
>   https://www.rfc-editor.org/auth48/rfc9772
> 
> Thank you.
> RFC Editor/ar
> 
> > On Apr 22, 2025, at 4:11 PM, rfc-edi...@rfc-editor.org wrote:
> > 
> > Authors,
> > 
> > While reviewing this document during AUTH48, please resolve (as necessary)
> > the following questions, which are also in the XML file.
> > 
> > 1) <!-- [rfced] Please note that the title of the document has been updated 
> > as
> > follows. Abbreviations have been expanded per Section 3.6 of RFC 7322 ("RFC
> > Style Guide"). 
> > 
> > Original:
> >                      Active OAM for use in Geneve
> > 
> > Current:
> >  Active Operations, Administration, and Maintenance (OAM) for Use in
> >         Generic Network Virtualization Encapsulation (Geneve)
> > -->
> > 
> > 
> > 2) <!--[rfced] Please clarify; is it possible that each endpoint (rather 
> > than 
> > the two endpoints together) is an interface of an NVE? If so, we suggest
> > updating this sentence as follows.
> > 
> > Original:
> >   Active OAM messages in a
> >   Geneve overlay network are exchanged between two Geneve tunnel
> >   endpoints, which may be the tenant-facing interface of the Network
> >   Virtualization Edge (NVE) or another device acting as a Geneve tunnel
> >   endpoint.
> > 
> > Perhaps:
> >   Active OAM messages in a
> >   Geneve overlay network are exchanged between two Geneve tunnel
> >   endpoints; each endpoint may be the tenant-facing interface of the Network
> >   Virtualization Edge (NVE) or another device acting as a Geneve tunnel
> >   endpoint.
> GIM>> Thank you for the proposed text, it is clearer. I agree with the 
> proposed update. 
> > -->
> > 
> > 
> > 3) <!--[rfced] Should "follow the same overlay and transport path" be plural
> > "paths"?
> > 
> > Original:
> >      Specifically,
> >      the OAM test packets MUST be in-band with the monitored traffic
> >      and follow the same overlay and transport path as packets carrying
> >      data payloads in the forward direction, i.e., from the ingress
> >      toward the egress endpoint(s) of the OAM test.
> > 
> > Perhaps:
> >      Specifically,
> >      the OAM test packets MUST be in-band with the monitored traffic
> >      and follow the same overlay and transport paths as packets carrying
> >      data payloads in the forward direction, i.e., from the ingress
> >      toward the egress endpoint(s) of the OAM test.
> GIM>> Indeed, plural "paths" is correct here. I agree with the update. 
> > -->
> > 
> > 
> > 4) <!--[rfced] How may "from the underlay network IP forwarding point 
> > of view" be rephrased for clarity? 
> > 
> > Original:
> >      Requirement 2: The encapsulation of OAM control messages and data
> >      packets in the underlay network MUST be indistinguishable from
> >      each other from the underlay network IP forwarding point of view.
> > 
> > Perhaps:
> >      Requirement 2: The encapsulation of OAM control messages and data
> >      packets in the underlay network MUST be indistinguishable from
> >      each other from the point of view of the forwarding in the IP 
> >      underlay network.
> GIM>> Perhaps removing "from the point of view" altogether as follows:
> Requirement 2: The encapsulation of OAM control messages and data packets in 
> the IP underlay network MUST be indistinguishable. 
> > 
> > (We note the phrase "the forwarding in the IP underlay network" is used in 
> > Section 2.2.)
> > --> 
> > 
> > 
> > 5) <!--[rfced] Regarding Section 2.3, the IANA actions for
> > draft-ietf-mpls-p2mp-bfd are not yet complete, i.e., the
> > Dummy-IPv6-Prefix requested by draft-ietf-mpls-p2mp-bfd has not yet been
> > assigned, so the text of this document has not been updated.
> > 
> > Should a reference to draft-ietf-mpls-p2mp-bfd be added?
> GIM>> Thank you for pointing it out to me. Yes, I provide one option below.
> > 
> > We note that https://www.iana.org/performance/ietf-draft-status lists
> > draft-ietf-mpls-p2mp-bfd as waiting on authors since 22 Feb 2025.
> GIM>> I answered the outstanding question and removed that obstacle, so 
> things are in motion. 
> > 
> > Unless the text is changed to remove this prefix, this document 
> > will remain in AUTH48 until the Dummy-IPv6-Prefix has been assigned.
> > 
> > ORIGINAL:
> >   Inner IP header:
> > 
> >      Destination IP: The IP address MUST be set to the loopback address
> >      127.0.0.1/32 for IPv4 version.  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.]
> GIM>> With the reference:
>       Destination IP: The IP address MUST be set to the loopback address
>       127.0.0.1/32 for IPv4 version.  For IPv6, the address MUST be
>       selected from the Dummy IPv6 Prefix for IPv6 *Dummy-IPv6-Prefix* 
> [I-D.ietf-mpls-p2mp-bfd].
>       A source-only IPv6 dummy address is used as the destination to
>      generate an exception and a reply message to the request message
>       received.
> > -->
> > 
> > 
> > 6) <!--[rfced] Please consider whether "dummy" would be more clear 
> > as "example" or "placeholder" or similar.
> > 
> > Original: the Dummy IPv6 Prefix
> GIM>> I suggest we leave this as-is; that is the name of the prefix in the 
> IANA registry. 
> > Original: A source-only IPv6 dummy address
> GIM>>  Perhaps we can drop "dummy" in this case:
>       A source-only IPv6 address is used as the destination to
>      generate an exception and a reply message to the request message
>       received.
> > -->
> > 
> > 
> > 7) <!-- [rfced] Please review the "Inclusive Language" portion of the 
> > online 
> > Style Guide 
> > <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
> > and let us know if any changes are needed.  Updates of this nature typically
> > result in more precise language, which is helpful for readers.
> > 
> > Note that our script did not flag any words in particular, but this should 
> > still be reviewed as a best practice.
> GIM>> It appears to me that we are clean on that. 
> > -->
> > 
> > 
> > Thank you.
> > 
> > RFC Editor/ar
> > 
> > 
> > 
> > On Apr 22, 2025, at 4:11 PM, rfc-edi...@rfc-editor.org wrote:
> > 
> > *****IMPORTANT*****
> > 
> > Updated 2025/04/22
> > 
> > RFC Author(s):
> > --------------
> > 
> > Instructions for Completing AUTH48
> > 
> > Your document has now entered AUTH48.  Once it has been reviewed and 
> > approved by you and all coauthors, it will be published as an RFC.  
> > If an author is no longer available, there are several remedies 
> > available as listed in the FAQ (https://www.rfc-editor.org/faq/).
> > 
> > You and you coauthors are responsible for engaging other parties 
> > (e.g., Contributors or Working Group) as necessary before providing 
> > your approval.
> > 
> > Planning your review 
> > ---------------------
> > 
> > Please review the following aspects of your document:
> > 
> > *  RFC Editor questions
> > 
> >  Please review and resolve any questions raised by the RFC Editor 
> >  that have been included in the XML file as comments marked as 
> >  follows:
> > 
> >  <!-- [rfced] ... -->
> > 
> >  These questions will also be sent in a subsequent email.
> > 
> > *  Changes submitted by coauthors 
> > 
> >  Please ensure that you review any changes submitted by your 
> >  coauthors.  We assume that if you do not speak up that you 
> >  agree to changes submitted by your coauthors.
> > 
> > *  Content 
> > 
> >  Please review the full content of the document, as this cannot 
> >  change once the RFC is published.  Please pay particular attention to:
> >  - IANA considerations updates (if applicable)
> >  - contact information
> >  - references
> > 
> > *  Copyright notices and legends
> > 
> >  Please review the copyright notice and legends as defined in
> >  RFC 5378 and the Trust Legal Provisions 
> >  (TLP – https://trustee.ietf.org/license-info).
> > 
> > *  Semantic markup
> > 
> >  Please review the markup in the XML file to ensure that elements of  
> >  content are correctly tagged.  For example, ensure that <sourcecode> 
> >  and <artwork> are set correctly.  See details at 
> >  <https://authors.ietf.org/rfcxml-vocabulary>.
> > 
> > *  Formatted output
> > 
> >  Please review the PDF, HTML, and TXT files to ensure that the 
> >  formatted output, as generated from the markup in the XML file, is 
> >  reasonable.  Please note that the TXT will have formatting 
> >  limitations compared to the PDF and HTML.
> > 
> > 
> > Submitting changes
> > ------------------
> > 
> > To submit changes, please reply to this email using ‘REPLY ALL’ as all 
> > the parties CCed on this message need to see your changes. The parties 
> > include:
> > 
> >  *  your coauthors
> > 
> >  *  rfc-edi...@rfc-editor.org (the RPC team)
> > 
> >  *  other document participants, depending on the stream (e.g., 
> >     IETF Stream participants are your working group chairs, the 
> >     responsible ADs, and the document shepherd).
> > 
> >  *  auth48archive@rfc-editor.org, which is a new archival mailing list 
> >     to preserve AUTH48 conversations; it is not an active discussion 
> >     list:
> > 
> >    *  More info:
> >       
> > https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
> > 
> >    *  The archive itself:
> >       https://mailarchive.ietf.org/arch/browse/auth48archive/
> > 
> >    *  Note: If only absolutely necessary, you may temporarily opt out 
> >       of the archiving of messages (e.g., to discuss a sensitive matter).
> >       If needed, please add a note at the top of the message that you 
> >       have dropped the address. When the discussion is concluded, 
> >       auth48archive@rfc-editor.org will be re-added to the CC list and 
> >       its addition will be noted at the top of the message. 
> > 
> > You may submit your changes in one of two ways:
> > 
> > An update to the provided XML file
> > — OR —
> > An explicit list of changes in this format
> > 
> > Section # (or indicate Global)
> > 
> > OLD:
> > old text
> > 
> > NEW:
> > new text
> > 
> > You do not need to reply with both an updated XML file and an explicit 
> > list of changes, as either form is sufficient.
> > 
> > We will ask a stream manager to review and approve any changes that seem
> > beyond editorial in nature, e.g., addition of new text, deletion of text, 
> > and technical changes.  Information about stream managers can be found in 
> > the FAQ.  Editorial changes do not require approval from a stream manager.
> > 
> > 
> > Approving for publication
> > --------------------------
> > 
> > To approve your RFC for publication, please reply to this email stating
> > that you approve this RFC for publication.  Please use ‘REPLY ALL’,
> > as all the parties CCed on this message need to see your approval.
> > 
> > 
> > Files 
> > -----
> > 
> > The files are available here:
> >  https://www.rfc-editor.org/authors/rfc9772.xml
> >  https://www.rfc-editor.org/authors/rfc9772.html
> >  https://www.rfc-editor.org/authors/rfc9772.pdf
> >  https://www.rfc-editor.org/authors/rfc9772.txt
> > 
> > Diff file of the text:
> >  https://www.rfc-editor.org/authors/rfc9772-diff.html
> >  https://www.rfc-editor.org/authors/rfc9772-rfcdiff.html (side by side)
> > 
> > Diff of the XML: 
> >  https://www.rfc-editor.org/authors/rfc9772-xmldiff1.html
> > 
> > 
> > Tracking progress
> > -----------------
> > 
> > The details of the AUTH48 status of your document are here:
> >  https://www.rfc-editor.org/auth48/rfc9772
> > 
> > Please let us know if you have any questions.  
> > 
> > Thank you for your cooperation,
> > 
> > RFC Editor
> > 
> > --------------------------------------
> > RFC9772 (draft-ietf-nvo3-geneve-oam-16)
> > 
> > Title            :   Active Operations, Administration, and Maintenance 
> > (OAM) for Use in Generic Network Virtualization Encapsulation (Geneve)
> > Author(s)        : G. Mirsky, S. Boutros, D. Black, S. Pallagatti
> > WG Chair(s)      : Matthew Bocci, Sam Aldrin
> > Area Director(s) : Jim Guichard, Ketan Talaulikar, Gunter Van de Velde
> > 
> 

-- 
auth48archive mailing list -- auth48archive@rfc-editor.org
To unsubscribe send an email to auth48archive-le...@rfc-editor.org

Reply via email to