Re: [netmod] yang-data-ext issues

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Tue, 01 May 2018 20:43 UTC

Return-Path: <j.schoenwaelder@jacobs-university.de>
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 98FE9126D0C for <netmod@ietfa.amsl.com>; Tue, 1 May 2018 13:43:34 -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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 eOuaUDEsWlck for <netmod@ietfa.amsl.com>; Tue, 1 May 2018 13:43:31 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31B2312420B for <netmod@ietf.org>; Tue, 1 May 2018 13:43:30 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id AF68CD0E; Tue, 1 May 2018 22:43:28 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id RDuwxECmcOhP; Tue, 1 May 2018 22:43:28 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Tue, 1 May 2018 22:43:28 +0200 (CEST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5EA4020036; Tue, 1 May 2018 22:43:28 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id tAAZ9ZB86QYU; Tue, 1 May 2018 22:43:27 +0200 (CEST)
Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D974C20031; Tue, 1 May 2018 22:43:27 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id CD05242C9335; Tue, 1 May 2018 22:43:27 +0200 (CEST)
Date: Tue, 01 May 2018 22:43:27 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Kent Watsen <kwatsen@juniper.net>
Cc: NetMod WG <netmod@ietf.org>
Message-ID: <20180501204327.yfwgax2cm5kspaet@elstar.local>
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Mail-Followup-To: Kent Watsen <kwatsen@juniper.net>, NetMod WG <netmod@ietf.org>
References: <45f5a97d205a9251b382687f54865c62250787cb.camel@nic.cz> <99aac5c0-aa2f-1a35-8a5c-ad97635e5a40@cisco.com> <b9211ebacd24ffdd558ecf4da5bfa1ad71cfdabb.camel@nic.cz> <20180427144708.6ekknrajexvz5yvf@elstar.local> <4305e62a9d301da22f89a0dd9a34c9c4882735af.camel@nic.cz> <CABCOCHSKfDCOpQJ4bX2ueHSj-e90ZyHVC1z3h9WMfPkn2OMMvw@mail.gmail.com> <87d0yglra0.fsf@nic.cz> <C9640A34-AC7F-4890-A3FA-C1CC0D056626@juniper.net> <20180501073448.vs642cc2mpuzrvv3@elstar.local> <508FA1DE-87BF-425E-BC52-2C4626ACAB12@juniper.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <508FA1DE-87BF-425E-BC52-2C4626ACAB12@juniper.net>
User-Agent: NeoMutt/20171215
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/6INNPFfYsqLzE6fFm21Lp7Q-kdY>
Subject: Re: [netmod] yang-data-ext issues
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, 01 May 2018 20:43:35 -0000

On Tue, May 01, 2018 at 08:33:58PM +0000, Kent Watsen wrote:
> 
> Juergen writes:
> > Kent writes:
> >> I don't understand talk about abandoning this draft.  There is no question
> >> that it is needed (e.g., anima vouch, zerotouch, tail-f's "structure"),
> >> and RFC 8040 is unsatisfactory because 1) it doesn't allow a top-level
> >> 'choice' between two containers and 2) it requires drafts to reference 
> >> RFC 8040, even though the drafts may have nothing to do with RESTCONF.
> >>
> >
> > Re 1: RFC 8040 says: "It MUST contain data definition statements that
> > result in exactly one container data node definition." So a choice may
> > actually work as long as the result is exactly one container data
> > node. OK, the wording in the RFC 8040 statement is not clear since
> > 'result' and 'definition' do not line up (does 'result' mean the
> > toplevel data node instances that are possible? In this case,
> > 'definition' would be misleading).
> 
> I agree, but Martin did not and he even modified `pyang` to throw an 
> error on the zerotouch draft, thus forcing the current situation.  If
> a new understanding regarding rc:yang-data can be reached, the zerotouch
> draft can go back to using it.

Well, the statement in RFC 8040 is not clear (to me).
 
> > Re 2: It does not really matter whether you import the extension from
> > RFC 8040 or some other module. Why is depending on A better than
> > depending on B? The definition in RFC 8040 is already know by tools.
> >
> > I view the yang-data definition of RFC 8040 as a temporary solution, a
> > proper solution should in my view be part of YANG 1.x.
> 
> What is the "proper solution", and why does it need to wait for YANG 1.x?
> In the discussion regarding moving faster, it's been suggested that YANG 
> 1.x could be a cherry-picking of some number of extension statements 
> produced in other I-Ds.  I was hoping that this was the case here.  True,
> some tools know about A, but if B is the LTS, then I'd hope to move to B
> ASAP.

You will end up with yang-data defined in ietf-restconf, yang-data
defined in ietf-yang-data-ext, and something long-term stable in YANG
1.x. Do people really believe that creating three variants will be
simpler and more effective? The experiment is yang-data in
ietf-restconf - why do we need another experiment?

/js

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