Re: [netconf] leafrefed data item in YANG Push
"Eric Voit (evoit)" <evoit@cisco.com> Wed, 18 December 2019 22:34 UTC
Return-Path: <evoit@cisco.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BADE6120086 for <netconf@ietfa.amsl.com>; Wed, 18 Dec 2019 14:34:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=E8CQ5+Bm; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=bc4tAbq+
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 nDgaT6Ucfx4L for <netconf@ietfa.amsl.com>; Wed, 18 Dec 2019 14:34:46 -0800 (PST)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EE53120077 for <netconf@ietf.org>; Wed, 18 Dec 2019 14:34:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11348; q=dns/txt; s=iport; t=1576708486; x=1577918086; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=nQVtis1zSTCqqgtHA/rGDd8EP1xPJMmWGx4dyUEjc3I=; b=E8CQ5+BmsV5jnhlGAbGswdQS3atZ5dUx67IMytSPG88AxTSK7Odd2+PN WAZvp8frbNAOjEx6CHrZM87lKXc9S9PQ7PU12gESnapv90K2/NEO9kPeH qVp05eanb8FO6YOaP6kChv58TLjHReRVMOHhwHDdkWHTLnvhq/giDIH+F A=;
X-Files: smime.p7s : 3975
IronPort-PHdr: 9a23:O7g3sRO97aQ74FwQ4okl6mtXPHoupqn0MwgJ65Eul7NJdOG58o//OFDEuKU/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDFf4ETBoZkYMTlg0kDtSCDBj2MvnrcwQxHd9JUxlu+HToeUU=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AqAAC6qPpd/5BdJa1lGgEBAQEBAQEBAQMBAQEBEQEBAQICAQEBAYFrAgEBAQELAYFMKScFbCstIAQLKgqDeoNGA4pxgl+YBoJSA1QCBwEBAQkDAQEYCwoCAQGDe0UCghkkNwYOAgMNAQEEAQEBAgEFBG2FNwyFXgEBAQECAQEBEBEdAQEsBAcBBAsCAQYCDgMEAQEBDAEaAwICAiULFAkIAQEEAQ0FCAYUgjVMgXlNAw4RDwECDJI7kGQCgTiIYXWBMoJ+AQEFhRUYggkHAwaBNgGBUoNJhnwagUE/gRFHgkw+gmQBAQIBgUoYFYJ5MoIsjUOCdJ5WCoI1g1+CN4EbhTeJRppOjk6IUZF9AgQCBAUCDgEBBYFoI4FYcBU7gmxQGA2NEoNzhRSFP3QBAYEmi0YrgQQBgQ8BAQ
X-IronPort-AV: E=Sophos;i="5.69,330,1571702400"; d="p7s'?scan'208";a="455727819"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 18 Dec 2019 22:34:44 +0000
Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id xBIMYik4017533 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 18 Dec 2019 22:34:44 GMT
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 18 Dec 2019 16:34:43 -0600
Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 18 Dec 2019 17:34:41 -0500
Received: from NAM12-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 18 Dec 2019 16:34:41 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=StJX1tb8LHWdvNHEYc74xtDLr9PeaL+4WPUSQ0yxSGpCevfm4g9x6hqru+b6OSnpbxbX5EXwusSoxpQgndMRom0e/L9uHrTVHly8v5JlsnZh32XoB2183kvtPOmY7ZXlGPVnk/bcwYuErogdBExRMHhqUxkyl36nkGQKIsOELPtQPvkhDUaUlyqSLboRjqEcE/30B8axzE81TAZbQSVPc7gDN9ulQxiFhM0od/YuFEPuRYCnT/0tWgtB7EWeJE0cYk0bJaxvDOk0JsoR0WHU6KehZUlC2SoUJMXVIwgmWDDBgKGu5xr3F+mtmrcP3Pq/41BkD2B6lTNGNrnJeNVmCg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WB5MO+y7Zsi1aZnjgGTp+trMiKXPxVdwjpGjpIbTXjM=; b=FFv4kuMGu6Ab1NRxizmwnqUJfEY/3XDcE4r87bmemP34oOpSgPRVJcrsbXaN7IR6Rgh8p4Ct4hEg1FOiFd+dp3rEe2biFu0+K8mi9hWpu5kzl4lpjDgkqaghqvI55KNo0/Jj6OlOTvUmu/NbH1RO+5Sqbgp8Fiaa1T6I9FQ2dq3MwRc3W3RNvi4sLARhyYjqoKLrgP14PFQa9YSZKm1tFlp05EcESRetORKwJ0muM53LAjYJlU3j/vqV+gnEqHHzm+0/zN+p1KnJWS9Rn4gW9MtGAKcam/X9oslP9y7dz/sF7Be+rb/LljWGPiNCmELjfVpP0WLXg/UNY1GQQZ4MLA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WB5MO+y7Zsi1aZnjgGTp+trMiKXPxVdwjpGjpIbTXjM=; b=bc4tAbq+XNkKFqm7jyBVpaXhwn67P+Tm4VeK4ZNnV/d0nFdYbNn7LiW4DSZ/tAVVjkQWhosoXb5ATRnIeqbIOIZJx0Ga+QZPUmHnnNwTsncdC/tiXkVM8NHcre+zsLORbM1MOZOdPn3+XZrQCsb+yB2DPOa2p70AFMZ07IY8Nzc=
Received: from DM6PR11MB2633.namprd11.prod.outlook.com (20.176.96.14) by DM6PR11MB3884.namprd11.prod.outlook.com (20.176.126.222) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2538.16; Wed, 18 Dec 2019 22:34:40 +0000
Received: from DM6PR11MB2633.namprd11.prod.outlook.com ([fe80::c4c7:61bd:790:9c1f]) by DM6PR11MB2633.namprd11.prod.outlook.com ([fe80::c4c7:61bd:790:9c1f%3]) with mapi id 15.20.2559.012; Wed, 18 Dec 2019 22:34:40 +0000
From: "Eric Voit (evoit)" <evoit@cisco.com>
To: Qin Wu <bill.wu@huawei.com>, Martin Bjorklund <mbj@tail-f.com>
CC: "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [netconf] leafrefed data item in YANG Push
Thread-Index: AdW1QZoZRKi9i69nQbyATo6Q8uMhYgArIluQ
Date: Wed, 18 Dec 2019 22:34:40 +0000
Message-ID: <DM6PR11MB2633A99E7D8BC8CF036628C5A1530@DM6PR11MB2633.namprd11.prod.outlook.com>
References: <B8F9A780D330094D99AF023C5877DABAA9500CAD@dggeml511-mbx.china.huawei.com>
In-Reply-To: <B8F9A780D330094D99AF023C5877DABAA9500CAD@dggeml511-mbx.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=evoit@cisco.com;
x-originating-ip: [173.38.117.79]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: e3db2b2e-88c0-45ac-2bdb-08d7840a78ca
x-ms-traffictypediagnostic: DM6PR11MB3884:
x-microsoft-antispam-prvs: <DM6PR11MB3884381DBE68B4E10A7C1E75A1530@DM6PR11MB3884.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0255DF69B9
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(39860400002)(396003)(366004)(136003)(199004)(189003)(478600001)(55016002)(110136005)(2906002)(76116006)(86362001)(966005)(8936002)(33656002)(53546011)(6506007)(81156014)(7696005)(8676002)(52536014)(316002)(26005)(5660300002)(66556008)(66616009)(9686003)(66946007)(66446008)(64756008)(66476007)(186003)(71200400001)(4326008)(81166006); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR11MB3884; H:DM6PR11MB2633.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: SduizNq+9LY+Sb8/Zyl589gV7R4pxAKI1WFhCZimx46kan7JgPbDrvydQHO5BWbblKhXCrAuNTd7u43wl3gTPVVu2YDIbdZIYmTPDxQug2Nwa09b1avnoLG3oBOUl9aBLAJVOn+pkRZ/LCSecCghpfYRrreQFtp5yFU1GLc8UyFqm3UZbDO9kfoQTwpWu63JM2cXFM0HxksnUYUgqHcEyF8BG3rpofnGPtDk97W2fpQTq6S8t7dBko/6DkvGk26XNhTsH9Z5K8teVwMtb+lD8AVIl7AQvgmCP8ZHvWvnmw7BfkkSYl3IUXFz+OTVXrJ2OM0JeZedxQASeP2ENVwuOJnGv71dsG7BxcWwXwCt1ZGwTgSqdyUy90s6c7KaX4AzGKqqn42OobN8TxU+avBb4JCBTlF90F3xrD5w1/ZS8d9PEV/MyN/j8sCDn0J5qMqMlaelUU/xr4ZOvUmFJ4AnV3l8/DdBVqeIypGMG+YouLM=
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_00BF_01D5B5C9.615A27D0"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: e3db2b2e-88c0-45ac-2bdb-08d7840a78ca
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Dec 2019 22:34:40.6060 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: OTrBGaDVt50Oc79fuz8yOmj0w1otHEqw+Ich4eNiIh9SL6SicbvtJ7oZHhOqli8d
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB3884
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com
X-Outbound-Node: rcdn-core-8.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/NHK5Vy9O26RGM8OZI2UyXWDm71o>
Subject: Re: [netconf] leafrefed data item in YANG Push
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Dec 2019 22:34:49 -0000
> From: netconf <netconf-bounces@ietf.org> On Behalf Of Qin Wu > Sent: Tuesday, December 17, 2019 8:35 PM > To: Martin Bjorklund <mbj@tail-f.com> > Cc: netconf@ietf.org > Subject: Re: [netconf] leafrefed data item in YANG Push > > Thanks Martin for clarification, I understand the dependency between > subscription is different from dependency between two leafs. > But still not clear what is the real case for dependency? Should parent > subscription and child subscription point to same leafs in the same modules > requested by the same subscriber? > If not, how a set of data defined by parent subscription and child > subscription are put together? Is this related to object correlation? Hi Qin, I know you are aware of this, but I wanted to be sure people on the thread follow. "/subscriptions/subscription/dependency" is for figuring out which from a set of buffered event records should be transmitted first. This could be a fairly common problem in some deployment scenarios which need to prevent head-of-line blocking. A good resource to understand the behavior of dependency is to look at HTTP2 stream dependency: https://tools.ietf.org/html/rfc7540#section-5.3.1 Right now anything related to "/subscriptions/subscription/dependency" is independent from inter-subscription correlation and pruning of any redundancy in pushed objects spanning multiple subscriptions. Eric > -Qin > -----邮件原件----- > 发件人: Martin Bjorklund [mailto:mbj@tail-f.com] > 发送时间: 2019年12月16日 16:33 > 收件人: Qin Wu <bill.wu@huawei.com> > 抄送: jason.sterne@nokia.com; netconf@ietf.org > 主题: Re: [netconf] leafrefed data item in YANG Push > > Hi, > > Qin Wu <bill.wu@huawei.com> wrote: > > Thanks Jason for clarification, 2 leafs associated with each other via > > leafref can be defined in the same module, can be defined in two > > separate modules (see example module below), I am wondering whether > > these two cases are treated by the server in the same way. > > Yes they are, in the sense that a leafref is not treated different than e.g. a > string by the YANG Push server. > > > RFC8639 provides a dependency parameter to describe the relationship > > between two subscriptions, I am wondering whether this dependency > > parameter is designed to address the case where two leafs are > > associated with each other via leafref in two different modules. > > > > Take the below modules as an example, > > We may have two subscriptions, one subscription A is used to > > subscribed to leaf aa in module foo, the other subscription B is used > > to subscribed to leaf cc and bb in module bar. So the subscription A > > will use dependency parameter to indicate leaf bb is associated with > > leaf aa in subscription B, right? > > No the dependency parameter is not used by a subscriber to "indicate" > (to whom?) that two leafs are associated. > > > If the answer is no, what is the real case for dependency parameter > > defined in RFC8639? > > From RFC 8639, section 2.3: > > If a subscription has the "dependency" parameter set, then any > buffered notification messages containing event records selected by > the parent subscription MUST be dequeued prior to the notification > messages of the dependent subscription. > > It it used to control the order in which the notifications are sent. > > > /martin > > > > > > > -Qin > > 发件人: Sterne, Jason (Nokia - CA/Ottawa) > [mailto:jason.sterne@nokia.com] > > 发送时间: 2019年12月14日 3:20 > > 收件人: Qin Wu <bill.wu@huawei.com>; netconf@ietf.org > > 主题: RE: leafrefed data item in YANG Push > > > > Hi Qin, > > > > For subscriptions, I don't think it matters if 2 leafs are associated > > with each other via a leafref. When you subscribe to each of those > > leafs, it is just like subscribing to any other 2 leafs (that aren't > > associated with eachother). > > > > About the 'dangling reference': that should be accepted into the > > running datastore. It would fail validation. So it can only exist in > > the candidate. > > > > Jason > > > > From: netconf > > <netconf-bounces@ietf.org<mailto:netconf-bounces@ietf.org>> On Behalf > > Of Qin Wu > > Sent: Thursday, December 12, 2019 11:09 PM > > To: netconf@ietf.org<mailto:netconf@ietf.org> > > Subject: [netconf] leafrefed data item in YANG Push > > > > Hello: > > Can I subscribe to specific data item that refer to data item in > > another YANG module with other data item in the same subscription? > > Module bar { > > import foo {prefix ex;} > > leaf cc{type int8;} > > leaf bb { > > type leafref { > > path "../ex:aa"; > > } > > } > > } > > > > Module foo { > > leaf aa { > > type int8; > > } > > } > > In addition, If there is dangling reference, e.g., leaf bb refer to > > leaf aa which doesn’t exist, how this failure is handled by the server > > and exposed to the client? > > > > -Qin > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf
- [netconf] leafrefed data item in YANG Push Qin Wu
- Re: [netconf] leafrefed data item in YANG Push Sterne, Jason (Nokia - CA/Ottawa)
- Re: [netconf] leafrefed data item in YANG Push Qin Wu
- Re: [netconf] leafrefed data item in YANG Push Martin Bjorklund
- Re: [netconf] leafrefed data item in YANG Push Qin Wu
- Re: [netconf] leafrefed data item in YANG Push Eric Voit (evoit)
- Re: [netconf] leafrefed data item in YANG Push Qin Wu
- Re: [netconf] leafrefed data item in YANG Push Sterne, Jason (Nokia - CA/Ottawa)