Re: [Netconf] RGW YANG push -18 LC comments [part 1]

Martin Bjorklund <mbj@tail-f.com> Mon, 10 September 2018 09:49 UTC

Return-Path: <mbj@tail-f.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCD0C130E62 for <netconf@ietfa.amsl.com>; Mon, 10 Sep 2018 02:49:00 -0700 (PDT)
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 x9pUHA5qDE2r for <netconf@ietfa.amsl.com>; Mon, 10 Sep 2018 02:48:59 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 71DFB130E48 for <netconf@ietf.org>; Mon, 10 Sep 2018 02:48:59 -0700 (PDT)
Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id AD2041AE018A; Mon, 10 Sep 2018 11:48:58 +0200 (CEST)
Date: Mon, 10 Sep 2018 11:48:58 +0200
Message-Id: <20180910.114858.2047503111224561678.mbj@tail-f.com>
To: rwilton=40cisco.com@dmarc.ietf.org
Cc: alexander.clemm@huawei.com, netconf@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <8941118a-33de-22c7-cf9e-7a836c18c063@cisco.com>
References: <8b2bd7da-7fd3-907d-1df0-947ce2052904@cisco.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EB5CE72@sjceml521-mbs.china.huawei.com> <8941118a-33de-22c7-cf9e-7a836c18c063@cisco.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/I1zXRLqDR8Jrx2Fl_v8-2s-ozDg>
Subject: Re: [Netconf] RGW YANG push -18 LC comments [part 1]
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Sep 2018 09:49:01 -0000

Hi,

I have one comment on this thread.

Robert Wilton <rwilton=40cisco.com@dmarc.ietf.org> wrote:
> On 06/09/2018 20:35, Alexander Clemm wrote:

[...]

> >         (13) Rather than "No Sync on start", it might be better to refer to
> >         this
> >
> >         as  "sync on start", which could be defined as a boolean with default
> >
> >         true [I've not checked the YANG model]
> >
> >     <ALEX> it's not defined as a boolean but as a leaf of type empty. 
> >     (So, the "default" is in fact true, unless  no-sync-on-start is
> >     present).  I don't see a compelling reason to change this and suggest
> >     to keep this as-is.
> >
> >     </ALEX>
> >
> > OK.  I think that in YANG, particularly considering NMDA, it is
> > cleaner to model this as a boolean with default true, particularly if
> > you do a get-data request on the operational state, since it more
> > clearly and explicitly indicates whether sync-on-start is enabled.
> >
> > With the current model, on a get-data request against operation, the
> > server returns "no-synch-on-start", it is obvious that it won't
> > perform a sync-on-start, however, the reverse if the leaf isn't
> > present isn't quite so clear.  If it doesn't return
> > "no-synch-on-start" then that either means the device will perform
> > sync-on-start, or perhaps the node the server isn't returning any
> > information, or perhaps it has been deviated.  So, in summary, I think
> > that flags that turn something off, are better modeled with default
> > true, rather than as empty leafs.  Flags that turn something on can be
> > modeled equally well either way.
> > <ALEX-2>In terms of instantiation, I find empty leaves more elegant,
> > particularly if there is a default value.  I think <no-sync-on-start/>
> > is more elegant than <no-sync-on-start>True</no-sync-on-start>.
> > Would you be satisfied if we turn the default around, i.e. change
> > “no-sync-on-start” to “sync-on-start”, but keeping it an empty?
> >  </ALEX-2>
> RW: Yes, changing it to "sync-on-start" keeping the type as empty is
> fine.

But this would change the default behaviour that the WG has accepted.
I don't think this is a good change.  I agree with Robert's initial
comment that this should be modeled as a leaf 'sync-on-start' of type
boolean, with default true.  I prefer the better model before a more
elegant encoding.


/martin