I have not received any comments or questions regarding this e-mail. Wondering if it hit the bit bucket :-)
> On Jan 3, 2022, at 1:41 PM, Mahesh Jethanandani <mjethanand...@gmail.com> > wrote: > > 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 <mailto:mjethanand...@gmail.com> > > > > > > Mahesh Jethanandani mjethanand...@gmail.com
