[netmod] review of draft-acee-netmod-rfc8022bis-05

Vladimir Vassilev <vladimir@transpacket.com> Mon, 30 October 2017 00:43 UTC

Return-Path: <vladimir@transpacket.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 4DB8513F652 for <netmod@ietfa.amsl.com>; Sun, 29 Oct 2017 17:43:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 7KEH62aYHp-9 for <netmod@ietfa.amsl.com>; Sun, 29 Oct 2017 17:43:10 -0700 (PDT)
Received: from mail.transpacket.com (s91205186171.blix.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CFEC13F5F4 for <netmod@ietf.org>; Sun, 29 Oct 2017 17:43:09 -0700 (PDT)
Received: from localhost (localhost []) by mail.transpacket.com (Postfix) with ESMTP id 5A1B01404EA6 for <netmod@ietf.org>; Mon, 30 Oct 2017 01:43:07 +0100 (CET)
Received: from mail.transpacket.com ([]) by localhost (mail.transpacket.com []) (amavisd-new, port 10032) with ESMTP id lSAP1rlLGGmV for <netmod@ietf.org>; Mon, 30 Oct 2017 01:43:07 +0100 (CET)
Received: from localhost (localhost []) by mail.transpacket.com (Postfix) with ESMTP id 2F4321404EA1 for <netmod@ietf.org>; Mon, 30 Oct 2017 01:43:07 +0100 (CET)
Received: from mail.transpacket.com ([]) by localhost (mail.transpacket.com []) (amavisd-new, port 10026) with ESMTP id OeHqMxVAGzf5 for <netmod@ietf.org>; Mon, 30 Oct 2017 01:43:07 +0100 (CET)
Received: from [] (unknown []) by mail.transpacket.com (Postfix) with ESMTPSA id E02251404DB9 for <netmod@ietf.org>; Mon, 30 Oct 2017 01:43:06 +0100 (CET)
From: Vladimir Vassilev <vladimir@transpacket.com>
To: "netmod@ietf.org" <netmod@ietf.org>
Message-ID: <4b313b03-73e2-1633-5936-4526ca67f820@transpacket.com>
Date: Mon, 30 Oct 2017 01:43:05 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.6.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/2Rh6wpzfZWCuFDyXCjErnyfK0lE>
Subject: [netmod] review of draft-acee-netmod-rfc8022bis-05
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Oct 2017 00:43:12 -0000


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-interfaces@2017-08-17.yang module in 
draft-ietf-netmod-rfc7277bis-00 and ietf-ip@2017-08-21.yang module in 


Review of draft-acee-netmod-rfc8022bis-05.
Vladimir Vassilev

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

    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.
    This version of the Routing Management data model supports the Network
    Management Datastore Architecture (NMDA) 

'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 {
                "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
              refine "address-family" {
                mandatory "false";

  - Suggested change of 'base address-family;' -> 'base 
rt:address-family;' for identity ipv4 and ipv6 (ref. 

     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' 
'9.  IPv6 Unicast Routing Management YANG Module' 

  - 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 

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