Unsolicited Bidirectional Forwarding Detection (BFD) for Sessionless Applications
draft-ietf-bfd-unsolicited-16

[Ballot comment]
Discuss position cleared.

As a non-discuss (and non-blocking) comment, I do still find this hierarchical configuration to be somewhat complex on two points:

(1) The configuration is under optional feature statements both at the global level and the per-interface level, and I think that the model would allow neither feature to be specified, in which case the defaults would be ambiguous.  I’m sure that the WG has a good reason for why it is designed the way it is, but I can’t help wondering whether it would make the model cleaner/simpler to require support for the global level configuration, and only have per-interface level configuration under an optional feature.  I.e., if this was done, then logically, there are always well-defined default values without requiring evaluation of the must-statement.
(2) I don’t think that the descriptions are necessarily clear about if, and how, single-interval on the interface is allowed to override desired-min-tx-interval and required-min-rx-interval configured globally, or vice-versa.  Please consider whether it would be helpful to update the descriptions of these fields under the interface configuration to clarify these semantics.

Regards,
Rob

[Ballot comment]
# GEN AD review of draft-ietf-bfd-unsolicited-11

CC @larseggert

Thanks to Dan Romascanu for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/2NcfuVBkWLD_CcQyTciwKOz2Xac).

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Boilerplate

Document still refers to the "Simplified BSD License", which was corrected in
the TLP on September 21, 2021. It should instead refer to the "Revised BSD
License".

### Grammar/style

#### Section 1, paragraph 6
```
to the widely deployed BFD itself. Thus we believe that this proposal is in
                                    ^^^^
```
A comma may be missing after the conjunctive/linking adverb "Thus".

#### Section 4.2, paragraph 23
```
xtra cost of configuring matching key-chains at the two endpoints. If BFD aut
                                  ^^^^^^^^^^
```
This word is normally spelled as one.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

[Ballot comment]
For Section 5, it is common (but not mandatory) to put each IANA action in its own subsection.

The SHOULD at the top of Section 2 is peculiar.  It indicates you would only make this non-configurable in an implementation in some unusual circumstances.  What's an example?

[Ballot discuss]
Thanks for working on this specification.

Thanks to Magnus Westerlund for the TSVART review, based on that review and my own read, I am supporting both Lars's and Roman's discuss.

On top of that, as this document claims - "with "unsolicited BFD" there is potential risk for excessive resource usage by BFD from "unexpected" remote systems". This translates to me as potential injection of huge amount of traffic which is lacking a self-regulation mechanism in this specification. To large degrees the traffic volume could have random effects on the routing plane and what links are considered up etc. We can hide all these by saying "Deploy the feature only in certain "trustworthy" environment"", then I am completely missing the definition of "trustworthy" environment". I would like to discuss that.

[Ballot comment]
Additional comments -

* This document also says - "When an Unsolicited BFD session goes down, an implementation MAY retain the session state for a period of time. Retaining this state can be useful for operational purposes." I am missing any discussion on the reduced functionality or any indication if the selected period time has any advantages or disadvantages. To be honest, without proper discussion or indication of some default values, I would remove the entire sentence or if this is just an additional implementation advice, I would drop the normative MAY.

[Ballot discuss]
** Section 7.1

Limit the feature to specific interfaces, and to single-hop BFD
      with "TTL=255" [RFC5082].

Section 2.2 of RFC5082 says “set the TTL on the protocol packets to 255 (the maximum possible for IP) and then reject any protocol packets that come in from configured peers that do NOT have an inbound TTL of 255”. Guidance on dropping the packets based on TTL in RFC5082 appears to be missing here. 

** Section 7.1.  The following considerations are inconsistent:

-- “To mitigate such risks, the following measures are mandatory: … Apply "policy" to allow BFD packets only from certain subnets or hosts.”

Editorially (not discuss but related), why is policy in quotes?

Requiring this check conflicts with the less rigorous SHOULD in Section 2: “The source address of the BFD Control packet SHOULD be validated against expected routing protocol peer addresses on that interface.”

-- “To mitigate such risks, the following measures are mandatory: … Use BFD authentication, see [RFC5880].  In some environments, e.g. when using an IXP, BFD authentication can not be used … If BFD authentication is used, the Meticulous Keyed SHA1 mechanism SHOULD be used.”

The text first says using BFD authentication is mandatory, but then says it is not possible in certain environments.  Later is states that “if BFD is used”, but the text already said it was mandatory.

[Ballot comment]
Thank you to Derek Atkins for the SECDIR review.

** Section 7.1  Meticulous Keyed SHA1 is a stated as a SHOULD.  Is this intended to express a preference over MD5?  If so, perhaps this needs to be restated that “SHA1 MUST be used if it is supported.”

** Section 7.2

*  data nodes local-multiplier, desired-min-tx-interval, required-
      min-rx-interval and min-interval all impact the parameters of the
      unsolicited BFD IP single-hop sessions.

Please explicitly state the impact of write options on these parameters

[Ballot discuss]
This document attempts to do two things: specify "unsolicited BFD" and define a YANG model for its management.  I am happy to include both in the same document, but the specification of the protocol mechanisms falls short and results in a document that lacks clarity.  While YANG is the preferred management mechanism, it should be possible to implement and manage the feature without the model.

Most of my concerns are from Section 2 (line numbers from idnits):


154   Passive unsolicited BFD support MUST be disabled by default, and MUST
155   require explicit configuration to be enabled.  On the passive side,
156   the desired BFD parameters SHOULD be configurable.  The passive side
157   MAY also choose to use the parameters that the active side uses in
158   its BFD Control packets.  The "My Discriminator", however, MUST be
159   chosen to allow multiple unsolicited BFD sessions.

(A) "the desired BFD parameters SHOULD be configurable"

Which parameters are those?  The YANG model uses bfd-types:base-cfg-parms, which only includes a basic set.  The point here is that this document's specification part is incomplete because it doesn't specify which parameters "SHOULD be configurable".


(B) The YANG model offers global and per-interface configuration options.  The specification doesn't discuss hierarchical configuration or whether one type should take precedence over the other.  [Related to Rob's DISCUSS.]

This point was discussed on the mailing list, where it was pointed out that per-interface configuration should override global configuration [1], but that discussion is not reflected in the document.

[1] https://mailarchive.ietf.org/arch/msg/rtg-bfd/GI_eNtxcEeh2_vTl9zfq7K6V1X4


171   When the passive side receives an incoming BFD Control packet on a
172   numbered interfaces, the source address of that packet MUST belong to
173   the subnet of the interface on which the BFD packet is received.  The
174   source address of the BFD Control packet SHOULD be validated against
175   expected routing protocol peer addresses on that interface.

(C) "SHOULD be validated"

What does validating the source address "against expected routing protocol peer addresses on that interface" entail?  Is it just a comparison?  Please be explicit on what the normative behavior should be.

When is it ok to not validate?  Why is this behavior recommended and not required?

If the validation is performed, is there an expected action if the source address does not correspond to an "expected routing protocol peer addresses on that interface"?  Where does this "expected" list come from?  On a LAN, it seems like any address would be valid since a router doesn't know the list of IGP neighbors beforehand.


177   The passive side MUST then start sending BFD Control packets and
178   perform the necessary procedure for bringing up, maintaining and
179   tearing down the BFD session.  If the BFD session fails to get
180   established within certain specified time, or if an established BFD
181   session goes down, the passive side SHOULD stop sending BFD Control
182   packets and MAY delete the BFD session created until BFD Control
183   packets are initiated by the active side again.

(D) "If the BFD session fails to get established within certain specified time..."

[nit] s/within certain specified time/within a certain specified time

Where does a "certain specified time" come from?  Is it configurable?  Does it correspond to any of the state variables in rfc5880?


(E) "SHOULD stop sending BFD Control packets"

When is it ok not to stop sending BFD control packets?  Why would the node continue sending packets if the session is not established (or goes down)?  Why is this behavior recommended and not required?


185   When an Unsolicited BFD session goes down, an implementation MAY
186   retain the session state for a period of time.  Retaining this state
187   can be useful for operational purposes.

(F) Not exactly a contradiction, but confusing normative statements (between this paragraph and the one before): "MAY delete" vs "MAY retain" for the same event ("BFD session goes down").

[Ballot comment]
(0) I support Rob's and Lars' DISCUSS positions.

(1) The Introduction makes several claims that must be developed further or eliminated to avoid further confusion.

(1a)

131   The procedure described in this document could be applied to BFD for
132   Multihop paths [RFC5883].  However, because of security risks, this
133   document applies only to BFD for single IP hops [RFC5881].

At first glance, I didn't see anything in rfc5883 that would prevent a node in the passive role from following this specification.  What am I missing?

Aren't the security risks already addressed in rfc5883?


(1b)

135   Compared to the "Seamless BFD" [RFC7880], this proposal involves only
136   minor procedural enhancements to the widely deployed BFD itself.
137   Thus we believe that this proposal is inherently simpler in the
138   protocol itself and deployment.  As an example, it does not require
139   the exchange of BFD discriminators over an out-of-band channel before
140   BFD session bring-up.

Given that this proposal claims to be better (or at least simpler) than S-BFD, what should an operator consider when deciding which to use?  Are they covering similar use cases?  If this is so much better, why is rfc7880 not deprecated?


(1c)

142   When BGP Add-Path [RFC7911] is deployed at an IXP using a Route
143   Server, multiple BGP paths (when they exist) can be made available to
144   the clients of the Route Server as described in [RFC7947].  The
145   "unsolicited BFD" can be used in BGP route selection by these clients
146   to eliminate paths with "inaccessible nexthops".

I guess that this part ("inaccessible nexthops") refers to "unresolvable routes" (from §9.1.2.1/rfc4271).  Is that the correct assumption?

First, please be consistent with the terminology.

The text above says that ""unsolicited BFD" can be used in BGP route selection".  Where is the interaction of BFD (in general -- not just unsolicited BFD) and BGP specified? 


(2) I am confused by the indication that this document Updates rfc9314 because no change is proposed to that RFC.  Instead, the YANG model augments the model in rfc9314 with optional (to the base BFD) functionality.  In my opinion, this is different than a formal Update, which is why rfc5880/rfc5881 are not tagged as being Updated either.

[Because the use of the Updates tag is not clearly defined, then I'm not making this comment part of my DISCUSS.]



(3) The "BFD Protocol Security Considerations" (Section 7.1) also needs work:

458   The same security considerations and protection measures as those
459   described in [RFC5880] and [RFC5881] apply to this document.  In
460   addition, with "unsolicited BFD" there is potential risk for
461   excessive resource usage by BFD from "unexpected" remote systems.  To
462   mitigate such risks, the following measures are mandatory:

[minor] For clarity, consider using rfc2119 language above:  s/mandatory/REQUIRED

Note that the last two bullets are conditional statements, which may not be aligned with the intent of making the measures mandatory.


464   *  Limit the feature to specific interfaces, and to single-hop BFD
465       with "TTL=255" [RFC5082].

GTSM is already required in rfc5880/rfc5881.  Does it need to be required again?


466   *  Apply "policy" to allow BFD packets only from certain subnets or
467       hosts.

[nit] s/allow BFD packets/process BFD packets

Given the statement in the Introduction about this document applying only to single IP hops, it seems that "certain subnets" are unnecessary as all the addresses on connected interfaces should fall on the same subnet.

468   *  Deploy the feature only in certain "trustworthy" environment,
469       e.g., at an IXP, or between a provider and its customers.

If this measure is mandatory, please expand on what a ""trustworthy" environment" is.


470   *  Use BFD authentication, see [RFC5880].  In some environments, e.g.
471       when using an IXP, BFD authentication can not be used because of
472       the lack of coordination into the operation of the two endpoints
473       of the BFD session.  In other environments, e.g. when BFD is used
474       to track the next hop of static routes, it is possible to use BFD
475       authentication: this comes with the extra cost of configuring
476       matching key-chains at the two endpoints.  If BFD authentication
477       is used, the Meticulous Keyed SHA1 mechanism SHOULD be used.

[Ballot discuss]
Hi,

Thanks for this document.

Please see my comments below for more details, but I'm balloting discuss on 3 points:
(1) The document is somewhat unclear as to whether the configuration is applied hierarchically (I presume that it is, if not then my second discuss point is not valid and can be ignored).
(2) As specified, I don't think that the hierarchical configuration will work, because the interface level leaf "defaults" will override an explicit value configured globally.  I.e., logically, the interface level leaf, if in scope, will always have a value.
(3) The document should provide an instance-data example in the appendix to illustrate the use of this configuration.

Regards,
Rob

[Ballot comment]
Moderate level comments:                                                                                                                                                                                                                                                                                                                                                                   
                                                                                                                                                                                                                                                                                                                                                                                           
(1) p 3, sec 2.  Procedures for Unsolicited BFD                                                                                                                                                                                                                                                                                                                                             
                                                                                                                                                                                                                                                                                                                                                                                           
  When the passive side receives a BFD Control packet from the active                                                                                                                                                                                                                                                                                                                     
  side with 0 as "Your Discriminator" and does not find an existing BFD                                                                                                                                                                                                                                                                                                                   
  session, the passive side MAY create a matching BFD session toward                                                                                                                                                                                                                                                                                                                       
  the active side, if permitted by local configuration and policy.                                                                                                                                                                                                                                                                                                                         
                                                                                                                                                                                                                                                                                                                                                                                           
I'm surprised that this is only a MAY and not a SHOULD or MUST.  I.e., if the local configuration & policy allows passive BFD sessions why would they not be created?                                                                                                                                                                                                                       
                                                                                                                                                                                                                                                                                                                                                                                           
                                                                                                                                                                                                                                                                                                                                                                                           
(2) p 4, sec 4.1.  Unsolicited BFD Hierarchy                                                                                                                                                                                                                                                                                                                                               
                                                                                                                                                                                                                                                                                                                                                                                           
  *  Globally, i.e. for all interfaces.  This requires support for the                                                                                                                                                                                                                                                                                                                     
      "unsolicited-params-global" feature.                                                                                                                                                                                                                                                                                                                                                 
  *  For specific interfaces.  This requires support for the                                                                                                                                                                                                                                                                                                                               
      "unsolicited-params-per-interface" feature.                                                                                                                                                                                                                                                                                                                                           
                                                                                                                                                                                                                                                                                                                                                                                           
From this description, it is unclear to me whether the features enabling global or per-interface configuration are meant to be an either/or (in which case, the constraint could probably be expressed in the features), or whether a server is allowed to support configuration both globally and override the global configuration with interface specific configuration.  My subsequent discuss comments assume the latter.  Either way, it would be helpful for this text in this section (and probably the YANG module) to be a bit more explicit on this regard.                                                                                                                                                                                                                                                                                                                                                 
                                                                                                                                                                                                                                                                                                                                                                                           
                                                                                                                                                                                                                                                                                                                                                                                           
(3) p 8, sec 4.2.  Unsolicited BFD Module                                                                                                                                                                                                                                                                                                                                                   
                                                                                                                                                                                                                                                                                                                                                                                           
      augment "/rt:routing/rt:control-plane-protocols/"                                                                                                                                                                                                                                                                                                                                     
            + "rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh/"                                                                                                                                                                                                                                                                                                                         
            + "bfd-ip-sh:interfaces" {
        if-feature bfd-unsol:unsolicited-params-per-interface;
        description
          "Augmentation for BFD unsolicited on IP single-hop interface";
        container unsolicited {
          description
            "BFD IP single-hop interface unsolicited top level
            container";
          leaf enabled {
            type boolean;
            default false;

I'm not sure that you want a default value specified in the YANG here since this would have precedence over any explicitly configured global default value.


(4) p 8, sec 4.2.  Unsolicited BFD Module

            description
              "BFD unsolicited enabled on this interface.";
          }
          uses bfd-types:base-cfg-parms;

You have the same issue here as above, in that the default values directly associated with the leaves in this grouping will always take precedence over any configured global value.  I.e., the configuration, if properly implemented cannot be hierarchical.  The pragmatic solution is to copy the used grouping inline here and delete the default statements.  This has the advantage that the descriptions can also make the hierarchical behavior of the configuration explicit.


(5) p 9, sec 4.2.  Unsolicited BFD Module

    augment "/rt:routing/rt:control-plane-protocols/"
          + "rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh/"
          + "bfd-ip-sh:sessions/bfd-ip-sh:session" {
      description
        "Augmentation for BFD unsolicited on IP single-hop session";
        leaf role {
          type bfd-unsol:role;
          config false;
          description
            "Role of local system during BFD session initialization.";
        }
    }
  }
 

Please add an instance data example to an appendix to illustrate the use of this YANG model.  This helps readers and can further emphasize the hierarchical nature of the configuration.



Minor level comments:

(6) p 3, sec 2.  Procedures for Unsolicited BFD

  Passive unsolicited BFD support MUST be disabled by default, and MUST
  require explicit configuration to be enabled.  On the passive side,
  the desired BFD parameters SHOULD be configurable.  The passive side
  MAY also choose to use the parameters that the active side uses in
  its BFD Control packets.  The "My Discriminator", however, MUST be
  chosen to allow multiple unsolicited BFD sessions.

Rather then configured values on the passive side, did the authors consider setting minimum configuration limits?  E.g., rather than define desired send/receive limits, instead, configure lower bounds on what the minimum tx interval may be (to prevent DDOS attacks).



Nit level comments:

(7) p 3, sec 2.  Procedures for Unsolicited BFD

  The passive side MUST then start sending BFD Control packets and
  perform the necessary procedure for bringing up, maintaining and
  tearing down the BFD session.  If the BFD session fails to get
  established within certain specified time, or if an established BFD
  session goes down, the passive side SHOULD stop sending BFD Control
  packets and MAY delete the BFD session created until BFD Control
  packets are initiated by the active side again.

Nit, within certain specified => within a specified


(8) p 6, sec 4.2.  Unsolicited BFD Module

        Copyright (c) 2021 IETF Trust and the persons
        identified as authors of the code.  All rights reserved.

This copyright statement will need to be fixed.

[Ballot discuss]
# GEN AD review of draft-ietf-bfd-unsolicited-11

CC @larseggert

Thanks to Dan Romascanu for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/2NcfuVBkWLD_CcQyTciwKOz2Xac).

## Discuss

### Section 7.1, paragraph 3
```
    The same security considerations and protection measures as those
    described in [RFC5880] and [RFC5881] apply to this document.  In
    addition, with "unsolicited BFD" there is potential risk for
    excessive resource usage by BFD from "unexpected" remote systems.  To
    mitigate such risks, the following measures are mandatory:

    *  Limit the feature to specific interfaces, and to single-hop BFD
        with "TTL=255" [RFC5082].
    *  Apply "policy" to allow BFD packets only from certain subnets or
        hosts.
    *  Deploy the feature only in certain "trustworthy" environment,
        e.g., at an IXP, or between a provider and its customers.
    *  Use BFD authentication, see [RFC5880].  In some environments, e.g.
        when using an IXP, BFD authentication can not be used because of
        the lack of coordination into the operation of the two endpoints
        of the BFD session.  In other environments, e.g. when BFD is used
        to track the next hop of static routes, it is possible to use BFD
        authentication: this comes with the extra cost of configuring
        matching key-chains at the two endpoints.  If BFD authentication
        is used, the Meticulous Keyed SHA1 mechanism SHOULD be used.
```
BFD can be configured to send large volumes of traffic, and it sends
it without congestion control. When a past IESG approved BFD for
standardization in that form, it was exactly because both endpoints
needed to be configured, which significantly reduces the
possibility/impact of unilateral misconfiguration. I don't believe
the suggestions above provide nearly the same level of protection.
Also, if (all of?) these are mandatory, that needs to be made very
clear, i.e., using RFC2119 terms here and elsewhere in the document
(where it currently says these mechanisms are recommended...)

[Ballot comment]
## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Boilerplate

Document still refers to the "Simplified BSD License", which was corrected in
the TLP on September 21, 2021. It should instead refer to the "Revised BSD
License".

### Grammar/style

#### Section 1, paragraph 6
```
to the widely deployed BFD itself. Thus we believe that this proposal is in
                                    ^^^^
```
A comma may be missing after the conjunctive/linking adverb "Thus".

#### Section 4.2, paragraph 23
```
xtra cost of configuring matching key-chains at the two endpoints. If BFD aut
                                  ^^^^^^^^^^
```
This word is normally spelled as one.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

[Ballot comment]
Thanks for the work. I have only two minor comments:

1/ unusual location for the BCP14 template

2/ in section 7.1, either refer only to RFC 5082 or be IPv6-friendly (i.e., rephrase "TTL=255" as IPv6 does not have TTL ;-))

Regards

-éric

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-bfd-unsolicited-10. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete.

First, in the ns registry on the IETF XML Registry page located at:

https://www.iana.org/assignments/xml-registry/

a single, new namespace will be registered as follows:

ID: yang:ietf-bfd-unsolicited
URI: urn:ietf:params:xml:ns:yang:ietf-bfd-unsolicited
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Second, in the YANG Module Names registry on the YANG Parameters registry page located at:

https://www.iana.org/assignments/yang-parameters/

a single, new YANG module will be registered as follows:

Name: ietf-bfd-unsolicited
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-bfd-unsolicited
Prefix: bfd-unsol
Module:
Reference: [ RFC-to-be ]

While the YANG module name will be registered after the IESG approves the document, the YANG module file will be posted after the RFC Editor notifies us that the document has been published.

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Specialist

The following Last Call announcement was sent out (ends 2022-11-14):

From: The IESG
To: IETF-Announce
CC: Jeffrey Haas , bfd-chairs@ietf.org, draft-ietf-bfd-unsolicited@ietf.org, jgs@juniper.net, jhaas@pfrc.org, rtg-bfd@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Unsolicited BFD for Sessionless Applications) to Proposed Standard


The IESG has received a request from the Bidirectional Forwarding Detection
WG (bfd) to consider the following document: - 'Unsolicited BFD for
Sessionless Applications'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2022-11-14. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  For operational simplification of "sessionless" applications using
  Bidirectional Forwarding Detection (BFD), in this document we present
  procedures for "unsolicited BFD" that allow a BFD session to be
  initiated by only one side, and established without explicit per-
  session configuration or registration by the other side (subject to
  certain per-interface or global policies).

  We also introduce a new YANG module to configure and manage
  "unsolicited BFD".  The YANG module in this document is based on YANG
  1.1 as defined in RFC 7950 and conforms to the Network Management
  Datastore Architecture (NMDA) as described in RFC 8342.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-bfd-unsolicited/



No IPR declarations have been submitted directly on this I-D.

: (1) What type of RFC is being requested (BCP, Proposed Standard, Internet
: Standard, Informational, Experimental, or Historic)? Why is this the proper
: type of RFC? Is this type of RFC indicated in the title page header?

Proposed Standard, since this provides updates to the BFD YANG module.

: (2) The IESG approval announcement includes a Document Announcement Write-Up.
: Please provide such a Document Announcement Write-Up. Recent examples can be
: found in the "Action" announcements for approved documents. The approval
: announcement contains the following sections:
:
: Technical Summary:

This document describes a profile for the Bi-directional Forwarding Detection
(BFD) protocol for "sessionless" applications.  This permits a single active
side to initiate a BFD session with a passive "unsolicited" side.  The
unsolicited side does not require per-session configuration.

An example of such a session is protecting the reachability of a static route's
nexthop by configuring BFD on the static route without requiring the device
with the target nexthop to have the other half of the session configured.

: Working Group Summary:
:
: Was there anything in WG process that is worth noting? For example, was there
: controversy about particular points or were there decisions where the consensus
: was particularly rough?

This document was considered non-controversial and has been previously deployed
in multiple implementations.  Since the document includes an extension to the
BFD YANG module, publication was delayed until the dependent YANG module was on
its way to IETF publication as an RFC.

: Document Quality:
:
: Are there existing implementations of the protocol? Have a significant number
: of vendors indicated their plan to implement the specification? Are there any
: reviewers that merit special mention as having done a thorough review, e.g.,
: one that resulted in important changes or a conclusion that the document had no
: substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other
: expert review, what was its course (briefly)? In the case of a Media Type
: review, on what date was the request posted?

There are multiple implementations of this mechanism.  Since the BFD YANG module is
new (RFC 9127) as of this writeup, there are currently no implementations of the
augmentation module contained in this document.

: Personnel:
:
: Who is the Document Shepherd? Who is the Responsible Area Director?

Document Shepherd: Jeffrey Haas, BFD co-chair.
Responsible Area Director: John Scudder, Routing.

: (3) Briefly describe the review of this document that was performed by the
: Document Shepherd. If this version of the document is not ready for
: publication, please explain why the document is being forwarded to the IESG.

This document has been through multiple Working Group review cycles.  A number
of minor clarifications were done in the final revisions of the document as
part of resolving the last portion of Working Group Last Call comments.  These
revisions increased the clarity of the document.

: (4) Does the document Shepherd have any concerns about the depth or breadth of
: the reviews that have been performed?

No.

: (5) Do portions of the document need review from a particular or from broader
: perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or
: internationalization? If so, describe the review that took place.

No.

: (6) Describe any specific concerns or issues that the Document Shepherd has
: with this document that the Responsible Area Director and/or the IESG should be
: aware of? For example, perhaps he or she is uncomfortable with certain parts of
: the document, or has concerns whether there really is a need for it. In any
: event, if the WG has discussed those issues and has indicated that it still
: wishes to advance the document, detail those concerns here.

N/A.

: (7) Has each author confirmed that any and all appropriate IPR disclosures
: required for full conformance with the provisions of BCP 78 and BCP 79 have
: already been filed. If not, explain why?

The IPR attestations from the authors are documented in this mail thread:
https://mailarchive.ietf.org/arch/msg/rtg-bfd/sFDEO17QJ2h-zqOncfEwLclGpvs/

All authors have confirmed that there are no IPR declarations vs. the document.

: (8) Has an IPR disclosure been filed that references this document? If so,
: summarize any WG discussion and conclusion regarding the IPR disclosures.

No.

: (9) How solid is the WG consensus behind this document? Does it represent the
: strong concurrence of a few individuals, with others being silent, or does the
: WG as a whole understand and agree with it?

The BFD Working Group has a small number of technically informed participants.
This document received good review from active Working Group members.

: (10) Has anyone threatened an appeal or otherwise indicated extreme discontent?
: If so, please summarise the areas of conflict in separate email messages to the
: Responsible Area Director. (It should be in a separate email because this
: questionnaire is publicly available.)

No.

: (11) Identify any ID nits the Document Shepherd has found in this document.
: (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist).
: Boilerplate checks are not enough; this check needs to be thorough.

ID-Nits shows 3 long-line errors.  Since these errors are related to formatting style
for the YANG module, the shepherd would prefer that these are resolved by the
RFC Editor as they normalize the module for publication.

Similarly, the error of a reference to RFC 8342 is being deferred for resolution by
the RFC Editor as part of their style choices for this document.

: (12) Describe how the document meets any required formal review criteria, such
: as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The YANG module in this document was reviewed by the YANG doctors and the
points raised had been resolved.

The publication of this document was deferred until the BFD YANG module was
ready to hit RFC.  (That RFC-to-be is RFC 9127.)

: (13) Have all references within this document been identified as either
: normative or informative?

Yes.

: (14) Are there normative references to documents that are not ready for
: advancement or are otherwise in an unclear state? If such normative references
: exist, what is the plan for their completion?

No.

: (15) Are there downward normative references references (see RFC 3967)? If so,
: list these downward references to support the Area Director in the Last Call
: procedure.

No.

: (16) Will publication of this document change the status of any existing RFCs?
: Are those RFCs listed on the title page header, listed in the abstract, and
: discussed in the introduction? If the RFCs are not listed in the Abstract and
: Introduction, explain why, and point to the part of the document where the
: relationship of this document to the other RFCs is discussed. If this
: information is not in the document, explain why the WG considers it
: unnecessary.

No.

There was Working Group discussion as to whether this document would be an
update to RFC 5881.  After discussion within the working group and the Area
Director at the time, it was determined that there are no normative protocol
changes created in this document to that RFC.  This document merely documents a
profile of RFC 5881.

: (17) Describe the Document Shepherd's review of the IANA considerations
: section, especially with regard to its consistency with the body of the
: document. Confirm that all protocol extensions that the document makes are
: associated with the appropriate reservations in IANA registries. Confirm that
: any referenced IANA registries have been clearly identified. Confirm that newly
: created IANA registries include a detailed specification of the initial
: contents for the registry, that allocations procedures for future registrations
: are defined, and a reasonable name for the new registry has been suggested (see
: RFC 8126).

The IANA considerations as currently present in the document were the result of
addressing review issues from Tom Petch.  The current text has been reviewed and
found to be consistent with the body of the document.

: (18) List any new IANA registries that require Expert Review for future
: allocations. Provide any public guidance that the IESG would find useful in
: selecting the IANA Experts for these new registries.

N/A.

: (19) Describe reviews and automated checks performed by the Document Shepherd
: to validate sections of the document written in a formal language, such as XML
: code, BNF rules, MIB definitions, YANG modules, etc.

YANG checks have been done as part of document review.

: (20) If the document contains a YANG module, has the module been checked with
: any of the recommended validation tools
: (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and
: formatting validation? If there are any resulting errors or warnings, what is
: the justification for not fixing them at this time? Does the YANG module comply
: with the Network Management Datastore Architecture (NMDA) as specified in
: RFC8342?

The module was verified with yangvalidator.com.

: (1) What type of RFC is being requested (BCP, Proposed Standard, Internet
: Standard, Informational, Experimental, or Historic)? Why is this the proper
: type of RFC? Is this type of RFC indicated in the title page header?

Proposed Standard

: (2) The IESG approval announcement includes a Document Announcement Write-Up.
: Please provide such a Document Announcement Write-Up. Recent examples can be
: found in the "Action" announcements for approved documents. The approval
: announcement contains the following sections:
:
: Technical Summary:

This document describes a profile for the Bi-directional Forwarding Detection
(BFD) protocol for "sessionless" applications.  This permits a single active
side to initiate a BFD session with a passive "unsolicited" side.  The
unsolicited side does not require per-session configuration.

An example of such a session is protecting the reachability of a static route's
nexthop by configuring BFD on the static route without requiring the device
with the target nexthop to have the other half of the session configured.

: Working Group Summary:
:
: Was there anything in WG process that is worth noting? For example, was there
: controversy about particular points or were there decisions where the consensus
: was particularly rough?

This document was considered non-controversial and has been previously deployed
in multiple implementations.  Since the document includes an extension to the
BFD YANG module, publication was delayed until the dependent YANG module was on
its way to IETF publication as an RFC.

: Document Quality:
:
: Are there existing implementations of the protocol? Have a significant number
: of vendors indicated their plan to implement the specification? Are there any
: reviewers that merit special mention as having done a thorough review, e.g.,
: one that resulted in important changes or a conclusion that the document had no
: substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other
: expert review, what was its course (briefly)? In the case of a Media Type
: review, on what date was the request posted?

There are multiple implementations of this mechanism.  Since the BFD YANG module is
new (RFC 9127) as of this writeup, there are currently no implementations of the
augmentation module contained in this document.

: Personnel:
:
: Who is the Document Shepherd? Who is the Responsible Area Director?

Document Shepherd: Jeffrey Haas, BFD co-chair.
Responsible Area Director: John Scudder, Routing Chair

: (3) Briefly describe the review of this document that was performed by the
: Document Shepherd. If this version of the document is not ready for
: publication, please explain why the document is being forwarded to the IESG.

This document has been through multiple Working Group review cycles.  A number
of minor clarifications were done in the final revisions of the document as
part of resolving the last portion of Working Group Last Call comments.  These
revisions increased the clarity of the document.

: (4) Does the document Shepherd have any concerns about the depth or breadth of
: the reviews that have been performed?

No.

: (5) Do portions of the document need review from a particular or from broader
: perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or
: internationalization? If so, describe the review that took place.

No.

: (6) Describe any specific concerns or issues that the Document Shepherd has
: with this document that the Responsible Area Director and/or the IESG should be
: aware of? For example, perhaps he or she is uncomfortable with certain parts of
: the document, or has concerns whether there really is a need for it. In any
: event, if the WG has discussed those issues and has indicated that it still
: wishes to advance the document, detail those concerns here.

N/A.

: (7) Has each author confirmed that any and all appropriate IPR disclosures
: required for full conformance with the provisions of BCP 78 and BCP 79 have
: already been filed. If not, explain why?

The IPR attestations from the authors are documented in this mail thread:
https://mailarchive.ietf.org/arch/msg/rtg-bfd/sFDEO17QJ2h-zqOncfEwLclGpvs/

All authors have confirmed that there are no IPR declarations vs. the document.

: (8) Has an IPR disclosure been filed that references this document? If so,
: summarize any WG discussion and conclusion regarding the IPR disclosures.

No.

: (9) How solid is the WG consensus behind this document? Does it represent the
: strong concurrence of a few individuals, with others being silent, or does the
: WG as a whole understand and agree with it?

The BFD Working Group has a small number of technically informed participants.
This document received good review from active Working Group members.

: (10) Has anyone threatened an appeal or otherwise indicated extreme discontent?
: If so, please summarise the areas of conflict in separate email messages to the
: Responsible Area Director. (It should be in a separate email because this
: questionnaire is publicly available.)

No.

: (11) Identify any ID nits the Document Shepherd has found in this document.
: (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist).
: Boilerplate checks are not enough; this check needs to be thorough.

ID-Nits shows 3 long-line errors.  Since these errors are related to formatting style
for the YANG module, the shepherd would prefer that these are resolved by the
RFC Editor as they normalize the module for publication.

Similarly, the error of a reference to RFC 8342 is being deferred for resolution by
the RFC Editor as part of their style choices for this document.

: (12) Describe how the document meets any required formal review criteria, such
: as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The YANG module in this document was reviewed by the YANG doctors and the
points raised had been resolved.

The publication of this document was deferred until the BFD YANG module was
ready to hit RFC.  (That RFC-to-be is RFC 9127.)

: (13) Have all references within this document been identified as either
: normative or informative?

Yes.

: (14) Are there normative references to documents that are not ready for
: advancement or are otherwise in an unclear state? If such normative references
: exist, what is the plan for their completion?

No.

: (15) Are there downward normative references references (see RFC 3967)? If so,
: list these downward references to support the Area Director in the Last Call
: procedure.

No.

: (16) Will publication of this document change the status of any existing RFCs?
: Are those RFCs listed on the title page header, listed in the abstract, and
: discussed in the introduction? If the RFCs are not listed in the Abstract and
: Introduction, explain why, and point to the part of the document where the
: relationship of this document to the other RFCs is discussed. If this
: information is not in the document, explain why the WG considers it
: unnecessary.

No.

There was Working Group discussion as to whether this document would be an
update to RFC 5881.  After discussion within the working group and the Area
Director at the time, it was determined that there are no normative protocol
changes created in this document to that RFC.  This document merely documents a
profile of RFC 5881.

: (17) Describe the Document Shepherd's review of the IANA considerations
: section, especially with regard to its consistency with the body of the
: document. Confirm that all protocol extensions that the document makes are
: associated with the appropriate reservations in IANA registries. Confirm that
: any referenced IANA registries have been clearly identified. Confirm that newly
: created IANA registries include a detailed specification of the initial
: contents for the registry, that allocations procedures for future registrations
: are defined, and a reasonable name for the new registry has been suggested (see
: RFC 8126).

The IANA considerations as currently present in the document were the result of
addressing review issues from Tom Petch.  The current text has been reviewed and
found to be consistent with the body of the document.

: (18) List any new IANA registries that require Expert Review for future
: allocations. Provide any public guidance that the IESG would find useful in
: selecting the IANA Experts for these new registries.

N/A.

: (19) Describe reviews and automated checks performed by the Document Shepherd
: to validate sections of the document written in a formal language, such as XML
: code, BNF rules, MIB definitions, YANG modules, etc.

YANG checks have been done as part of document review.

: (20) If the document contains a YANG module, has the module been checked with
: any of the recommended validation tools
: (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and
: formatting validation? If there are any resulting errors or warnings, what is
: the justification for not fixing them at this time? Does the YANG module comply
: with the Network Management Datastore Architecture (NMDA) as specified in
: RFC8342?

The module was verified with yangvalidator.com.

: (1) What type of RFC is being requested (BCP, Proposed Standard, Internet
: Standard, Informational, Experimental, or Historic)? Why is this the proper
: type of RFC? Is this type of RFC indicated in the title page header?

Proposed Standard

: (2) The IESG approval announcement includes a Document Announcement Write-Up.
: Please provide such a Document Announcement Write-Up. Recent examples can be
: found in the "Action" announcements for approved documents. The approval
: announcement contains the following sections:
:
: Technical Summary:

This document describes a profile for the Bi-directional Forwarding Detection
(BFD) protocol for "sessionless" applications.  This permits a single active
side to initiate a BFD session with a passive "unsolicited" side.  The
unsolicited side does not require per-session configuration.

An example of such a session is protecting the reachability of a static route's
nexthop by configuring BFD on the static route without requiring the device
with the target nexthop to have the other half of the session configured.

: Working Group Summary:
:
: Was there anything in WG process that is worth noting? For example, was there
: controversy about particular points or were there decisions where the consensus
: was particularly rough?

This document was considered non-controversial and has been previously deployed
in multiple implementations.  Since the document includes an extension to the
BFD YANG module, publication was delayed until the dependent YANG module was on
its way to IETF publication as an RFC.

: Document Quality:
:
: Are there existing implementations of the protocol? Have a significant number
: of vendors indicated their plan to implement the specification? Are there any
: reviewers that merit special mention as having done a thorough review, e.g.,
: one that resulted in important changes or a conclusion that the document had no
: substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other
: expert review, what was its course (briefly)? In the case of a Media Type
: review, on what date was the request posted?

There are multiple implementations of this mechanism.  Since the BFD YANG module is
new (RFC 9127) as of this writeup, there are currently no implementations of the
augmentation module contained in this document.

: Personnel:
:
: Who is the Document Shepherd? Who is the Responsible Area Director?

Document Shepherd: Jeffrey Haas, BFD co-chair.
Responsible Area Director: John Scudder, Routing Chair

: (3) Briefly describe the review of this document that was performed by the
: Document Shepherd. If this version of the document is not ready for
: publication, please explain why the document is being forwarded to the IESG.

This document has been through multiple Working Group review cycles.  A number
of minor clarifications were done in the final revisions of the document as
part of resolving the last portion of Working Group Last Call comments.  These
revisions increased the clarity of the document.

: (4) Does the document Shepherd have any concerns about the depth or breadth of
: the reviews that have been performed?

No.

: (5) Do portions of the document need review from a particular or from broader
: perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or
: internationalization? If so, describe the review that took place.

No.

: (6) Describe any specific concerns or issues that the Document Shepherd has
: with this document that the Responsible Area Director and/or the IESG should be
: aware of? For example, perhaps he or she is uncomfortable with certain parts of
: the document, or has concerns whether there really is a need for it. In any
: event, if the WG has discussed those issues and has indicated that it still
: wishes to advance the document, detail those concerns here.

N/A.

: (7) Has each author confirmed that any and all appropriate IPR disclosures
: required for full conformance with the provisions of BCP 78 and BCP 79 have
: already been filed. If not, explain why?

The IPR attestations from the authors are documented in this mail thread:
https://mailarchive.ietf.org/arch/msg/rtg-bfd/sFDEO17QJ2h-zqOncfEwLclGpvs/

All authors have confirmed that there are no IPR declarations vs. the document.

: (8) Has an IPR disclosure been filed that references this document? If so,
: summarize any WG discussion and conclusion regarding the IPR disclosures.

No.

: (9) How solid is the WG consensus behind this document? Does it represent the
: strong concurrence of a few individuals, with others being silent, or does the
: WG as a whole understand and agree with it?

The BFD Working Group has a small number of technically informed participants.
This document received good review from active Working Group members.

: (10) Has anyone threatened an appeal or otherwise indicated extreme discontent?
: If so, please summarise the areas of conflict in separate email messages to the
: Responsible Area Director. (It should be in a separate email because this
: questionnaire is publicly available.)

No.

: (11) Identify any ID nits the Document Shepherd has found in this document.
: (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist).
: Boilerplate checks are not enough; this check needs to be thorough.

ID-Nits shows 3 long-line errors.  Since these errors are related to formatting style
for the YANG module, the shepherd would prefer that these are resolved by the
RFC Editor as they normalize the module for publication.

Similarly, the error of a reference to RFC 8342 is being deferred for resolution by
the RFC Editor as part of their style choices for this document.

: (12) Describe how the document meets any required formal review criteria, such
: as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The YANG module in this document was reviewed by the YANG doctors and the
points raised had been resolved.

The publication of this document was deferred until the BFD YANG module was
ready to hit RFC.  (That RFC-to-be is RFC 9127.)

: (13) Have all references within this document been identified as either
: normative or informative?

Yes.

: (14) Are there normative references to documents that are not ready for
: advancement or are otherwise in an unclear state? If such normative references
: exist, what is the plan for their completion?

No.

: (15) Are there downward normative references references (see RFC 3967)? If so,
: list these downward references to support the Area Director in the Last Call
: procedure.

No.

: (16) Will publication of this document change the status of any existing RFCs?
: Are those RFCs listed on the title page header, listed in the abstract, and
: discussed in the introduction? If the RFCs are not listed in the Abstract and
: Introduction, explain why, and point to the part of the document where the
: relationship of this document to the other RFCs is discussed. If this
: information is not in the document, explain why the WG considers it
: unnecessary.

No.

There was Working Group discussion as to whether this document would be an
update to RFC 5881.  After discussion within the working group and the Area
Director at the time, it was determined that there are no normative protocol
changes created in this document to that RFC.  This document merely documents a
profile of RFC 5881.

: (17) Describe the Document Shepherd's review of the IANA considerations
: section, especially with regard to its consistency with the body of the
: document. Confirm that all protocol extensions that the document makes are
: associated with the appropriate reservations in IANA registries. Confirm that
: any referenced IANA registries have been clearly identified. Confirm that newly
: created IANA registries include a detailed specification of the initial
: contents for the registry, that allocations procedures for future registrations
: are defined, and a reasonable name for the new registry has been suggested (see
: RFC 8126).

The IANA considerations as currently present in the document were the result of
addressing review issues from Tom Petch.  The current text has been reviewed and
found to be consistent with the body of the document.

: (18) List any new IANA registries that require Expert Review for future
: allocations. Provide any public guidance that the IESG would find useful in
: selecting the IANA Experts for these new registries.

N/A.

: (19) Describe reviews and automated checks performed by the Document Shepherd
: to validate sections of the document written in a formal language, such as XML
: code, BNF rules, MIB definitions, YANG modules, etc.

YANG checks have been done as part of document review.

: (20) If the document contains a YANG module, has the module been checked with
: any of the recommended validation tools
: (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and
: formatting validation? If there are any resulting errors or warnings, what is
: the justification for not fixing them at this time? Does the YANG module comply
: with the Network Management Datastore Architecture (NMDA) as specified in
: RFC8342?

The module was verified with yangvalidator.com.

: (1) What type of RFC is being requested (BCP, Proposed Standard, Internet
: Standard, Informational, Experimental, or Historic)? Why is this the proper
: type of RFC? Is this type of RFC indicated in the title page header?

Proposed Standard

: (2) The IESG approval announcement includes a Document Announcement Write-Up.
: Please provide such a Document Announcement Write-Up. Recent examples can be
: found in the "Action" announcements for approved documents. The approval
: announcement contains the following sections:
:
: Technical Summary:

This document describes a profile for the Bi-directional Forwarding Detection
(BFD) protocol for "sessionless" applications.  This permits a single active
side to initiate a BFD session with a passive "unsolicited" side.  The
unsolicited side does not require per-session configuration.

An example of such a session is protecting the reachability of a static route's
nexthop by configuring BFD on the static route without requiring the device
with the target nexthop to have the other half of the session configured.

: Working Group Summary:
:
: Was there anything in WG process that is worth noting? For example, was there
: controversy about particular points or were there decisions where the consensus
: was particularly rough?

This document was considered non-controversial and has been previously deployed
in multiple implementations.  Since the document includes an extension to the
BFD YANG module, publication was delayed until the dependent YANG module was on
its way to IETF publication as an RFC.

: Document Quality:
:
: Are there existing implementations of the protocol? Have a significant number
: of vendors indicated their plan to implement the specification? Are there any
: reviewers that merit special mention as having done a thorough review, e.g.,
: one that resulted in important changes or a conclusion that the document had no
: substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other
: expert review, what was its course (briefly)? In the case of a Media Type
: review, on what date was the request posted?

There are multiple implementations of this mechanism.  Since the YANG module is
new and is heading toward RFC as of this writeup, there are currently no
implementations of the augmentation module contained in this document.  That
YANG module has received YANG doctor review.

: Personnel:
:
: Who is the Document Shepherd? Who is the Responsible Area Director?

Document Shepherd: Jeffrey Haas, BFD co-chair.
Responsible Area Director: John Scudder, Routing Chair

: (3) Briefly describe the review of this document that was performed by the
: Document Shepherd. If this version of the document is not ready for
: publication, please explain why the document is being forwarded to the IESG.

This document has been through multiple Working Group review cycles.  A number
of minor clarifications were done in the final revisions of the document as
part of resolving the last portion of Working Group Last Call comments.  These
revisions increased the clarity of the document.

: (4) Does the document Shepherd have any concerns about the depth or breadth of
: the reviews that have been performed?

No.

: (5) Do portions of the document need review from a particular or from broader
: perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or
: internationalization? If so, describe the review that took place.

No.

: (6) Describe any specific concerns or issues that the Document Shepherd has
: with this document that the Responsible Area Director and/or the IESG should be
: aware of? For example, perhaps he or she is uncomfortable with certain parts of
: the document, or has concerns whether there really is a need for it. In any
: event, if the WG has discussed those issues and has indicated that it still
: wishes to advance the document, detail those concerns here.

N/A.

: (7) Has each author confirmed that any and all appropriate IPR disclosures
: required for full conformance with the provisions of BCP 78 and BCP 79 have
: already been filed. If not, explain why?

The IPR attestations from the authors are documented in this mail thread:
https://mailarchive.ietf.org/arch/msg/rtg-bfd/sFDEO17QJ2h-zqOncfEwLclGpvs/

All authors have confirmed that there are no IPR declarations vs. the document.

: (8) Has an IPR disclosure been filed that references this document? If so,
: summarize any WG discussion and conclusion regarding the IPR disclosures.

No.

: (9) How solid is the WG consensus behind this document? Does it represent the
: strong concurrence of a few individuals, with others being silent, or does the
: WG as a whole understand and agree with it?

The BFD Working Group has a small number of technically informed participants.
This document received good review from active Workign Group members.

: (10) Has anyone threatened an appeal or otherwise indicated extreme discontent?
: If so, please summarise the areas of conflict in separate email messages to the
: Responsible Area Director. (It should be in a separate email because this
: questionnaire is publicly available.)

No.

: (11) Identify any ID nits the Document Shepherd has found in this document.
: (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist).
: Boilerplate checks are not enough; this check needs to be thorough.

ID-Nits points out two obsolete normative references in the YANG boilerplate in
the Security Considerations.  The RFC Editor should replace this portion of
text with the current accepted boilerplate text prior to publication.

: (12) Describe how the document meets any required formal review criteria, such
: as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The YANG module in this document was reviewed by the YANG doctors and the
points raised had been resolved.

The publication of this document was deferred until the BFD YANG module was
ready to hit RFC.  (That RFC-to-be is RFC 9127.)

: (13) Have all references within this document been identified as either
: normative or informative?

Yes.

: (14) Are there normative references to documents that are not ready for
: advancement or are otherwise in an unclear state? If such normative references
: exist, what is the plan for their completion?

No.  The pending BFD Yang module is about ready to be published and this
reference may be updated by the RFC Editor.

: (15) Are there downward normative references references (see RFC 3967)? If so,
: list these downward references to support the Area Director in the Last Call
: procedure.

No.

: (16) Will publication of this document change the status of any existing RFCs?
: Are those RFCs listed on the title page header, listed in the abstract, and
: discussed in the introduction? If the RFCs are not listed in the Abstract and
: Introduction, explain why, and point to the part of the document where the
: relationship of this document to the other RFCs is discussed. If this
: information is not in the document, explain why the WG considers it
: unnecessary.

No.

There was Working Group discussion as to whether this document would be an
update to RFC 5881.  After discussion within the working group and the Area
Director at the time, it was determined that there are no normative protocol
changes created in this document to that RFC.  This document merely documents a
profile of RFC 5881.

: (17) Describe the Document Shepherd's review of the IANA considerations
: section, especially with regard to its consistency with the body of the
: document. Confirm that all protocol extensions that the document makes are
: associated with the appropriate reservations in IANA registries. Confirm that
: any referenced IANA registries have been clearly identified. Confirm that newly
: created IANA registries include a detailed specification of the initial
: contents for the registry, that allocations procedures for future registrations
: are defined, and a reasonable name for the new registry has been suggested (see
: RFC 8126).

N/A.

: (18) List any new IANA registries that require Expert Review for future
: allocations. Provide any public guidance that the IESG would find useful in
: selecting the IANA Experts for these new registries.

N/A.

: (19) Describe reviews and automated checks performed by the Document Shepherd
: to validate sections of the document written in a formal language, such as XML
: code, BNF rules, MIB definitions, YANG modules, etc.

YANG checks hae been done as part of document review.

: (20) If the document contains a YANG module, has the module been checked with
: any of the recommended validation tools
: (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and
: formatting validation? If there are any resulting errors or warnings, what is
: the justification for not fixing them at this time? Does the YANG module comply
: with the Network Management Datastore Architecture (NMDA) as specified in
: RFC8342?

The module was verified with yangvalidator.com.
A single nit regarding line length was returned to the authors for correction.