I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-bfd-unsolicited-10 Reviewer: Dan Romascanu Review Date: 2022-11-02 IETF LC End Date: 2022-11-14 IESG Telechat date: Not scheduled for a telechat Summary: This is a well-written and clear document that describes 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), with the goal of achieving operational simplification of "sessionless" applications using Bidirectional Forwarding Detection (BFD). The document is Ready from a Gen-ART perspective. A couple of editorial nits need clarification and possible fixes. Major issues: Minor issues: Nits/editorial comments: 1. Section 1 refers to draft-ietf-idr-rs-bfd which has the status Expired in the Datatracker. Is the intention to stay with the archived version of this Expired document? 2. Section 3 defines the new state variable Role as 'The role of the BFD session as per [RFC5880], section 6.1.'. However, RFC 5880 talks about role as an attribute of the system in session initialization rather than one of the session. > A system may take either an Active role or a Passive role in session initialization. A system taking the Active role MUST send BFD Control packets for a particular session, regardless of whether it has received any BFD packets for that session. A system taking the Passive role MUST NOT begin sending BFD packets for a particular session until it has received a BFD packet for that session, and thus has learned the remote system's discriminator value. At least one system MUST take the Active role (possibly both). The role that a system takes is specific to the application of BFD, and is outside the scope of this specification. I believe that wording in the two documents needs to be aligned.