Re: [netmod] augment YANG 1.0 with YANG 1.1 OK?

Andy Bierman <andy@yumaworks.com> Thu, 26 October 2017 01:46 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 4BBFE1395F3 for <netmod@ietfa.amsl.com>; Wed, 25 Oct 2017 18:46:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 tA9uvm1j2jWB for <netmod@ietfa.amsl.com>; Wed, 25 Oct 2017 18:46:48 -0700 (PDT)
Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (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 0B18113F4FB for <netmod@ietf.org>; Wed, 25 Oct 2017 18:46:48 -0700 (PDT)
Received: by mail-lf0-x231.google.com with SMTP id 75so1994192lfx.1 for <netmod@ietf.org>; Wed, 25 Oct 2017 18:46:47 -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=1pNJ5Pdfv5P8xwjmydXN3FX3p3guKNVyrGo2NSHnHx8=; b=n/5LdsIz++Wk4et2TMw0mtiMgDpBsAk6mjaPJYa2ycJgMVES21olLEYpeG15nh5sTl CNYRBv8Q8W6RiTtvIaU65Rbdlo+AC8bVPLNqBHWuQjm8iFYjz25Ik8ewqN9yTsZprATe SCr4UynKVPEr8kqbncMmTlL0Thh2hb09zfFJPDJBqjc9qroucql44H79YsL6IzHH4OMt yLzzV0/FzTwRIRn23TEtxiWbCCbh6uQDkobMeczqrZrnFnK1jzMoQa4wleLUgQbYTFB5 O7isOWA5IEyc5HsvNyBUY4LB3+tG+pSpZuD25d2KuGQyb+tpgKuDFcRf3BZP6YhiFMmt OHHA==
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=1pNJ5Pdfv5P8xwjmydXN3FX3p3guKNVyrGo2NSHnHx8=; b=d+SpikbUYWRrA0KaSR0EuS+OnIE0NG4dUkFNHaLleh+Dc3vZ65PquMp8qIQ2EN3fgn +iasCDw4LNAsgbpgib/9yNVIB6v5dh/OURskJ0PtPNqIOM8V+EfhffFdxVwSF5+JmO4m smt+VDRiT+SYe2IQaz8/f6jO+0yL8nZnHnLdpDjfnSJJgL0mYRFR0wctcVPosQIGbOli ypfSes0owXSGq42iZbP+uMiHMkBrpJpAQqLNFFJJtDY8tk0U/yV3tKssOKNSuCVzaaZ6 GIih7qPLGGyPXU1C3jzcwXCq37n/LvcpeLH6LZsuBdX0LOTt8NjrluYIhExEWPRY4fmQ F8sg==
X-Gm-Message-State: AMCzsaW8LemugQWWfttf+n+OjlvgArxNCCe8Z8mdnthFllqEI5uql6dn eilhilfo5Ii8W+WzVIjTm8Mu+WFnHkmdkCPPgYidnA==
X-Google-Smtp-Source: ABhQp+Q8/K2ys+V95TFEmH8KW9Qz47f/VVOdw6FbX5gTKB3n0E0FYDcYyxcupsuaGVhcVDuKLrHsn/ZpsoIrVWDvChQ=
X-Received: by 10.46.117.24 with SMTP id q24mr8616253ljc.14.1508982406282; Wed, 25 Oct 2017 18:46:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.150.198 with HTTP; Wed, 25 Oct 2017 18:46:45 -0700 (PDT)
In-Reply-To: <20171025.214929.480782767501855061.mbj@tail-f.com>
References: <CABCOCHR22Ehryxu374a_-F6PFYayTgizReHuC0EaY4uBC7+vyg@mail.gmail.com> <c470cfec-c1b8-a419-ca52-30c47697e21f@cisco.com> <CABCOCHTxrxxa0YGtXs8M3x8NGnb0yGJeGPk=6j0s=zsXqtTHNg@mail.gmail.com> <20171025.214929.480782767501855061.mbj@tail-f.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Wed, 25 Oct 2017 18:46:45 -0700
Message-ID: <CABCOCHTuGGBY40UYg=Xk8Hx5tPHnu=t+pdGvpJ17cwN_0wSu4A@mail.gmail.com>
To: Martin Bjorklund <mbj@tail-f.com>
Cc: Robert Wilton <rwilton@cisco.com>, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, "netmod@ietf.org" <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="089e082f63e04c92aa055c6958be"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/KCjB9a-3JQNzut43Wbq-6Kp_DcQ>
Subject: Re: [netmod] augment YANG 1.0 with YANG 1.1 OK?
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, 26 Oct 2017 01:46:50 -0000

On Wed, Oct 25, 2017 at 12:49 PM, Martin Bjorklund <mbj@tail-f.com> wrote:

> Andy Bierman <andy@yumaworks.com> wrote:
> > I think NMDA is creating much more complexity and disruption than is
> > required.
> > The original issue was the OpenConfig-style config/state trees.
> > The WG agreed that an RPC-based solution was needed so that the
> > YANG modules would not need to change (far too disruptive!).
> >
> > Then the IETF proceeds to redo all the YANG modules anyway.
> > Now the server is allowed to implement the same module differently in
> each
> > datastore.
> > Now comparing the configured and operational value is even harder than
> > before.
> >
> > None of this added complexity was in the OpenConfig proposal.
> > It was not even possible to have different features and deviations for
> the
> > same object in that proposal.
>
> Actually, this is not correct.  In both OC and the old IETF split tree
> solutions, the configuration and operational state were modelled with
> duplicate nodes, and you could certainly deviate these nodes
> differently.
>
> This said, I share your concern about complexity.  I also agree that
> the only model that makes the client simple is that if all objects in
> the config are also available with the same types in operational
> state.  Otherwise comparison won't work (or be complicated).
>
> But at the same time, the converse is not true.  I.e., if an object is
> present in operational, it doesn't have to be configurable.
>
> So what I think we want is that the schema for the conventional
> datastore is a subset of the schema for operational.
>
> This would allow an implementation that cannot support configuration
> of let's say the MTU, to deviate the mtu with "not-supported" in the
> conventional datastore, but it will still be available for inspection
> in operational.
>
> Does this make sense?
>

OK -- deviations for not-supported make sense per datastore
to resolve the missing-object ambiguity problem.
It is not realistic to expect every object in a module to be able
to report its operational state in the same release.
It is better to report not-supported than return nothing or return the
configured value as a guess.

If the admin-state and oper-state objects are different, 2 objects should
be used instead of per-datastore deviations of the syntax of 1 object.



>
> /martin
>


Andy