Re: [netmod] yang-data-ext issues

Martin Bjorklund <mbj@tail-f.com> Wed, 02 May 2018 07:30 UTC

Return-Path: <mbj@tail-f.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 34AA8126E64 for <netmod@ietfa.amsl.com>; Wed, 2 May 2018 00:30:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 AUFY4jUxzgqc for <netmod@ietfa.amsl.com>; Wed, 2 May 2018 00:30:17 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7C3CC126C2F for <netmod@ietf.org>; Wed, 2 May 2018 00:30:17 -0700 (PDT)
Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id AE26A1AE012C; Wed, 2 May 2018 09:30:16 +0200 (CEST)
Date: Wed, 02 May 2018 09:30:16 +0200
Message-Id: <20180502.093016.2140999496080783112.mbj@tail-f.com>
To: kwatsen@juniper.net
Cc: j.schoenwaelder@jacobs-university.de, netmod@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <508FA1DE-87BF-425E-BC52-2C4626ACAB12@juniper.net>
References: <C9640A34-AC7F-4890-A3FA-C1CC0D056626@juniper.net> <20180501073448.vs642cc2mpuzrvv3@elstar.local> <508FA1DE-87BF-425E-BC52-2C4626ACAB12@juniper.net>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/N8ti7h2mRgESJaRBGlVteeV8pzg>
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: Wed, 02 May 2018 07:30:19 -0000

Kent Watsen <kwatsen@juniper.net> 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

Originally pyang did not check this, but I was convinced by Andy and
the discussion on the ML that pyang was not correct.

The intention of the text in RFC 8040 was to allow for "uses" within a
yang-data statement.  It was not to allow for "choice".

>, 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.
> 
> 
> > 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.

+1


/martin


> True,
> some tools know about A, but if B is the LTS, then I'd hope to move to B
> ASAP.
> 
> > Since NMDA essentially binds all data tree definitions to datastores,
> > the yang-data construct allows us to define data structures that are
> > specifically not bound to any datastore, i.e., data structures that by
> > design can't be operated on directly with NMDA NETCONF/RESTCONF.
> 
> Yes.
> 
> 
> Kent // contributor
> 
> 
> 
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>