Authors,
While reviewing this document during AUTH48, please resolve (as necessary)
the following questions, which are also in the source file.
1) <!-- [rfced] We have updated the title as shown below. Please let us
know if any changes are required.
Original:
BFD Stability
Current:
Bidirectional Forwarding Detection (BFD) Stability
-->
2) <!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->
3) <!-- [rfced] In the text below, may we replace "in addition to" with a
verb (such as "describes" or similar) to clarify the purpose of the
document?
Original:
This document proposes an experimental mechanism to detect lost
packets in a BFD session in addition to the datapath fault detection
mechanisms of BFD.
Perhaps:
This document proposes an experimental mechanism to detect lost
packets in a BFD session and describes the datapath fault detection
mechanisms of BFD.
-->
4) <!-- [rfced] In the instances below, may we update
"received-packet-count" to "receive-packet-count" to match usage in
RFC 9314?
Original (Introduction):
Such a mechanism, combined with 'received-packet-count' defined in
the YANG Data Model for Bidrectional Forward Detection (BFD) [RFC9314]
permits operators to measure the stability of BFD sessions.
Original (Appendix A):
The experiment will use the packet lost count
and the 'received-packet-count' defined in the YANG Data Model for
Bidirectional Forward Detection (BFD) [RFC9314] to determine how
stable is the session.
-->
5) <!-- [rfced] FYI - For readability, we broke the text below into two
separate sentences. Please review.
Original:
This proposal enables BFD implementations to generate diagnostic
information on the health of each BFD session that could be used to
preempt probability of a failure on a datapath that BFD was
monitoring by allowing time for a corrective action to be taken.
Current:
This proposal enables BFD implementations to generate diagnostic
information on the health of each BFD session. This information could be
used to preempt the probability of a failure on a datapath that BFD was
monitoring by allowing time for a corrective action to be taken.
-->
6) <!-- [rfced] Does "BFD Meticulous" refer "Meticulous Keyed MD5", as
registered by IANA? Should the text be udpated to refer to march the IANA
name? See
<https://www.iana.org/assignments/bfd-parameters/bfd-parameters.xhtml#bfd-parameters-2>.
Original:
BFD stability measurement requires that a BFD Meticulous
Authentication type is configured.
-->
7) <!-- [rfced] FYI - We have removed "BFD" from the text below for
clarity, because we believe it was meant to function as a citation (rather
than a part of the sentence's meaning). Please review to confirm this
change is accurate.
Original:
The NULL Authentication Type, defined in this document, can be used
to provide a meticulously increasing sequence number BFD [RFC5880]
for stability measurement.
Current:
The NULL authentication type, defined in this document, can be used
to provide a meticulously increasing sequence number [RFC5880]
for stability measurement.
-->
8) <!-- [rfced] What does "lsp" refer to in the text below? How may we
clarify how it relates to the rest of the sentence?
Original:
In addition, a loss count per-session or lsp for BFD packets that are
lost has also been added in this model.
-->
9) <!-- [rfced] Section 7.2: We note that RFC 8177 ("YANG Data Model for
Key Chains") is referenced in the YANG module that appears in this section,
but it is not included in the references section of this document or in the
text that introduces this YANG module (see below).
May we add a reference to RFC 8177 in the references section and in the
text below?
Original:
This YANG module imports modules defined in Common YANG Types
[RFC6991], A YANG Data Model for Routing [RFC8349], and YANG Data
Model for Bidirectional Forwading Detection (BFD) [RFC9314].
Perhaps:
This YANG module imports modules defined in "Common YANG Data Types"
[RFC6991], "YANG Data Model for Key Chains" [RFC8177], "A YANG Data
Model for Routing Management (NMDA Version)" [RFC8349], and "YANG Data
Model for Bidirectional Forwarding Detection (BFD)" [RFC9314].
-->
10) <!-- [rfced] We have updated the YANG module to match the format output
when using the formatting option of pyang. See the formatting (only)
updates in this file:
https://www.rfc-editor.org/authors/[email protected]
-->
11) <!-- [rfced] We have updated the introductory paragraph in the IANA
Considerations to also mention registration of the YANG module name.
Please review and let us know if updates are required.
Original:
This document requests one new authentication type and registers one
URIs in the "ns" subregistry of the "IETF XML" registry [RFC3688].
Current:
This document registers a new authentication type in the "BFD
Authentication Types" registry, a new URI in the "ns" registry within
the "IETF XML" registry group [RFC3688], and a YANG module in the "YANG
Module Names" registry.
-->
12) <!-- [rfced] FYI - We have replaced the comma in the text below with
"with" for clarity. Please review.
Original:
It is intended to provide BFD sessions that otherwise would not use
authentication, a sequence number that can be used for purposes of
detecting lost packets.
Current:
It is intended to provide BFD sessions that otherwise would not use
authentication with a sequence number that can be used for the purpose
of detecting lost packets.
-->
13) <!-- [rfced] Section 9.2 (YANG Security Considerations): We note some
differences from the template in the OPs wiki. Please refer to the
template at <https://wiki.ietf.org/en/group/ops/yang-security-guidelines>.
a) We have updated the first three paragraphs of this section to match the
template. Please review and let us know any objections.
b) In addition, we have updated this paragraph to match what is defined in
the template. Please review and let us know if any updates are needed.
Original:
The only readable data nodes in YANG module may be considered
sensitive or vulnerable in some network environments. It is thus
important to control read access (e.g., via get, get-config, or
notification) to these data nodes.
Current:
Some of the readable data nodes in this YANG module may be
considered sensitive or vulnerable in some network environments. It is
thus important to control read access (e.g., via get, get-config, or
notification) to these data nodes. Specifically, the following subtrees
and data nodes have particular sensitivities/vulnerabilities:
c) In general, please review the Security Considerations and let us know
if any additional changes are required.
d) FYI - Note that we have added RFC 9907 to the Informative References
section of this document.
-->
14) <!-- [rfced] Regarding reference [Y-1731], the version of ITU-T
Recommendation G.8013/Y.1731 referenced in this document has been superseded
(https://www.itu.int/rec/T-REC-G.8013-201311-S/en).
The most current "in force" version was published in June 2023
(https://www.itu.int/rec/T-REC-G.8013-202306-I/en). May we update this
reference to point to the most current version?
Current:
[Y-1731] ITU-T, "OAM functions and mechanisms for Ethernet based
networks", ITU-T Recommendation G.8013/Y.1731, November
2013,
<https://www.itu.int/rec/T-REC-G.8013-201311-S/en>.
Perhaps:
[Y-1731]
ITU-T, "Operation, administration and maintenance (OAM)
functions and mechanisms for Ethernet-based networks",
ITU-T Recommendation G.8013/Y.1731, June 2023,
<https://www.itu.int/rec/T-REC-G.8013-202306-I/en>.
-->
15) <!-- [rfced] Please review the following questions and changes
regarding the terminology used in this document:
a) Should instances of "NULL Auth" be updated to "NULL authentication type"
(i.e., spell out "Authentication") for clarity and consistency with other
uses in the document?
NULL Auth type
NULL Auth Type
NULL Auth
Note that "authentication type" (lowercase) is used except where the text
explicitly refers to the field (Auth Type field or Authentication Type
field).
Please let us know if any updates are needed.
b) To align with RFC 5880, we have updated the following terms. Please
review and let us know if any updates are required.
- "sequence number" (lowercase) except where the text explicitly refers to
the field (i.e., Sequence Number field).
- "authentication type" (lowercase) except where the text explicitly refers
to the field (Auth Type field or Authentication Type field).
- Authentication Section (initial capitalization)
- "session Detection Time"
- Per guidance from Benoit Claise and the YANG Doctors, we updated
instances of "YANG model" to "YANG data model". However, please be sure to
review and ensure "model" and "module" are used correctly.
- We have added expansions for abbreviations upon first use
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.
Operations, Administration, and Maintenance (OAM)
Label Switched Paths (LSPs)
-->
Thank you.
Kaelin Foody and Sandy Ginoza
RFC Production Center
On May 7, 2026, at 3:57 PM, [email protected] wrote:
*****IMPORTANT*****
Updated 2026/05/07
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/rfc9978.xml
https://www.rfc-editor.org/authors/rfc9978.html
https://www.rfc-editor.org/authors/rfc9978.pdf
https://www.rfc-editor.org/authors/rfc9978.txt
Diff file of the text:
https://www.rfc-editor.org/authors/rfc9978-diff.html
https://www.rfc-editor.org/authors/rfc9978-rfcdiff.html (side by side)
Diff of the XML:
https://www.rfc-editor.org/authors/rfc9978-xmldiff1.html
Tracking progress
-----------------
The details of the AUTH48 status of your document are here:
https://www.rfc-editor.org/auth48/rfc9978
Please let us know if you have any questions.
Thank you for your cooperation,
RFC Editor
--------------------------------------
RFC9978 (draft-ietf-bfd-stability-21)
Title : BFD Stability
Author(s) : A. Mishra, M. Jethanandani, A. Saxena, S. Pallagatti, M. Chen
WG Chair(s) : Jeffrey Haas, Reshad Rahman
Area Director(s) : Jim Guichard, Ketan Talaulikar, Gunter Van de Velde
--
auth48archive mailing list -- [email protected]
To unsubscribe send an email to [email protected]
