Re: [netmod] WG Last Call: draft-ietf-netmod-rfc7277bis-00

Martin Bjorklund <mbj@tail-f.com> Mon, 18 December 2017 11:34 UTC

Return-Path: <mbj@tail-f.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED85E124B09 for <netmod@ietfa.amsl.com>; Mon, 18 Dec 2017 03:34:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ph2ktBcPuKkl for <netmod@ietfa.amsl.com>; Mon, 18 Dec 2017 03:34:16 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 357A8124239 for <netmod@ietf.org>; Mon, 18 Dec 2017 03:34:16 -0800 (PST)
Received: from localhost (unknown [173.38.220.60]) by mail.tail-f.com (Postfix) with ESMTPSA id ED37A1AE0311; Mon, 18 Dec 2017 12:34:14 +0100 (CET)
Date: Mon, 18 Dec 2017 12:32:56 +0100 (CET)
Message-Id: <20171218.123256.987905036621498990.mbj@tail-f.com>
To: vladimir@transpacket.com
Cc: netmod@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <b5b9198f-15ef-fd6c-bb5c-04c0ef49557c@transpacket.com>
References: <937fadab-b3f0-1246-8543-00cb4d6a5acd@transpacket.com> <20171216.104645.2140965470373068531.mbj@tail-f.com> <b5b9198f-15ef-fd6c-bb5c-04c0ef49557c@transpacket.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/lEWaCMsck2NfQGES9k0Apiz0B9w>
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-rfc7277bis-00
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, 18 Dec 2017 11:34:18 -0000

Hi,

Vladimir Vassilev <vladimir@transpacket.com>; wrote:
> On 12/16/2017 10:46 AM, Martin Bjorklund wrote:
> 
> > Hi,
> >
> > Vladimir Vassilev <vladimir@transpacket.com>; wrote:
> >> On 12/13/2017 04:26 PM, Vladimir Vassilev wrote:
> >>> Hi,
> >>>
> >>> On 12/13/2017 03:47 PM, Martin Bjorklund wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> Thanks for reporting this.  I'll add the missing origin.  But why did
> >>>> you think forwarding and mtu should be removed?
> >>> 1. IMO since <mtu> is not present in the <ipv4> container in the
> >>> Appendix A (<get-config>) example and does not have default value in
> >>> the model I still think it should be removed.
> >> Alternatively the ipv4/mtu node can be a good example of a
> >> origin="or:system" configuration.
> > Yes.
> >
> >>>>     In fact, I think I
> >>>> missed <enabled>,
> >>> 2. IMO both fixes adding <enabled> or removing <forwarding> should be
> >>> OK depending on the RFC6243 defined with-defaults capability
> >>> 'basic-mode' parameter advertised by the server. I was running the
> >>> example with basic-mode=explicit
> > Right.  I now have this:
> >
> >        <!-- other parameters from ietf-interfaces omitted -->
> >
> >        <ipv4 xmlns="urn:ietf:params:xml:ns:yang:ietf-ip">
> >          <enabled or:origin="or:default">true</enabled>
> >          <forwarding or:origin="or:default">false</forwarding>
> >          <mtu or:origin="or:system">1500</mtu>
> >          <address>
> >            <ip>192.0.2.1</ip>
> >            <prefix-length>24</prefix-length>
> >            <origin>static</origin>
> >          </address>
> >          <neighbor or:origin="or:learned">
> >            <ip>192.0.2.2</ip>
> >            <link-layer-address>00:01:02:03:04:05</link-layer-address>
> >          </neighbor>
> >        </ipv4>
> >        <ipv6 xmlns="urn:ietf:params:xml:ns:yang:ietf-ip">
> >          <enabled or:origin="or:default">true</enabled>
> >          <forwarding or:origin="or:default">false</forwarding>
> >          <mtu>1280</mtu>
> >          ...
> >
> > Do you think this is ok?
> Yes. The or:default data makes the example even better.
> 
> 1. However there is one more default value missing
> (/interfaces/interface[name='eth0']/enabled) for the example to be
> consistent

Note that the example has:

   <!-- other parameters from ietf-interfaces omitted -->

This covers the 'enabled' leaf (and more).  The idea is to let this
document focus on the ip parameters.

> 2. ... and in the last diff I unintentionally omitted the get-data
> output node <data> required namespace addition (this is also
> applicable to draft-ietf-netmod-7223bis-01):

Good catch!  I have applied this in both documents.

I also realized that the drafts don't use text from the latest
Security Considerations template; I have fixed that as well.


/martin




> 
> diff -u before2.xml after2.xml
> --- before2.xml    2017-12-18 11:41:54.029279321 +0100
> +++ after2.xml    2017-12-18 11:36:25.973850340 +0100
> @@ -1,4 +1,4 @@
> -     <data>
> +     <data
> xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-datastores">
>         <interfaces
>             xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"
>             xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type"
> @@ -7,6 +7,7 @@
>           <interface or:origin="or:intended">
>             <name>eth0</name>
>             <type>ianaift:ethernetCsmacd</type>
> +           <enabled or:origin="or:default">true</enabled>
>             <!-- other parameters from ietf-interfaces omitted -->
>             <ipv4 xmlns="urn:ietf:params:xml:ns:yang:ietf-ip">
>               <enabled or:origin="or:default">true</enabled>
> 
> 
> Vladimir
> >
> >
> > /martin
>