Hi Reshad, Thanks for the review comment. Can you please check the following? Regards, - Xufeng > -----Original Message----- > From: Reshad Rahman (rrahman) [mailto:rrahman@xxxxxxxxx] > Sent: Friday, December 1, 2017 5:05 PM > To: Xufeng Liu <Xufeng_Liu@xxxxxxxxx>; ietf@xxxxxxxx > Cc: draft-ietf-rtgwg-yang-rip@xxxxxxxx; rtgwg@xxxxxxxx; rtgwg-chairs@xxxxxxxx; > rtg-bfd@xxxxxxxx > Subject: Re: Last Call: <draft-ietf-rtgwg-yang-rip-06.txt> (A YANG Data Model > for Routing Information Protocol (RIP)) to Proposed Standard > > Hi Xufeng, > > You are correct, I looked at the wrong version. > > If explicit-neighbors feature is not supported, would you want to have the BFD > client parameters (client-cfg-parms) configured in RIP? Otherwise operator > needs to look at neighbors discovered and configure parameters under BFD for > that neighbor. And when a new neighbor shows up, the same thing has to be > done again. [Xufeng] Yes. It would be better to have such a capability. Now that a newer version of the BFD model (draft-ietf-bfd-yang-07) have been posted, it would be better to use the new grouping "client-cfg-parms" and be consistent with other IGPs. Please review if the followings are the proper changes: module ietf-rip { + import ietf-bfd-types { + prefix "bfd-types"; + } container bfd { if-feature bfd; description "BFD configuration."; - leaf enabled { - type boolean; - default false; - description - "'true' if BFD is enabled for the interface."; - } + uses bfd-types:client-cfg-parms; } } +--rw interfaces | +--rw interface* [interface] | +--rw interface if:interface-ref | +--rw bfd {bfd}? - | | +--rw enabled? boolean + | | +--rw enable? boolean <== From grouping client-cfg-parms + | | +--rw local-multiplier? multiplier + | | +--rw (interval-config-type)? + | | +--:(tx-rx-intervals) + | | | +--rw desired-min-tx-interval uint32 + | | | +--rw required-min-rx-interval uint32 + | | +--:(single-interval) + | | +--rw min-interval uint32 [Xufeng] BTW. A comment about the leaf "enable" above: in most published models, "enabled" is used instead of "enable". Do you want to make it consistent? > > Please see email discussion with OSPF/ISIS YANG authors. > https://mailarchive.ietf.org/arch/msg/rtg-bfd/KNipAESw8fGKuUKrCxFlhdkRA0Y > > Regards, > Reshad. > > ________________________________________ > From: Xufeng Liu <Xufeng_Liu@xxxxxxxxx> > Sent: Friday, December 1, 2017 4:50 PM > To: Reshad Rahman (rrahman); ietf@xxxxxxxx > Cc: draft-ietf-rtgwg-yang-rip@xxxxxxxx; rtgwg@xxxxxxxx; rtgwg-chairs@xxxxxxxx; > rtg-bfd@xxxxxxxx > Subject: RE: Last Call: <draft-ietf-rtgwg-yang-rip-06.txt> (A YANG Data Model > for Routing Information Protocol (RIP)) to Proposed Standard > > Hi Reshad, > > Can you please double-check the revision 06 of the document? draft-ietf-rtgwg- > yang-rip-04 used bfd-grouping-base-cfg-parms, and was taken out by draft-ietf- > rtgwg-yang-rip-05. Please let us know if this is not the case, or we need to do > something differently. > > Thanks, > - Xufeng > > > -----Original Message----- > > From: Reshad Rahman (rrahman) [mailto:rrahman@xxxxxxxxx] > > Sent: Wednesday, November 29, 2017 11:49 AM > > To: ietf@xxxxxxxx > > Cc: draft-ietf-rtgwg-yang-rip@xxxxxxxx; rtgwg@xxxxxxxx; > > rtgwg-chairs@xxxxxxxx; rtg-bfd@xxxxxxxx > > Subject: Re: Last Call: <draft-ietf-rtgwg-yang-rip-06.txt> (A YANG > > Data Model for Routing Information Protocol (RIP)) to Proposed > > Standard > > > > Hi, > > > > The RIP YANG model uses bfd-grouping-base-cfg-parms from BFD YANG. > > That grouping does not exist in latest revision (it has been renamed). > > Also, as per discussions we had with OSPF/ISIS YANG authors, the > > grouping which should be used from BFD is client-cfg-parms. > > > > Regards, > > Reshad. > > ________________________________________ > > From: rtgwg <rtgwg-bounces@xxxxxxxx> on behalf of The IESG <iesg- > > secretary@xxxxxxxx> > > Sent: Tuesday, November 28, 2017 11:29 AM > > To: IETF-Announce > > Cc: draft-ietf-rtgwg-yang-rip@xxxxxxxx; rtgwg@xxxxxxxx; > > rtgwg-chairs@xxxxxxxx > > Subject: Last Call: <draft-ietf-rtgwg-yang-rip-06.txt> (A YANG Data > > Model for Routing Information Protocol (RIP)) to Proposed Standard > > > > The IESG has received a request from the Routing Area Working Group WG > > (rtgwg) to consider the following document: - 'A YANG Data Model for > > Routing Information Protocol (RIP)' > > <draft-ietf-rtgwg-yang-rip-06.txt> as Proposed Standard > > > > The IESG plans to make a decision in the next few weeks, and solicits > > final comments on this action. Please send substantive comments to the > > ietf@xxxxxxxx mailing lists by 2017-12-12. Exceptionally, comments may > > be sent to iesg@xxxxxxxx instead. In either case, please retain the > > beginning of the Subject line to allow automated sorting. > > > > Abstract > > > > > > This document describes a data model for the Routing Information > > Protocol (RIP). Both RIP version 2 and RIPng are covered. > > > > > > > > > > The file can be obtained via > > https://datatracker.ietf.org/doc/draft-ietf-rtgwg-yang-rip/ > > > > IESG discussion can be tracked via > > https://datatracker.ietf.org/doc/draft-ietf-rtgwg-yang-rip/ballot/ > > > > > > No IPR declarations have been submitted directly on this I-D. > > > > > > The document contains these normative downward references. > > See RFC 3967 for additional information: > > draft-bjorklund-netmod-rfc7223bis: A YANG Data Model for Interface > > Management (None - IETF stream) > > draft-ietf-netmod-revised-datastores: Network Management Datastore > > Architecture (None - IETF stream) > > draft-acee-netmod-rfc8022bis: A YANG Data Model for Routing > > Management (NDMA Version) (None - ) > > draft-bjorklund-netmod-rfc7277bis: A YANG Data Model for IP > > Management (None - IETF stream) > > draft-ietf-ospf-yang: Yang Data Model for OSPF Protocol (None - > > IETF stream) > > > > > > > > _______________________________________________ > > rtgwg mailing list > > rtgwg@xxxxxxxx > > https://www.ietf.org/mailman/listinfo/rtgwg