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

Andy Bierman <andy@yumaworks.com> Tue, 24 October 2017 18:22 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 7DF7A1386F3 for <netmod@ietfa.amsl.com>; Tue, 24 Oct 2017 11:22: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=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 EBfJg38VdoWH for <netmod@ietfa.amsl.com>; Tue, 24 Oct 2017 11:21:58 -0700 (PDT)
Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::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 72D57137ED6 for <netmod@ietf.org>; Tue, 24 Oct 2017 11:21:57 -0700 (PDT)
Received: by mail-lf0-x22a.google.com with SMTP id a132so25044554lfa.7 for <netmod@ietf.org>; Tue, 24 Oct 2017 11:21:57 -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; bh=mRhU013cjtosCkE144kdPsPpKGIM22Is2fl8FKAFJAk=; b=N0MKNDBdkfjvCf9q9Vn0KG6VNOxsSxWcqmjSmqcoBBY90ovoQYEaz+HIC2Ye2QgUcc kzpDG+S2nNZ5RLN6mF3xK8XvW/QRzp0uJIY3sWJl1rUiwTwSKL4vXkE3nPHPMsOt3oqk dS+YlBN9+XYG/XPEdmg7DhteiRJybiTAnIXaB8rtNUQdBC/YMIGrLaZOG4CBO+0dSHhk PgbdmItFesL0k89H35iqxmlhAz9VSOw/hzLqtYCVbDYiDu7V0C6OY9LLHeBiXPodoaH1 tcxGp6mujTfUCVqOR9eeAAeFLMQw4iZTqHWdxKP54PMughTiS+7khxFQZCMlpWcU2LMl h0PA==
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; bh=mRhU013cjtosCkE144kdPsPpKGIM22Is2fl8FKAFJAk=; b=G+L+Ydtwrb6VUlI+1Q4/yTs9vFix2BohBj2bARVyAWHwPB6s7d0n6D6yE/QmsJ73r2 afvoaGm761iIwR95pUwclyoIIpsPRNrt83owuB7xVHfRSHPZ7Fvndi0RPMDzLVsEsWj0 vJknnE6E3YfoIs8JzVXaq1/reXbQfJHJBec2yTweGtv9N2B/zQL6KiQ3wuQ3qO+HpcDD DMNHFLjx6sFul3IOJAs4XaG1jK6LOZL3YjKzSwSnkZ/d372SinTQMIS5qDecQTO/g1CR r5znLwgNlunLHGZW9vADpzKA+JrVeRLgCwhq+q4Qn39QoXuZrA6/sVoUcAzMRj+TPRgN nFSA==
X-Gm-Message-State: AMCzsaUIVQSCqei/JxX00nfw3BHhz6lGKZJIxS2FVIyAGXJXrY3HFsqg UXHTwg6m6SQeEDvDCVE+HFv1eVvJ+uSmrr4ct5CJJQ==
X-Google-Smtp-Source: ABhQp+RbJpa2U4SuSCUDg/4sZpAbfTdwo7uMPQI8DvKyKhsluN0OqWnduFJc529a1U0g6O2XD5KYTpb5pQv9X3UZmG0=
X-Received: by 10.25.23.165 with SMTP id 37mr5927110lfx.202.1508869315745; Tue, 24 Oct 2017 11:21:55 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.150.198 with HTTP; Tue, 24 Oct 2017 11:21:54 -0700 (PDT)
In-Reply-To: <20171024172125.l6l3yhocakfkcoh2@elstar.local>
References: <CABCOCHQhPHxen2YD-ZPHqpGZN5YrE_7RVe7_3qUkdazL+PTSmg@mail.gmail.com> <20171015.095206.5556973134711466.mbj@tail-f.com> <CABCOCHR_q8DTF2agDi_VH9pSL8DWV1ttuX=ZZDO9OmNXhAeEsg@mail.gmail.com> <20171018143651.kdsf77r65ptlu4mq@elstar.local> <CABCOCHRVdkjV5PgQ+UtwJMKPLeFRKs_=ogAfTaCGZsWEdgP5uw@mail.gmail.com> <20171018213601.hdkt2qtqsno6vr4u@elstar.local> <CABCOCHS72TVrurJ1mTRi4eGQR3=G1=bx3wk_NK07NOB8OaZfKg@mail.gmail.com> <bacb34ef-d3d9-babd-467e-188146c1084d@cisco.com> <CABCOCHR6tSg9RRW7gZ50qp6F5frWGm-P1qK_0xEEQdiNursB7A@mail.gmail.com> <20171024172125.l6l3yhocakfkcoh2@elstar.local>
From: Andy Bierman <andy@yumaworks.com>
Date: Tue, 24 Oct 2017 11:21:54 -0700
Message-ID: <CABCOCHQ8nbf_H6eJxGFqwr=LHrdxyFWc3a4FfhLwR45bs-J19Q@mail.gmail.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Andy Bierman <andy@yumaworks.com>, Robert Wilton <rwilton@cisco.com>, Martin Bjorklund <mbj@tail-f.com>, "netmod@ietf.org" <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="001a11401a0493f1b6055c4f03f7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/1GL4AWwEdpKNdMFJzztr_h5mWeY>
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: Tue, 24 Oct 2017 18:22:00 -0000

On Tue, Oct 24, 2017 at 10:21 AM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Tue, Oct 24, 2017 at 10:13:35AM -0700, Andy Bierman wrote:
> >
> > IMO the more complex NMDA is to implement, the less likely it will
> > be implemented.  If you want the tools to figure out the correct
> > datastore(s) from description-stmts instead of something
> > deterministic and machine-usable, NMDA is less likely to be
> > implemented.
>
> There is nothing machine readable today that tells you which argument
> of get-config identifies the datastore that is being accessed by
> get-config. Our reasoning is that for most actions that default is
> going to do the right thing. If there is a need to have further
> language support to handle the cases where operations may relate to
> datastores different than operational, then this should be taken up by
> a future version of YANG.
>
>
There is only 1 schema tree now in pre-NMDA so it is easy to parse
instance data against the one and only set of modules.



> > Given that the same objects can be defined differently in each
> > datastore in NMDA, it is especially useful to know which set of YANG
> > modules applies, before parsing instance data against those modules.
>
> I am not sure I parse this correctly.
>

The new YANG library requires the implementation to know the datastore
to pick the correct set of modules for the datastore used in the operation.
Module sets are allowed to overlap, so the same module can be different
in <running> vs. <operational>.

Developers unaware of the new NMDA complexities should read the drafts
again.



>
> > (2) Define <action2>:
> > >
> > > I'm not convinced that this is really required/helpful, given that most
> > > actions are likely to only apply to operational.  If it turns out that
> this
> > > is particularly useful then I would propose that this is deferred
> until a
> > > future revision of NETCONF, particularly because we are trying to keep
> the
> > > NETCONF NMDA and RESTCONF NMDA drafts as small as possible.
> > >
> > > Is this OK?
> > >
> >
> > The NMDA theme has been to declare things that are possible in pre-NMDA
> > but not supported in post-NMDA to be not useful, so this can be left to
> > vendors I guess.
>
> Not sure I understand this either.
>
> If you have a concrete change proposal, perhaps the discussion becomes
> more concrete and productive.
>


I already said to declare that <action> is invoked in <operational>. Period.
No description-stmt exceptions.

If another datastore is needed, use rpc-stmt instead of action-stmt.




>
> /js
>
>

Andy


> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
>