Re: [netmod] yang-data-ext issues

Ladislav Lhotka <lhotka@nic.cz> Wed, 02 May 2018 10:35 UTC

Return-Path: <lhotka@nic.cz>
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 4BD4312D875 for <netmod@ietfa.amsl.com>; Wed, 2 May 2018 03:35:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7
X-Spam-Level:
X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 iwEFGbPM6VD1 for <netmod@ietfa.amsl.com>; Wed, 2 May 2018 03:35:08 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26110124BFA for <netmod@ietf.org>; Wed, 2 May 2018 03:35:07 -0700 (PDT)
Received: from birdie (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id E71E060440 for <netmod@ietf.org>; Wed, 2 May 2018 12:35:05 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1525257305; bh=DgoWnjfU3AkHK1ESxwdG58iep+80A5fIvkcwpmiheZE=; h=From:To:Date; b=IE463SL9afmySHaVrWQd1r4gOa04MWQgDVorju7mxyNLKkz1qX1DOWMmeIJ09fnVR wCOncY7KGYS8lJEHkQUPkn1EJrDWZ2CnIvaTUVow/hbVU2+gRxHFC0WK2GWNh2n14I rLfOg/N7ON0h65SghD2zhXnxW5esGItrsE8epP6U=
Message-ID: <5f3081d2731263f93486e8242310733e9f4060a4.camel@nic.cz>
From: Ladislav Lhotka <lhotka@nic.cz>
To: netmod@ietf.org
Date: Wed, 02 May 2018 12:35:12 +0200
In-Reply-To: <20180502093626.ugsg6nq24a6vjtdn@elstar.local>
References: <CABCOCHSupojOLssLebB-mR_PybRLA_4bcbaNF6-8ZUrx1Pu53w@mail.gmail.com> <20180502.092527.2305319833268262996.mbj@tail-f.com> <9fca04b0-fb29-36b3-67aa-2f2c4fb98748@cisco.com> <20180502.112506.845305331945500257.mbj@tail-f.com> <20180502093626.ugsg6nq24a6vjtdn@elstar.local>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.28.1
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/PJZMyzy7T5ww71Op6N0hMYDOCdk>
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 10:35:13 -0000

On Wed, 2018-05-02 at 11:36 +0200, Juergen Schoenwaelder wrote:
> On Wed, May 02, 2018 at 11:25:06AM +0200, Martin Bjorklund wrote:
> > 
> > The primary use case is not "generic RPC messages", but standalone
> > instance documents, error-info structures, etc.
> > 
> > > This doesn't seem to be a fundamental change in YANG's scope, or
> > > architecture.
> 
> The proper solution for rpcs and actions is to define error
> information as part of the rpc/action. YANG 1.1 does not support
> this but this is where it should be fixed.
> 
> Standalone instance documents (not tied to datastores) may have their
> use cases as well but it feels odd to create support for standalone
> instance documents as extensions and then to create even more
> extensions to support augmentation of these instance documents and
> whoever knows what comes next. For short-term needs, there is
> yang-data defined in RFC 8040. The longer-term solution should IMHO be
> a proper part of YANG and not an extension.
> 
> And if the current short-term solution requires an additional
> container, then bam go for the additional container. If there is
> serious pressure to use yang-data, then the additional container
> should not stop people that need to use yang-data today.

I agree with all of the above.

Lada

> 
> /js
> 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67