Re: [netmod] upcoming adoptions

Andy Bierman <andy@yumaworks.com> Wed, 06 September 2017 15:24 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 DC81C132EA2 for <netmod@ietfa.amsl.com>; Wed, 6 Sep 2017 08:24:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 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] autolearn=ham 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 reQw2sOdXN5j for <netmod@ietfa.amsl.com>; Wed, 6 Sep 2017 08:24:49 -0700 (PDT)
Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (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 820CA132E28 for <netmod@ietf.org>; Wed, 6 Sep 2017 08:24:49 -0700 (PDT)
Received: by mail-io0-x22d.google.com with SMTP id y123so24479216iod.0 for <netmod@ietf.org>; Wed, 06 Sep 2017 08:24:49 -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=RqSBWrtP44OjdwOGvap2XXQpspInXnNZwTlyzGz2XgM=; b=Pk0yRYUnLxn8TevElfWIHPosIQ3qSLMSmqO+NV+zA283MT03BBePUSE5zUlws51dE4 Uf6lx8c92tHj9Mvc5XRccGvqSOjAx8QwKLA+xidh1jBpbMlta5uFOL8bUllGiNwjrlV0 OV8Wb76z1BIV4I3Bo897kBM78effLXI1u18+jwK91BNtPudI+UmztUMLR3B6tL08Jnmy YWNy77ccizAC/hZ4OzFzzOe0VlQCNYV8u1N87AADqD+if+Dux5wj189KpYXNHQHGH1Fv WeZpODCT97ZrIdsap0wfZEe7rpO8c4lJwR7umNXy445VLW5gWT4WUk67EsnPN1K4Vz3r UAOQ==
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=RqSBWrtP44OjdwOGvap2XXQpspInXnNZwTlyzGz2XgM=; b=iYZN+v7UTMRQKpPGkRi6DieVlBUaoQAmTkXKuFa/2YiCcwocfjeEnZQIGpmF9yPoTL 5i1XTBfoXmK6hzcDG8/WCo0l54PwK9xgVrlk0reH7ZpJJ3CvHiI0H8494B36ZLCmm6VG GnOFkO4jOV6UICRdisLcuBfW7czMeWs4GYbdmwgi9LS8Tk5p/ucXjwzmh6WFcnhVMT6Y 2MwovdtNDPWG+AYB0FaIuAQ9wIceWJPQnp5dM1x42gNbybivfyEWR+layVj99Ig56MU7 C1+tjHrslQiIFz6lVHXIjoR/G4XsmkZT5Fn4gB2qJQ9+fjGGA8zaFRpQPemEEKX7jed5 Rbsw==
X-Gm-Message-State: AHPjjUhb2t6HccXpMe4xSLsjP1VEN4VKtY2/XZBi4MNBZW2q3LZ5xGxj KCxF59SpB9feoZ544NSLgYZW4Ex0QJAM
X-Google-Smtp-Source: AOwi7QB5Va2dWkn2VbPCNQ9cCcHQN7MAHXjvW7Mvv8JO+SID7cIO7pKsvFJC0GRBVn8i/zqfolgnBmwS4I9eVc2VgvQ=
X-Received: by 10.107.51.81 with SMTP id z78mr3302492ioz.146.1504711488748; Wed, 06 Sep 2017 08:24:48 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.36.6.206 with HTTP; Wed, 6 Sep 2017 08:24:48 -0700 (PDT)
In-Reply-To: <38E666E2-EECE-4554-9A55-B98D829EB4CA@juniper.net>
References: <3620aafe-bc72-cc54-9dbd-b687a0178df2@cisco.com> <20170905.095949.1829098658779783521.mbj@tail-f.com> <CABCOCHRmNT=v9ivztzPh3OGmo-AeheHDct2XY9zbk_-FjEytmg@mail.gmail.com> <20170906.084124.2282926097915349446.mbj@tail-f.com> <38E666E2-EECE-4554-9A55-B98D829EB4CA@juniper.net>
From: Andy Bierman <andy@yumaworks.com>
Date: Wed, 6 Sep 2017 08:24:48 -0700
Message-ID: <CABCOCHQ-bBe307BgXJtxKOW3avmdkck4qrmj-oHTdmaRD5pU_w@mail.gmail.com>
To: Kent Watsen <kwatsen@juniper.net>
Cc: Martin Bjorklund <mbj@tail-f.com>, "bclaise@cisco.com" <bclaise@cisco.com>, "netconf-chairs@ietf.org" <netconf-chairs@ietf.org>, "netmod@ietf.org" <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="001a11440c9cc6ff76055886f131"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/ENSTJOmO0q3oH9qWozgeb2vHiho>
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: Wed, 06 Sep 2017 15:24:51 -0000

On Wed, Sep 6, 2017 at 6:11 AM, Kent Watsen <kwatsen@juniper.net> wrote:

> >> I guess the NMDA transition plan to move the child nodes to a
> config=true
> >> node
> >> name /restconf that has only config=false nodes in it.  This seems quite
> >> disruptive
> >> and not a productive use of engineering resources, or support and
> customer
> >> re-training.
> >
> > I agree with you.  We've said that it is ok to have pure config false
> > trees, if it makes sense for what we're trying to model.
> >
> > The only "issue" with the tree above is that its top-level node's name
> > contains the word "state".
>
> /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


2) RD defines operational state to include config=false nodes such as
counters,
so these modules are properly named.



K.  // contributor
>
>
>
>
Andy