Hi Authors, I read through the draft. Thanks for putting together a short and readable document. I had the following comments/questions on the Unsolicited BFD for Sessionless Applications draft. Some of the comments are nits, while others are a little more substantive.
Abstract: I believe that by proposing this solution, you are updating RFC 5880. But the Abstract or draft makes no mention of it. Introduction: The Abstract mentions that a YANG model is also proposed, but the Introduction section does not. I believe a clear mention that the YANG model proposed is a YANG 1.1 model (RFC 7950) would be helpful. The fact that the model in NMDA compliant can then be mentioned in this section, rather than in Abstract, which is as its name suggests - an Abstract. The details should be mentioned in the Introduction. Procedures for Unsolicited BFD & State Variable: The procedure seems simple enough, although a few more updates would be helpful. For example, can a given router be configured both globally and per interface? If not, it should be added in the procedure, and a must statement to that effect should be added to the YANG model. If both can be supported, then there should be an explanation as to which parameters take effect for a given session, and if per-interface parameters override global parameters. s/per-router/globally/g just to keep consistency in the text. The third paragraph says “The passive side does not send Control packets”. I think you mean to say that the passive side does not send Control packets initially or on its own, but does in response to the active side sending them. In the fifth paragraph it is not clear what “It” means. Does “it" mean the active or the passive side? If this paragraph was part of the fourth paragraph I could deduce that you are talking about passive side, but since this is a new paragraph, it is not clear. Also, I see the use of word “would” in the paragraph. Do you mean should, or more precisely SHOULD instead? The sixth paragraph makes mention of a configurable parameter, but there is no such parameter in the YANG model. The draft mentions an active and passive role towards the end of this section, and the beginning of the next section. The next section is titled “State Variable”, but there is talk of “configuring" operational mode. State variables are not configurable, are ‘config false’, and operational mode is certainly not “configured”. I think you mean administrative mode. If so, a separate state variable is not required per NMDA, and the same variable will represent both admin and operational status. I would drop section 3, and roll the discussion of the UnsolictedRole into Section 2, and explain how the UnsolictedRole is both configured and its operational status retrieved using NMDA. YANG Data Model: Who is “We”? Also, please update reference of RFC 9127 to draft-ietf-bfd-rfc9127-bis. Unsolicited BFD Hierarchy: Remove reference to a separate container for operational data. See above point. Unsolicited BFD Module There is a redundant reference statement right after the Copyright paragraph and before the revision statement. In YANG, the parent name is not repeated. Therefore s/unsolicted-active/active s/unsolicited-passive/passive YANG Module Security Considerations: The section highlights the data nodes that are sensitive/vulnerable, but most of the nodes it describes as sensitive are imported from RFC 9127. It should defer to the Security Considerations of that RFC, unless it is changing those variables meaningfully. Thanks. Mahesh Jethanandani mjethanand...@gmail.com
