Re: Comments on draft-ietf-bfd-unsolicited

[Reshad Rahman <[e-mail]>]

 Hi Mahesh,
Thanks for the thorough, and again apologies for the delay.
Please see inline.

    On Monday, January 3, 2022, 04:41:47 PM EST, Mahesh Jethanandani <[e-mail]> 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.<RR> As you may recall, initially this document was informational and that got changed when the YANG model got added. So in the authors view, at least when we last discussed this, this is an implementation addition and not a change to the BFD protocol as specified in RFC5880. But if the WG consensus is that we should treat this document as an update to RFC5880, that's acceptable to me.
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.<RR> Will add in next rev.

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.<RR>Both can be supported, will add text specifying that per-interface overrides global.

s/per-router/globally/g just to keep consistency in the text.<RR>Ack.

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.<RR>Will clarify.

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?<RR>It is the passive side, will update. Wrt would/should/SHOULD, I think it is MUST because of the MAY at the end of the 4th paragraph.

The sixth paragraph makes mention of a configurable parameter, but there is no such parameter in the YANG model.<RR>You are referring to the "period of time"? I'd rather remove the text which says "which may be configurable" than add this in the YANG. Implementations which support this can augment and add the config parameter.

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. <RR>By operational mode, we are not referring to the operational data in NMDA/YANG parlance, instead we mean "mode of operation" of BFD (which is configurable). And the state variable was meant to be an addition to RFC 5880 - Bidirectional Forwarding Detection (BFD) (so we do update 5880 after all...). I think you are right and that this section is confusing.

YANG Data Model:
Who is “We”? Also, please update reference of RFC 9127 to draft-ietf-bfd-rfc9127-bis.<RR> We will get rid of the "we" :-) Ack for 9127-bis.

Unsolicited BFD Hierarchy:
Remove reference to a separate container for operational data. See above point.<RR>Which container are you referring to? There is an unsolicited container under interfaces and globally for config. There is an unsolicited container under single-hop for unsolicited session state.

Unsolicited BFD Module
There is a redundant reference statement right after the Copyright paragraph and before the revision statement.<RR>I thought this was standard procedure. That's what 9127 has anyway.

In YANG, the parent name is not repeated. Therefore 
s/unsolicted-active/actives/unsolicited-passive/passive<RR>Ack.

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. <RR> It talks about sensitivity of unsolicited specific nodes. Which 9127 nodes are you referring to? 

Regards,Reshad.
Thanks.
Mahesh [e-mail]