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 <[email protected]> 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 <[email protected]>
> 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, [email protected] 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, [email protected] 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
> >
> > * [email protected] (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).
> >
> > * [email protected], 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,
> > [email protected] 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 -- [email protected]
To unsubscribe send an email to [email protected]
