Re: Yangdoctors last call review of draft-ietf-bfd-yang-09

["Reshad Rahman (rrahman)" <[e-mail]>]

Hi Juergen,

Thanks again for the excellent review. We've just published rev12 to address your latest comments.

Please see inline.

Regards,
Reshad.

On 2018-03-13, 10:58 AM, "Juergen Schoenwaelder" <[e-mail]> wrote:

    On Sun, Mar 04, 2018 at 02:12:30PM +0000, Reshad Rahman (rrahman) wrote:
    > 
    > We have made the changes in revs 10 and 11 to address your comments . The exception is module ietf-bfd-types which did not get renamed per reason below.
    >
    
    Hi,
    
    here is my re-review of draft-ietf-bfd-yang. I think the document has
    significantly improved since the -09 version, the authors have done an
    excellent job to improve the document quality.
    
    I have mostly a few minor mostly editorial issues left, except the
    first one, which concerns the schema mount use case.
    
    - Thanks for clarifying that the modules can be used on standalone
      devices. The new text is helpful.
    
      For the LNE and NI use cases, does it make sense to detail the mount
      points that are used? My understanding is that schema mount requires
      that mount points are identified with a "mount-point" extension
      statement, i.e., you can't mount at arbitrary places in the
      hierarchy but only at places that have been designated as mount
      points.
    
      That all said, since your YANG modules are basically augmenting
      other YANG modules that may be mounted, you do not seem to need a
      separate schema mount. If my understanding is correct, then here is
      a starting point for making this clearer:
    
      OLD
    
        When used at the network device level, the BFD YANG model is used
        "as-is".  When the BFD model is to be used in a Logical Network
        Element or in a Network Instance, the approach taken is to do a
        schema-mount (see Schema Mount [I-D.ietf-netmod-schema-mount]) of the
        BFD model in the appropriate location.  For example, if an
        implementation supports BFD IP multihop in network instances, the
        implementation would do schema-mount of the BFD IP multihop model in
        a mount-point which resides in a network instance.
    
      NEW
    
        When used at the network device level, the BFD YANG model are used
        "as-is".  When the BFD YANG model is used in a Logical Network
        Element or in a Network Instance, then the BFD YANG model augments
        the mounted routing model for the Logical Network Element or the
        Network Instance.
    
      Note that with this change, you also do not need a reference to
      schema mount.
<RR> Done.
      
    - Since the different use cases (device, LNE, NI) are discussed right
      at the beginning of Section 2, it seems the following statements in
      Sections 2.5, 2.6, 2.7, 2.8, 2.9 are not really needed:
    
                                       The "bfd" node under control-plane-
       protocol can be used in a network device (top-level), or mounted in
       an LNE or in a network instance.
    
                                                The "ip-sh" node can be used
       in a network device (top-level), or mounted in an LNE or in a network
       instance.
    
                                                                The "ip-mh"
       node can be used in a network device (top-level), or mounted in an
       LNE or in a network instance.
    
                                  The "lag" node can be used in a network
       device (top-level), or mounted in an LNE or in a network instance.
    
                                                                 The "mpls"
       node can be used in a network device (top-level), or mounted in an
       LNE or in a network instance.
<RR> Done
    
    - The text at the beginning of Section 2.13 should also mention RFC
      8177 since you are importing it.
<RR> Done

    - It might be useful to give more explicit instructions to IANA. I
      assume you want IANA to update the iana-bfd-types module whenever
      changes are made to the "BFD Diagnostic Codes" registry and "BFD
      Authentication Types" registries. Giving clear instructions what
      IANA is expected to do and when is better than a soft statement such
      as "intended to reflect". But IANA is going to ask questions about
      this anyway during their review I assume.
<RR> Updated 5.1
    
    - The feature definitions in ietf-bfd-types have text of the form "as
      defined in RFC 5880" and perhaps it makes sense to add reference
      statements to these feature definitions. There are also a number of
      identities that say "as per RFC 588X" where perhaps reference
      statements should be added.
<RR> Added reference sections to the feature definitions and identities.
    
    - The text at the beginning of Section 2.13 should also	mention	RFC
      6991 since you are importing it. And you are also importing from
      RFC XXXX (the routing model).
<RR> 2.13 already mentions RFC 6991 but it was missing from 2.15 and 2.17 (it's been added). 2.13 already has mention of 8022bis (routing model). 8022bis is now rfc8349.

    - The text at the beginning of Section 2.16 should also mention
      that you import from RFC XXXX (the routing model).
<RR> We now mention rfc8349 (8022bis).
    
    - The text at the beginning of Section 2.17 should also mention that
      you import from RFC 6991 and from RFC XXXX (the routing model).
<RR> Added mention of RFC6991.
    
    - The text at the beginning of Section 2.18 should also mention that
      you import from RFC XXXX (the routing model).
<RR> We now mention rfc8349  (8022bis).
    
    - The text at the beginning of Section 2.19 should also mention that
      you import from RFC XXXX (the routing model).
<RR> We now mention rfc8349   (8022bis).
    
    - I have not validated the examples - I hope the authors have done so.
      They look more plausible than in the previous version I reviewed.
<RR> Yes we have validated them using yanglint.
    
    /js
    
    -- 
    Juergen Schoenwaelder           Jacobs University Bremen gGmbH
    Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
    Fax:   [phone]         <https://www.jacobs-university.de/>
    

--- Begin Message ---

A new version of I-D, draft-ietf-bfd-yang-12.txt
has been successfully submitted by Reshad Rahman and posted to the
IETF repository.

Name:		draft-ietf-bfd-yang
Revision:	12
Title:		YANG Data Model for Bidirectional Forwarding Detection (BFD)
Document date:	2018-03-20
Group:		bfd
Pages:		74
URL:            https://www.ietf.org/internet-drafts/draft-ietf-bfd-yang-12.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-bfd-yang/
Htmlized:       https://tools.ietf.org/html/draft-ietf-bfd-yang-12
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-bfd-yang
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-yang-12

Abstract:
   This document defines a YANG data model that can be used to configure
   and manage Bidirectional Forwarding Detection (BFD).

   The YANG modules in this document conform to the Network Management
   Datastore Architecture (NMDA).

                                                                                  


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.

The IETF Secretariat

--- End Message ---