Re: [netmod] yang-data-ext issues

Martin Bjorklund <mbj@tail-f.com> Wed, 02 May 2018 07:27 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 C5228126CD6 for <netmod@ietfa.amsl.com>; Wed, 2 May 2018 00:27:53 -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 G6W9B1SgVsHa for <netmod@ietfa.amsl.com>; Wed, 2 May 2018 00:27:52 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4CBD5126C2F for <netmod@ietf.org>; Wed, 2 May 2018 00:27:52 -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 75C321AE012C; Wed, 2 May 2018 09:27:51 +0200 (CEST)
Date: Wed, 02 May 2018 09:27:51 +0200 (CEST)
Message-Id: <20180502.092751.513408171275580216.mbj@tail-f.com>
To: kwatsen@juniper.net
Cc: lhotka@nic.cz, andy@yumaworks.com, netmod@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <C9640A34-AC7F-4890-A3FA-C1CC0D056626@juniper.net>
References: <CABCOCHSKfDCOpQJ4bX2ueHSj-e90ZyHVC1z3h9WMfPkn2OMMvw@mail.gmail.com> <87d0yglra0.fsf@nic.cz> <C9640A34-AC7F-4890-A3FA-C1CC0D056626@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/k_AzhOxkiTjsCi9biR2H0ZjLKJM>
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:27:54 -0000

Kent Watsen <kwatsen@juniper.net>; wrote:
> 
> Lada writes:
> > Andy writes:
> >>IMO, the yang-data defined in RFC 8040 has a clear purpose, and it
> >>is sufficient for that purpose, which is a YANG representation of
> >>an instance document (such as a protocol message or file).
> >
> > The same is basically true even without the extension. For example, I
> > fail to see any benefit from using yang-data in a module like
> > ietf-zerotouch-information.
> 
> I don't understand this, how else would you propose to define the
> JSON-or-XML encoded payload of the CMS structure?
> 
> 
> >> I am in favor if keeping the yang-data in RFC 8040 and not
> >> creating a new version of it that is unconstrained.
> >> There does not seem to be consensus on how to do this,
> >> or even consensus that it is a good idea.
> >
> > If the extension is deemed necessary, I would also prefer this 
> > approach to making the extension a Proposed Standard.
> 
> 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.

and 3) it is not possible to augement 8040's yang-data.

> Sure, maybe we have convinced ourselves that yang-data is not needed
> to model error-info

I don't think there have been any other proposal for how to model
error-info that have any sort of concensus behind it.

> , but that doesn't negate the other use case.
> 
> We need a way to indicate that some data-model represents a stand-alone
> data structure.  It is not configuration, operational state, an RPC, or
> a notification.  It can only appear as a descendent of the 'module'
> statement.  All 'action', 'notification', 'config', and 'if-feature'
> descendent statements are ignored.  For the purpose of 'must' and '
> when' statements, the yang-data structure is its own context root.  It
> has a namespace and a unique local name (unique only to other yang-data
> defined within the same module; it's okay if an RPC, notification, or
> top-level data node has the same name).  Anything else?



/martin