Re: [netmod] yang-data issues

Qin Wu <bill.wu@huawei.com> Tue, 23 October 2018 01:37 UTC

Return-Path: <bill.wu@huawei.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 0BC72130DEB for <netmod@ietfa.amsl.com>; Mon, 22 Oct 2018 18:37:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iia6pT8BxND0 for <netmod@ietfa.amsl.com>; Mon, 22 Oct 2018 18:37:34 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 60356130DD9 for <netmod@ietf.org>; Mon, 22 Oct 2018 18:37:34 -0700 (PDT)
Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id A8149BCB18676 for <netmod@ietf.org>; Tue, 23 Oct 2018 02:37:29 +0100 (IST)
Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 23 Oct 2018 02:37:30 +0100
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.10]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0415.000; Tue, 23 Oct 2018 09:37:24 +0800
From: Qin Wu <bill.wu@huawei.com>
To: Kent Watsen <kwatsen@juniper.net>, "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: [netmod] yang-data issues
Thread-Index: AQHUSavF2bweVYawaEOu4z2U70td9KUnzRIAgAR+tvA=
Date: Tue, 23 Oct 2018 01:37:24 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABA9B0BC63B@nkgeml513-mbx.china.huawei.com>
References: <20180911.104447.2165943059473950359.mbj@tail-f.com> <DAEC916E-564D-436E-8B34-6235BDC466AC@juniper.net>
In-Reply-To: <DAEC916E-564D-436E-8B34-6235BDC466AC@juniper.net>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.138.33.244]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/HcZe6YXfCPA6cpabCXAHyhwpJRc>
Subject: Re: [netmod] yang-data issues
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
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, 23 Oct 2018 01:37:37 -0000

-----邮件原件-----
发件人: netmod [mailto:netmod-bounces@ietf.org] 代表 Kent Watsen
发送时间: 2018年10月20日 20:49
收件人: netmod@ietf.org
主题: Re: [netmod] yang-data issues

Folks,

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 <netmod-bounces@ietf.org> on behalf of Martin Bjorklund <mbj@tail-f.com>
Date: Tuesday, September 11, 2018 at 4:45 AM
To: "netmod@ietf.org" <netmod@ietf.org>
Subject: [netmod] yang-data issues

Hi,

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 {
      description
        "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;
        }
        description
          "Indicates the reason why the subscription has failed to
          be modified.";
      }
      uses hints;
    }

This would be encoded as:

  <modify-subscription-datastore-error-info>
    <reason>foo</reason>
    <period-hint>42</period-hint>
    ...
  </modify-subscription-datastore-error-info>


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
pattern:

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



/martin

_______________________________________________
netmod mailing list
netmod@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=7nlVu5dJaa8XsD0LRd0VTH301caVRUXGsa6L-UgXVRE&s=1o7vXH-j8Ha6xbJFTG1jjNzy9JQw7k-UWIqpeCr8qrk&e=

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod