Authors, Thanks for continued work on the yang module. It does appear it's approaching a good level of maturity!
I have a few comments from my recent read-through. I'd like to encourage other members of the Working Group to review the module. I'd also like to encourage the authors to reach out to other protocol groups to check the suitability of the module for interaction with their protocols. Some stream of thought comments: - TTL seems to be only a property of multi-hop sessions. How do you configure GTSM for single-hop sessions? - In single-hop, sessions are operationally keyed on "interface". However, there's also a "out-interface" node. How are they intended to be different? - state-change-reason in notification is a string type. While this is probably the fastest path to getting some code written, it's also the least machine usable mechanism. Has there been any discussion among the authors on how that might otherwise be addressed? - time-in-previous-state is oddly a string. Why not a time of some sort? - Future-proofing observation: An mpls-fec is not required to be an IP address, although that is pretty much its only major manifestation at the moment. This may cause weirdness down the road. - mpls-fec is of type ip-address. FECs are typicall prefixes. - bfd-diagnostic is missing code point 9. (See IANA issues.) - Suggest adding the range restriction 0..31 to the description for bfd-diagnostic. - Naming elements such as nbor, conc, etc. are rather unnecessarily truncated. While I realize that yang is somewhat human readable, it's mostly for machine interaction. Reasonably expanded names make a module easier to read, especially to English as a second language parties. This, however, needs to be balanced against things like "admin" which is already present in other BFD documents. - In the bfd-auth-replay-protection description, please include citations to the specific section of RFC 5880. - The bfd-all-session grouping includes source-port and dest-port. This may not be relevant to all transports of BFD. What discussion have you given to restricting this, if any? - rx-ttl's description is a bit confusing to read. I think you are trying to suggest that the received TTL should be <= this value to be acceptable? - potential nit on "ttl"; ipv6 calls this hop-count. Any discussion on the naming of this type among the authors? Features: Echo and demand mode are not pervasively implemented for BFD. (I've not actually heard of an implementation of demand mode.) I suspect these elements should be covered by if-feature? While I realize the elements are optionally usable in the configuration leaves, the lack of a feature might lead a netconf implementation with the thought that they can use this feature. What has been the author discussion on this point? IANA management of some module components: Several elements in this draft are things that will regularly need to be maintained. Examples include: - bfd-path-type - bfd-auth-replay-protection - bfd-diagnostic I suspect we wish to place these components in a module/modules that are IANA maintained. I'm a bit behind in current yang practices, but I suspect we have something like this defined now. It unfortunately has the headache that it impacts name-spacing issues for the consuming modules. Timing hints: Has any discussion been given to an operational module that might suggest what timer values are acceptable to an implementation? Note: I'm not suggesting this as part of the core module, but it's a common "what timers does your implementation support" question that typically happens. On Fri, Mar 10, 2017 at 09:29:45PM +0000, Reshad Rahman (rrahman) wrote: > Main changes from rev 04 are: > - Removed augment of network-instance, added reference to schema-mount > - bfd is not top-level anymore, augments control-plane-protocol from > RFC8022 > - Addeds section on Interaction with other YANG modules > > > > Regards, > BFD YANG authors. > > On 2017-03-10, 4:26 PM, "Rtg-bfd on behalf of [email protected]" > <[email protected] on behalf of [email protected]> wrote: > > > > >A New Internet-Draft is available from the on-line Internet-Drafts > >directories. > >This draft is a work item of the Bidirectional Forwarding Detection of > >the IETF. > > > > Title : Yang Data Model for Bidirectional Forwarding > >Detection (BFD) > > Authors : Reshad Rahman > > Lianshu Zheng > > Santosh Pallagatti > > Mahesh Jethanandani > > Greg Mirsky > > Filename : draft-ietf-bfd-yang-05.txt > > Pages : 53 > > Date : 2017-03-10 > > > >Abstract: > > This document defines a YANG data model that can be used to configure > > and manage Bidirectional Forwarding Detection (BFD). > > > > > > > >The IETF datatracker status page for this draft is: > >https://datatracker.ietf.org/doc/draft-ietf-bfd-yang/ > > > >There's also a htmlized version available at: > >https://tools.ietf.org/html/draft-ietf-bfd-yang-05 > > > >A diff from the previous version is available at: > >https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-yang-05 > > > > > >Please note that it may take a couple of minutes from the time of > >submission > >until the htmlized version and diff are available at tools.ietf.org. > > > >Internet-Drafts are also available by anonymous FTP at: > >ftp://ftp.ietf.org/internet-drafts/ > >
