Re: [netmod] augment YANG 1.0 with YANG 1.1 OK?
Robert Wilton <rwilton@cisco.com> Wed, 25 October 2017 17:05 UTC
Return-Path: <rwilton@cisco.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 4F4731394F1 for <netmod@ietfa.amsl.com>; Wed, 25 Oct 2017 10:05:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 gWBMzz1vnExY for <netmod@ietfa.amsl.com>; Wed, 25 Oct 2017 10:05:40 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B638138726 for <netmod@ietf.org>; Wed, 25 Oct 2017 10:05:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20226; q=dns/txt; s=iport; t=1508951140; x=1510160740; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=Aa62ZWoQ/pics7Vzo63MdNK25ekfaspO0u+EvWejffY=; b=OPVnouIGAVJUnao88ZR0gL24+gQAH0bDMeKCZ5R7yQRQs8nrYOyUb3bW WheivP4KGZsbPhQvH4ciHMmwbKK5qhULoWErXqB07bsTAFZO0DGZHiMQC aBqRlXp/bLovOcuZUdot9258/Q8b7s/B3L/vGSTHePMZEBpsZJyisDqtJ 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0B0AQALxPBZ/xbLJq1YAxkBAQEBAQEBAQEBAQcBAQEBAYJvgVRuJ4N6ixOQEZB4hUKCEQofgz6BXgKFLRcBAgEBAQEBAQFrKIUdAQEBAwEjZAIJAhAIJwMCAhsrEQYBDAYCAQGKFAiLc51ngicmilMBAQEBAQEBAwEBAQEBAQEBAQEBHQWDKYNXgWkpgwGEbzcmgk2CYQWYdoh9lHeCFYlYJIcVjhqHZ4E5IQMzgVs0IQgdFUmCZAmCGjkcgWg/NowKAQEB
X-IronPort-AV: E=Sophos;i="5.43,432,1503360000"; d="scan'208,217";a="656578772"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Oct 2017 17:05:37 +0000
Received: from [10.63.23.64] (dhcp-ensft1-uk-vla370-10-63-23-64.cisco.com [10.63.23.64]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v9PH5bci004764; Wed, 25 Oct 2017 17:05:37 GMT
To: Andy Bierman <andy@yumaworks.com>, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Martin Bjorklund <mbj@tail-f.com>, "netmod@ietf.org" <netmod@ietf.org>
References: <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> <CABCOCHQ8nbf_H6eJxGFqwr=LHrdxyFWc3a4FfhLwR45bs-J19Q@mail.gmail.com> <20171025110851.wdoj2dbrqmxz5shd@elstar.local> <CABCOCHR22Ehryxu374a_-F6PFYayTgizReHuC0EaY4uBC7+vyg@mail.gmail.com>
From: Robert Wilton <rwilton@cisco.com>
Message-ID: <c470cfec-c1b8-a419-ca52-30c47697e21f@cisco.com>
Date: Wed, 25 Oct 2017 18:05:37 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <CABCOCHR22Ehryxu374a_-F6PFYayTgizReHuC0EaY4uBC7+vyg@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------3F01318C4E05690CBDF4CC7F"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/ZNqfXpyAunz6gaJeEEXvuq0tmZ8>
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: Wed, 25 Oct 2017 17:05:47 -0000
Hi Andy, On 25/10/2017 16:54, Andy Bierman wrote: > > > On Wed, Oct 25, 2017 at 4:08 AM, Juergen Schoenwaelder > <j.schoenwaelder@jacobs-university.de > <mailto:j.schoenwaelder@jacobs-university.de>> wrote: > > It seems we are jumping between topics. I will skip over comments > concerning the YANG library and whether it is OK or not OK that YANG > library allows different schemas in different datastores. > > \ > \ > > Actually, this is the only issue that matters. > > I decided that no special text is needed because the YANG library is > violating a MUST requirement > in RFC 7950 and needs to be changed. Are you referring to this text, or something else: 5.6.5. Implementing a Module A server implements a module if it implements the module's data nodes, RPCs, actions, notifications, and deviations. A server MUST NOT implement more than one revision of a module. If, so, then we still agree with this constraint, and this hasn't changed for NMDA. I think that YANG library should make this clear in the list of modules. But I don't think that text specifically prevents different deviations or features for different datastores ... > > There can only be one implementation of a module per server, not per > datastore. > Therefore a module MAY appear in multiple module-sets, but it MUST NOT > be different. The exact same revision, features, and deviations MUST > be present > in each instance. The NMDA draft already states that the schema for all conventional configuration datastores must be the same (meaning that all deviations and features must be the same as well): 5.1. Conventional Configuration Datastores The conventional configuration datastores are a set of configuration datastores that share exactly the same schema, allowing data to be copied between them. So, I think that the main question is about how the schema for <operational> can differ from the configuration datatstores. We want to allow different features to be supported in running vs operational, so that feature statements can be useful to turn off features that may be supported by a device, but might not be externally configurable (e.g router-id). But we could partially constrain their use. So I propose that we add the following extra sentence to the NMDA draft on section 5.3 The Operational State Datastore (<operational>). My proposed NEW text is: If a YANG feature is supported for a module in any configuration datastore then it SHOULD also be supported in <operational>. This is to allow the applied configuration and any other operational state associated with that feature to be available. The inverse constraint does not hold, a server MAY support a feature in <operational> without also supporting it in any configuration datatstore. I'm not sure that it makes sense to constrain deviations to be the same for all datastores, since these are the mechanism for reporting why a server doesn't conform to the standard ... Thanks, Rob > > Andy > > > > On Tue, Oct 24, 2017 at 11:21:54AM -0700, Andy Bierman wrote: > > On Tue, Oct 24, 2017 at 10:21 AM, Juergen Schoenwaelder < > > j.schoenwaelder@jacobs-university.de > <mailto: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. > > So you are fine if for RPCs description statements can define which > datastores are affected by an RPC? I probably did not get that you > make a distinction between actions and RPCs here. > > /js > > -- > 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/ > <http://www.jacobs-university.de/>> > >
- [netmod] augment YANG 1.0 with YANG 1.1 OK? Andy Bierman
- Re: [netmod] augment YANG 1.0 with YANG 1.1 OK? Martin Bjorklund
- Re: [netmod] augment YANG 1.0 with YANG 1.1 OK? Andy Bierman
- Re: [netmod] augment YANG 1.0 with YANG 1.1 OK? Juergen Schoenwaelder
- Re: [netmod] augment YANG 1.0 with YANG 1.1 OK? Andy Bierman
- Re: [netmod] augment YANG 1.0 with YANG 1.1 OK? Andy Bierman
- Re: [netmod] augment YANG 1.0 with YANG 1.1 OK? Juergen Schoenwaelder
- Re: [netmod] augment YANG 1.0 with YANG 1.1 OK? Juergen Schoenwaelder
- Re: [netmod] augment YANG 1.0 with YANG 1.1 OK? Andy Bierman
- Re: [netmod] augment YANG 1.0 with YANG 1.1 OK? Robert Wilton
- Re: [netmod] augment YANG 1.0 with YANG 1.1 OK? Andy Bierman
- Re: [netmod] augment YANG 1.0 with YANG 1.1 OK? Juergen Schoenwaelder
- Re: [netmod] augment YANG 1.0 with YANG 1.1 OK? Andy Bierman
- Re: [netmod] augment YANG 1.0 with YANG 1.1 OK? Juergen Schoenwaelder
- Re: [netmod] augment YANG 1.0 with YANG 1.1 OK? Andy Bierman
- Re: [netmod] augment YANG 1.0 with YANG 1.1 OK? Robert Wilton
- Re: [netmod] augment YANG 1.0 with YANG 1.1 OK? Martin Bjorklund
- Re: [netmod] augment YANG 1.0 with YANG 1.1 OK? Andy Bierman
- Re: [netmod] augment YANG 1.0 with YANG 1.1 OK? Andy Bierman
- Re: [netmod] augment YANG 1.0 with YANG 1.1 OK? Martin Bjorklund
- Re: [netmod] augment YANG 1.0 with YANG 1.1 OK? Andy Bierman
- Re: [netmod] augment YANG 1.0 with YANG 1.1 OK? Andy Bierman
- Re: [netmod] augment YANG 1.0 with YANG 1.1 OK? Martin Bjorklund
- [netmod] Action and RPC statements [was Re: augme… Robert Wilton
- Re: [netmod] augment YANG 1.0 with YANG 1.1 OK? Robert Wilton
- Re: [netmod] Action and RPC statements [was Re: a… Randy Presuhn
- Re: [netmod] Action and RPC statements [was Re: a… Andy Bierman
- Re: [netmod] Action and RPC statements [was Re: a… Randy Presuhn
- Re: [netmod] Action and RPC statements Martin Bjorklund
- Re: [netmod] Action and RPC statements Robert Wilton
- Re: [netmod] Action and RPC statements Juergen Schoenwaelder
- Re: [netmod] Action and RPC statements Kent Watsen
- Re: [netmod] Action and RPC statements Robert Wilton
- Re: [netmod] Action and RPC statements Juergen Schoenwaelder
- Re: [netmod] Action and RPC statements Robert Wilton
- Re: [netmod] Action and RPC statements Andy Bierman
- Re: [netmod] Action and RPC statements Randy Presuhn
- Re: [netmod] Action and RPC statements Andy Bierman
- Re: [netmod] Action and RPC statements Alexander Clemm
- Re: [netmod] Action and RPC statements Phil Shafer
- Re: [netmod] Action and RPC statements Robert Wilton
- Re: [netmod] Action and RPC statements Robert Wilton
- Re: [netmod] Action and RPC statements Juergen Schoenwaelder
- Re: [netmod] Action and RPC statements Andy Bierman
- Re: [netmod] Action and RPC statements Alexander Clemm
- Re: [netmod] Action and RPC statements Alexander Clemm
- Re: [netmod] Action and RPC statements Juergen Schoenwaelder
- Re: [netmod] Action and RPC statements Phil Shafer
- Re: [netmod] Action and RPC statements Andy Bierman
- Re: [netmod] Action and RPC statements Martin Bjorklund
- Re: [netmod] Action and RPC statements Lou Berger
- Re: [netmod] Action and RPC statements Juergen Schoenwaelder
- Re: [netmod] Action and RPC statements Martin Bjorklund
- Re: [netmod] Action and RPC statements Lou Berger
- Re: [netmod] Action and RPC statements Robert Wilton
- Re: [netmod] Action and RPC statements Lou Berger
- Re: [netmod] Action and RPC statements Robert Wilton
- Re: [netmod] Action and RPC statements Lou Berger
- Re: [netmod] Action and RPC statements Juergen Schoenwaelder
- [netmod] Reset tags RPC [was Re: Action and RPC s… Robert Wilton
- Re: [netmod] Action and RPC statements Lou Berger
- Re: [netmod] Action and RPC statements Andy Bierman
- Re: [netmod] Action and RPC statements Juergen Schoenwaelder
- Re: [netmod] Action and RPC statements Robert Wilton
- Re: [netmod] Action and RPC statements Lou Berger
- Re: [netmod] Action and RPC statements Robert Wilton
- Re: [netmod] Action and RPC statements Lou Berger
- Re: [netmod] Action and RPC statements t.petch