Re: [netmod] yang-data issues

Qin Wu <> Tue, 23 October 2018 01:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0BC72130DEB for <>; Mon, 22 Oct 2018 18:37:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Iia6pT8BxND0 for <>; Mon, 22 Oct 2018 18:37:34 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 60356130DD9 for <>; Mon, 22 Oct 2018 18:37:34 -0700 (PDT)
Received: from (unknown []) by Forcepoint Email with ESMTP id A8149BCB18676 for <>; Tue, 23 Oct 2018 02:37:29 +0100 (IST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 23 Oct 2018 02:37:30 +0100
Received: from ([]) by ([]) with mapi id 14.03.0415.000; Tue, 23 Oct 2018 09:37:24 +0800
From: Qin Wu <>
To: Kent Watsen <>, "" <>
Thread-Topic: [netmod] yang-data issues
Thread-Index: AQHUSavF2bweVYawaEOu4z2U70td9KUnzRIAgAR+tvA=
Date: Tue, 23 Oct 2018 01:37:24 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [netmod] yang-data issues
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 23 Oct 2018 01:37:37 -0000

发件人: netmod [] 代表 Kent Watsen
发送时间: 2018年10月20日 20:49
主题: Re: [netmod] yang-data issues


Can we get some quick replies to this email?

[Qin]: I believe restconf collection work might benefit from this work as well. It follows traditional usages of rc:yang-data,
However I am not sure the benefit to remove container defined within yang-data extension, the restrict ion I see this,
In traditional usage of yang-data, we can add more than one containers, then augment-yang-data can augment from any of these containers 
defined within yang-data extension.
But with below proposal, we lose such flexibility, in my opinion.

Kent // all hats

-----Original Message-----
From: netmod <>; on behalf of Martin Bjorklund <>;
Date: Tuesday, September 11, 2018 at 4:45 AM
To: ""; <>;
Subject: [netmod] yang-data issues


The authors of draft-ietf-netmod-yang-data-ext have been discussing the two remaining issues on this draft; the issue of whether a yang-data structure must have unique top-level node names or not, and the issue of the syntax for augment-yang-data.  We haven't been able to find agreement with the current proposal, so I have a suggestion for a slightly modified yang-data statement (which may have been discussed before):

The idea is to encode a yang-data extension the same way as anydata, i.e., as a container.  For example:

  yd:yang-data modify-subscription-datastore-error-info {
        "This yang-data MAY be provided as part of a subscription's RPC
        error response when there is a failure of a
        'modify-subscription' RPC which has been made against a
        datastore.  This yang-data MUST be used if hints are to be
        provides back to the subscriber.";
      leaf reason {
        type identityref {
          base sn:modify-subscription-error;
          "Indicates the reason why the subscription has failed to
          be modified.";
      uses hints;

This would be encoded as:


Since the structure is always encoded as a container, it follows that it can have any data definition statement as substatement, with no restriction on naming and type of statement.  An instance of this can trivially be a complete instance document in XML w/o additional context, works well with JSON, and can appear in an error-info structure.

Such a structure can be augemented as:

  yd:augment-yang-data /sn:modify-subscription-datastore-error-info {
    leaf foo { ... }

The drawback is that it forces the use of an extra container in the encoding.  OTOH, most usages of current rc:yang-data follows this

  rc:yang-data modify-subscription-datastore-error-info {
    container modify-subscription-datastore-error-info {


netmod mailing list

netmod mailing list