Hello,

I have reviewed draft-acee-netmod-rfc8022bis-05. My conclusion is that the YANG modules part of the draft have been successfully modified in accordance with sec. '4.23.3 NMDA Transition Guidelines' of draft-ietf-netmod-rfc6087bis-14. The modifications are coherent with the ietf-interfa...@2017-08-17.yang module in draft-ietf-netmod-rfc7277bis-00 and ietf...@2017-08-21.yang module in draft-ietf-netmod-rfc7277bis-00.

Vladimir


Review of draft-acee-netmod-rfc8022bis-05.
Vladimir Vassilev
2017-10-30

'Abstract':
'Introduction 1':
 - Both Abstract and Sec 1. contain duplicated text which can be removed
from Abstract. The text in Sec 1. can be simplified:

OLD:
   This version of these YANG modules uses new names for these YANG
   models.  The main difference from the first version is that this
   version fully conforms to the Network Management Datastore
   Architecture (NMDA).  Consequently, this document obsoletes RFC 8022.
NEW:
   This version of the Routing Management data model supports the Network
Management Datastore Architecture (NMDA) [I-D.ietf-netmod-revised-datastores].


'7.  Routing Management YANG Module':

- Why should address-family identity be different e.g. mandatory "false"; for system created RIBs? I think this needs some explanation (Page 21):
           ...
           uses address-family {
             description
               "Address family of the RIB.

                It is mandatory for user-controlled RIBs.  For
                system-controlled RIBs it can be omitted; otherwise, it
                must match the address family of the corresponding state
                entry.";
             refine "address-family" {
               mandatory "false";
             }
           }
           ...

- Suggested change of 'base address-family;' -> 'base rt:address-family;' for identity ipv4 and ipv6 (ref. draft-ietf-netmod-rfc6087bis-14#section-4.2):

    o The local module prefix MUST be used instead of no prefix in
    all "default" statements for an "identityref" or "instance-identifier"
        data type

'8. IPv4 Unicast Routing Management YANG Module' (ietf-ipv4-unicast-rout...@2017-10-14.yang): '9. IPv6 Unicast Routing Management YANG Module' (ietf-ipv6-unicast-rout...@2017-10-14.yang):


- The ietf-ipv4-unicast-routing and ietf-ipv6-unicast-routing modules import the ietf-routing without revision (ref. rfc6087#section-4.6):


    o The revision-date substatement within the imports statement SHOULD be
    present if any groupings are used from the external module."


'Appendix D. Data Tree Example':

- The example in the Appendix D. has not been updated and it must be extended in order to demonstrate a usecase of operational datastore of configuration data with different origin (intended, system, etc.) similar to the 'Appendix C. Example Data' of draft-ietf-netmod-revised-datastores-05.


Nits:
 - s/Figures 1/Figure 1/
 - s/systemindependently/system independently/

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to