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

# Internet AD comments for draft-ietf-bfd-unsolicited-11
CC @ekline

## Nits

### S2

* "on a numbered interfaces" -> "on a numbered interface" perhaps?

# 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

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?

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

Thank you to Derek Atkins for the SECDIR review.

Thank you for addressing my DISCUSS and COMMENT feedback.

Thanks for addressing my discuss points and comments. Based on our email discussions and resolutions I am entering No Objection.

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

[Thanks for addressing my DISCUSS.]