Skip to main content

YANG Data Model for Bidirectional Forwarding Detection (BFD)
draft-ietf-bfd-yang-17

Yes

(Martin Vigoureux)

No Objection

(Alexey Melnikov)
(Alvaro Retana)
(Ben Campbell)
(Deborah Brungard)
(Ignas Bagdonas)
(Mirja Kühlewind)
(Suresh Krishnan)
(Terry Manderson)

Note: This ballot was opened for revision 15 and is now closed.

Warren Kumari
(was Discuss) No Objection
Comment (2018-07-04 for -16) Unknown
Thank you.

I also had a few minor nits:
Nits:
Section 1:
"The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA) Network Management Datastore Architecture [RFC8342]. " 
The Department of Redundancy Department called and wants some of their words back please :-)

Section 2:
"Since BFD is used for liveliness detection of various forwarding
   paths, there is no uniform key to identify a BFD session.  So the BFD
   data model is split in multiple YANG modules where each module
   corresponds to one type of forwarding path."
I think this would be more readable as:
"... to identify a BFD session, and so the BFD..."  (hey, I said it was a nit)
Martin Vigoureux Former IESG member
Yes
Yes (for -15) Unknown

                            
Adam Roach Former IESG member
No Objection
No Objection (2018-07-03 for -16) Unknown
I have found one minor editorial issue on page 43:

>    notification singlehop-notification {
>      description
>        "Notification for BFD single-hop session state change. An " +
>        "implementation may rate-limit notifications, e.g. when a" +
>        "session is continuously changing state.";

Nit: add a space between "a" and the closing quotation mark.

(Note: this occurs on Pages 46, 50, 54, and 57 as well)
Alexey Melnikov Former IESG member
No Objection
No Objection (for -16) Unknown

                            
Alissa Cooper Former IESG member
(was Discuss) No Objection
No Objection (2018-07-19 for -16) Unknown
Looking forward to the discussion of my original DISCUSS in NETMOD. Here it was:

I will apologize in advance because this document may be sort of a casualty of this DISCUSS. I should have raised my point below at least two years ago if not four years ago when the first iana-* YANG module was registered, but the thought did not occur to me until now. 

It gives me some pause to see the name "iana" embedded in the file name, module name, namespace, and prefix of the module being defined in Sec. 2.12. I realize there is precedent here, but I question whether tying these kinds of modules specifically to IANA as the protocol parameter registry operator by name puts them on the most stable deployment footing under all possible circumstances. I am personally pleased as punch with the service we get from IANA, but that doesn't mean "IANA" will always be the name of the registry operator. The more modules that get created with this embedding, the more of them that may need to change in the unlikely event that the name of the registry operator changes. Lots of RFCs would need to change too, but embedding the name extends the potential problem to the modules themselves.

It wasn't clear to me whether there is some ops-area-wide convention around the embedding of "iana" in the names of modules to be maintained by IANA. I don't see this specifically referenced in RFC 7950 or RFC 6020. So I'd like to discuss whether a different naming convention could be established and used in this document and others going forward.

---

COMMENT:

Some further questions on Sec. 2.12:

Looking back at the other RFCs that have defined YANG modules to be maintained by IANA (7224, 7317, 8294, 8348), they use two different postal addresses for ICANN. Why? Furthermore, is "ICANN" really the right contact name, or should it be PTI?
Alvaro Retana Former IESG member
No Objection
No Objection (for -16) Unknown

                            
Ben Campbell Former IESG member
No Objection
No Objection (for -16) Unknown

                            
Benjamin Kaduk Former IESG member
(was Discuss) No Objection
No Objection (2018-08-02) Unknown
Thank you for your patience and continued discussion as we worked to resolve my DISCUSS point!
Deborah Brungard Former IESG member
No Objection
No Objection (for -16) Unknown

                            
Eric Rescorla Former IESG member
No Objection
No Objection (2018-07-04 for -16) Unknown
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D6374



COMMENTS
S 2.1.4.
>              Minimum TTL of incoming BFD control packets.
>   
>   2.1.4.  MPLS Traffic Engineering Tunnels
>   
>      For MPLS-TE tunnels, BFD is configured under the MPLS-TE tunnel since
>      the desired failure detection parameters is a property of the MPLS-TE

"parameters are"


S 2.8.
>   
>   2.8.  BFD over LAG hierarchy
>   
>      A "lag" node is added under the "bfd" node in control-plane-protocol.
>      The configuration and operational state data for each BFD LAG session
>      is under this "lag" node.

There seems to be a lot of replication (e.g., number of sessions). Is
it possible to somehow refactor this so that's common?
Ignas Bagdonas Former IESG member
No Objection
No Objection (for -16) Unknown

                            
Mirja Kühlewind Former IESG member
No Objection
No Objection (for -16) Unknown

                            
Suresh Krishnan Former IESG member
No Objection
No Objection (for -16) Unknown

                            
Terry Manderson Former IESG member
No Objection
No Objection (for -16) Unknown