This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-art@ietf.org if you reply to or forward this review.

I have a couple comments focused around how to deal with overload or attacks using unsolicited BFD.

1) Section 7.1 
The formulations around the mitigations are poorly worded. 
a) First the lead in to the bullet list states that this is mandatory but it fails to use and RFC 2119/8174 words.
b) "Limit the feature to specific interfaces, and to single-hop BFD with "TTL=255" 
     [RFC5082]." I would think that this sentence would rather state that one MUST use the RFC 5082 security mechanism for the BFD traffic. What is unclear to me from not having read RFC 5082 in detail is if this mechanism works well for this traffic or gets additional traffic into problems due to scoping which appear to be interface wide. Thus, are further clarifications on usage needed?
c) "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." This mitigation usage is deployment dependent, thus better care in formulation related to this is needed. This appears to be a MUST unless in this particular situation and should be clearer. Also the actual support required for interop appears a bit weak without having looked into RFC 5880 in detail. But only a SHOULD support algorithm? 

2) Not being an expert in BFD and its control parts it appears that there are no mechanism for terminating an ongoing BFD session as the passive player in case of any overload. It is even unclear if there are any other mechanism than refusing to respond to a new session for the passive entity when getting unsolicitied BFD. So it would be good if the document could be more explicit if there are any action the passive entity can do if ending up with to many BFD sessions? I understand the goal here is to limit the number of potential peers as well as ensuring that they are trusted entities even before any packets are sent, but are there really no method to stop the session?

3) Section 7.2:
So this section lays out the "knobs" that are sensitive. But it appears to not really put any requirement on that one actually protects. Is this how things usually are done i YANG modules?