Re: [netmod] upcoming adoptions

Martin Bjorklund <mbj@tail-f.com> Thu, 07 September 2017 11:12 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 F3FFA1329AD; Thu, 7 Sep 2017 04:12:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=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 SCxT8KidL7Wj; Thu, 7 Sep 2017 04:12:23 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 41D33132EEA; Thu, 7 Sep 2017 04:12:23 -0700 (PDT)
Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 0F7DB1AE0312; Thu, 7 Sep 2017 13:12:21 +0200 (CEST)
Date: Thu, 07 Sep 2017 13:10:48 +0200 (CEST)
Message-Id: <20170907.131048.1841464922845786321.mbj@tail-f.com>
To: rwilton@cisco.com
Cc: andy@yumaworks.com, kwatsen@juniper.net, netconf-chairs@ietf.org, netmod@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <89b4053a-19de-a77b-8442-84c3d75e3457@cisco.com>
References: <232e44d5-28b9-a017-ec10-54a597a66c7b@cisco.com> <20170907.121547.1207208093298972388.mbj@tail-f.com> <89b4053a-19de-a77b-8442-84c3d75e3457@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=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/gPv00BBSFl5dapqJH8OH-XyrjD4>
Subject: Re: [netmod] upcoming adoptions
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: Thu, 07 Sep 2017 11:12:25 -0000

Robert Wilton <rwilton@cisco.com> wrote:
> 
> 
> On 07/09/2017 11:15, Martin Bjorklund wrote:
> > Robert Wilton <rwilton@cisco.com> wrote:
> >>
> >> On 07/09/2017 11:05, Martin Bjorklund wrote:
> >>> Robert Wilton <rwilton@cisco.com> wrote:
> >>>> On 07/09/2017 03:36, Andy Bierman wrote:
> >>>>> On Wed, Sep 6, 2017 at 10:57 AM, Kent Watsen <kwatsen@juniper.net
> >>>>> <mailto:kwatsen@juniper.net>> wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>       >> /netconf-state and /restconf-state don't seem to follow the
> >>>>>       >> general
> >>>>>       >> pattern we're correcting with the various NMDA updates.
> >>>>>       Particularly,
> >>>>>       >> these -state trees are NOT for the purpose to providing the
> >>>>>       >> opstate
> >>>>>       >> value for configured nodes.  These modules have the misfortune
> >>>>>       >> of
> >>>>>       >> having "-state" in their name, but they're otherwise fine.
> >>>>>       >
> >>>>>       >
> >>>>>       > This contradicts some details we have been told about NMDA
> >>>>>       >
> >>>>>       > 1) the transition guidelines say otherwise
> >>>>>       >
> >>>>>       > New modules and modules that are not concerned with the
> >>>>>       > operational state of configuration information SHOULD
> >>>>>       > immediately be structured to be NMDA-compatible
> >>>>>
> >>>>>       Yes, I'm suggesting we give ourselves some leeway, by taking
> >>>>>       advantage of the SHOULD keyword above and defer updating these
> >>>>>       two modules to when it makes more sense to do so.
> >>>>>
> >>>>>
> >>>>>
> >>>>> OK -- good.
> >>>>> I think another sentence needs to be added.
> >>>>>
> >>>>>
> >>>>> NMDA compatibility conversion MAY be deferred if the module
> >>>>> does not contain any configuration datastore objects.
> >>>> I agree.
> >>> +1
> >>>
> >>>
> >>>>>       > 2) RD defines operational state to include config=false nodes
> >>>>>       > such as counters, so these modules are properly named.
> >>>>>
> >>>>>       module-name == top-level node name.  Either way, my point is that
> >>>>>       the -state tree in these modules is not trying to provide the
> >>>>>       opstate value for configured nodes (i.e. applied configuration).
> >>>>>
> >>>>>
> >>>>> So a data node naming convention is needed?
> >>>>> And a module naming convention?
> >>>>>
> >>>>> We need a rule that says the suffix "-state" is reserved for NMDA
> >>>>> compatibility
> >>>>> so module names and data nodes SHOULD NOT be named with an identifier
> >>>>> that
> >>>>> ends in this suffix.
> >>>> Also agree.
> >>> -1
> >>>
> >>> There are cases where a -state suffix is natural, e.g. in
> >>> ietf-hardware we have admin-state, oper-state, usage-state etc.
> >>>
> >>> I prefer to have a recommendation that generated modules and top-level
> >>> nodes are called ...-state, but that should not be a reason for making
> >>> -state illegal in general.
> >> Sorry, it was specifically modules and top level data nodes that I
> >> think this restriction should apply to.
> > Even in this case I'd prefer to make a one-way recommendation.  Is
> > there a technical reason for not allowing a normal module or top-level
> > node be called ...-state?  IMO, *if* it is important to mark these
> > modules as being generated, we should use a formal way to convey this
> > information, not rely on a naming convention.  (i.e., use a YANG
> > extension in the module).
> My logic is slightly different:
> 
> I think that new top level containers shouldn't be called ...-state
> because either
> (i) they already contain config nodes, in which case they are
> misnamed, or
> (ii) they might be revised to contain config nodes in the future, in
> which case they would end up being misnamed.
> 
> I basically, think that the suffix "-state" doesn't generally provide
> any useful extra information.

Sure.  But there are many suffixes that don't generally provide useful
extra information.  I just think we should be careful with these kinds
of rules.  Bad names are hopefully catched during the review process.

> Lower down the tree, I guess that using "state" or  "*-state" is OK if
> it can be known that the leaf/container will *always* only be state
> and never potentially be configurable in future.  But I still think
> that it is necessary to be very careful here.
> 
> For example, If I designed a new routing protocol, then in v1 there
> might be no explicit neighbor configuration, and hence I put all of
> the neighbor information into a container call
> neighbor-state. However, if a v2 version of that protocol (or vendor
> extensions) wants to add some per neighbor configuration then it would
> hit the problem that the original container is poorly named to be
> updated to now also hold configuration.  So, generally avoiding
> "-state" in the name of containers seems to be good common sense to
> me.

I agree.  And avoid "*-config".



/martin


>   I would suggest adding something to 6087bis, but my previous
> suggested additions to 6087bis didn't appear to be well received ;-)