Re: [netmod] upcoming adoptions

Andy Bierman <andy@yumaworks.com> Thu, 07 September 2017 17:52 UTC

Return-Path: <andy@yumaworks.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 14C88132F1B for <netmod@ietfa.amsl.com>; Thu, 7 Sep 2017 10:52:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
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 wT3bfbfhVVLp for <netmod@ietfa.amsl.com>; Thu, 7 Sep 2017 10:51:56 -0700 (PDT)
Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CC84132930 for <netmod@ietf.org>; Thu, 7 Sep 2017 10:51:56 -0700 (PDT)
Received: by mail-it0-x22a.google.com with SMTP id g142so377085ita.0 for <netmod@ietf.org>; Thu, 07 Sep 2017 10:51:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=V6lVKl2xb3kl1HFxVmFpbEiI3E0YtAasNzVllQOpOUs=; b=PGmDSG5aZrl/g0AjR+zvxoYj/O7hvcwGTdauzQPyw1NIPPWCJbFoLOX3XwVIqeJ8d2 RKfGWhZEfkWspcZftZF/PrglLcGEv2zPg+A5GL2+fo94mrh9W9VPopor0xM2+UxB8egV De9M+bz8++7EoUyk+BVzNaktvd7ryw/9v9mu82RmLattDHuFcI8ZmQQNmZytd9kzy4E0 x3h+nCvTblYOC7q/xY44rmLuuw/odNSpFKxlU+loxOsyOegIAekvCgwEUg5PrAzr3cW7 05Zf1H+fzz8sC0vdYiWDzl0ahXM23ZPjN37Q+HHBRWN48FHdD2Jk/xs9UfLe81avNr7r NL2Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=V6lVKl2xb3kl1HFxVmFpbEiI3E0YtAasNzVllQOpOUs=; b=lqRX20EoAgt5Xtz769822Zfm6WOKW6Y+egfW94FzuMtn9NG1KsBhxRXip6WMOWVmlw aUXtHkSqCIEU1QBfAOjvAlFMAmTbgboGcetzyUqFKBOk2fm9c/C1xD/0wswXR5SWEry1 1anUxDbuAxqYmOFPmFlKBNnUf+UfM84RcJCarTMrhE4MyoJJJMHK46ozCm+8U0acLsxm nXgsejDuOmxesME082Z3+ggpVGneF1p3s3hkWGDzNJFESlk3HcFrYL2sBasPPTURNykh wlLXP9Hgu40POnt6Q1DfmuyyQG6FNYiptRjrebc1GqAKDqXxhBZfmDJoCd7ADBbEM3JG TebQ==
X-Gm-Message-State: AHPjjUhUMXDRjNXMTCDZwdKEV4tFGS0WwGoyb/YFhIC5MNvpgetBvYrm HYKYGfut2Z4n6A2sduvl+s/f1zWJPAjd
X-Google-Smtp-Source: ADKCNb65WMYaCOz5+ne9cYuY99EwAP6KNkU/Wael55m9aFY92QIW8pnrGdB/CaoNzcTZDR/ZjobV9KUyJYL/iraF8D8=
X-Received: by 10.36.40.138 with SMTP id h132mr161264ith.26.1504806715808; Thu, 07 Sep 2017 10:51:55 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.36.6.206 with HTTP; Thu, 7 Sep 2017 10:51:54 -0700 (PDT)
In-Reply-To: <20170907.131048.1841464922845786321.mbj@tail-f.com>
References: <232e44d5-28b9-a017-ec10-54a597a66c7b@cisco.com> <20170907.121547.1207208093298972388.mbj@tail-f.com> <89b4053a-19de-a77b-8442-84c3d75e3457@cisco.com> <20170907.131048.1841464922845786321.mbj@tail-f.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Thu, 7 Sep 2017 10:51:54 -0700
Message-ID: <CABCOCHR91bouy8jVN9Dt6nEiVo67jmGFFHO-pv8FA4QDM-6dtw@mail.gmail.com>
To: Martin Bjorklund <mbj@tail-f.com>
Cc: Robert Wilton <rwilton@cisco.com>, Kent Watsen <kwatsen@juniper.net>, NETCONF Working Group <netconf-chairs@ietf.org>, "netmod@ietf.org" <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="001a113f62ecc090ff05589d1dd2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/SqQkf-ToMzbqeY_wSEZceER6ysg>
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 17:52:00 -0000

Hi,

I suggested the naming guideline because the NMDA design team decided to
add semantics to certain naming patterns, so authors have to be warned.

But this is a really bad idea (and slippery slope).
First we tell everybody "these are just identifiers, pick any string you
want",
then we want to change it 8 years later to "except these strings which mean
special things".

The proper deterministic way to identify that the module or subtree is
special
is to tag it with a YANG extension. Adding semantics to the user-selected
identifier space
8 years after dozens of exceptions already exist is not a great plan.

If anybody ever actually implements this NMDA stuff, I think they will find
it useful to identify modules written for specific datastore usage, or
if the module is an NMDA transition module, an I2RS-specific module, etc.
The extension you suggested in another email would work.


Andy


On Thu, Sep 7, 2017 at 4:10 AM, Martin Bjorklund <mbj@tail-f.com> wrote:

> 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 ;-)
>
>