Re: [netmod] Question about schema-mount

"Bogaert, Bart (Nokia - BE/Antwerp)" <bart.bogaert@nokia.com> Thu, 28 November 2019 08:37 UTC

Return-Path: <bart.bogaert@nokia.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 4C798120026 for <netmod@ietfa.amsl.com>; Thu, 28 Nov 2019 00:37:57 -0800 (PST)
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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com
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 SPd-3--rnuct for <netmod@ietfa.amsl.com>; Thu, 28 Nov 2019 00:37:54 -0800 (PST)
Received: from FRA01-PR2-obe.outbound.protection.outlook.com (mail-eopbgr120128.outbound.protection.outlook.com [40.107.12.128]) (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 8E362120025 for <netmod@ietf.org>; Thu, 28 Nov 2019 00:37:54 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bNLno342RhT+HvE102hLUzdeWqeL5rMfp35DdMkWEYPU41nA+R+dDZ30v6Yl66tZ4ObYC7X6vfqPCl5m++yk/SugfJdNRpiqoUcV6V4g9VxuUFuw0Izur4fS2R9M5penjCoos1JVOj0nE6VN7TXP4HQKd8k5AmHxswzwOTPfrtrqIvAcgfHkBeWm9kphqSc9y+kNsbKoAAI0r/JcUug9o/YPvJN+YT/cziiJ5zyNvWJnufT+FNZB9/evJ2qUeuZjRfuY1u1EorUq1Z3bZEw7Ft73ESlA+wcb3FwB1MHOPe4C66UHCe+eBLvTBbZQ956qkE0XViPpZ0Wp2Lt9CuMKBg==
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=oSgCxiPw8h01vVY1Zqe6KgeyRCrSnRSF2pqdPLJKYmk=; b=NC6JQ7I1NSh6oZ7SlkkfkEWznY8t8mB/67wVtLQ8U9+9ibY/E+8KrKOZ/AGuMxYyO/BsdZNhZBj+ae8z32NTRGoMwUkS54IJJee36PIp4l3svz8sjTX5rlbkCMec0Zuunl28oDbEr1H41rGGmSpS28LdN1A17mgXQLY2/+vB8BHYeyD95LOwvA7zBou0veCRGnQkSXVfH8vl3/OLsHzJqiKKATuXAhMBY6KaQBz0ckoYFgZWMZLiQ72/qauAyRDHg8WZva79w1TE+mUZQSpcGk/XKskaGJGGvt9oMf8+aXPCBT1AHIGd7nyTl9R/ne6ceqF/7PBLdxWgKdU9+hpT3g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oSgCxiPw8h01vVY1Zqe6KgeyRCrSnRSF2pqdPLJKYmk=; b=VWaW4GuLRHV+wjTX+YDNcsBkwNG3Mrk4pUcM61BTWifn/vL8HBbA2guHHS0PlbbM4tKhHkSRmr3GKUn7D6GFE/740QZzCoGCUoVvU4lKSJYdmzJn7DW0PvQTrvI7csBMDOvTOHqU9z1FbG5CmQ/EZkY9zP2BaXZXuNGDByRJ8+0=
Received: from PR1PR07MB5084.eurprd07.prod.outlook.com (20.177.211.156) by PR1PR07MB4939.eurprd07.prod.outlook.com (20.177.208.90) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2495.14; Thu, 28 Nov 2019 08:37:52 +0000
Received: from PR1PR07MB5084.eurprd07.prod.outlook.com ([fe80::f83d:1e2c:e85:3e6e]) by PR1PR07MB5084.eurprd07.prod.outlook.com ([fe80::f83d:1e2c:e85:3e6e%5]) with mapi id 15.20.2495.014; Thu, 28 Nov 2019 08:37:52 +0000
From: "Bogaert, Bart (Nokia - BE/Antwerp)" <bart.bogaert@nokia.com>
To: Martin Bjorklund <mbj@tail-f.com>
CC: "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: [netmod] Question about schema-mount
Thread-Index: AdWk9fv8FHvjWB4ASPu2WAFNJmQaWAAz7VcAAAAdBOA=
Date: Thu, 28 Nov 2019 08:37:52 +0000
Message-ID: <PR1PR07MB50843E27EE1440DAE654244494470@PR1PR07MB5084.eurprd07.prod.outlook.com>
References: <PR1PR07MB5084895F5DBBA09EA1ADE2B494440@PR1PR07MB5084.eurprd07.prod.outlook.com> <20191128.092738.1831675400353812183.mbj@tail-f.com>
In-Reply-To: <20191128.092738.1831675400353812183.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=bart.bogaert@nokia.com;
x-originating-ip: [178.119.249.45]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: e96abb54-f3ec-4649-14c2-08d773de420a
x-ms-traffictypediagnostic: PR1PR07MB4939:
x-microsoft-antispam-prvs: <PR1PR07MB4939B760D3C0D4DE7D2F8E2694470@PR1PR07MB4939.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 0235CBE7D0
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(376002)(346002)(136003)(396003)(366004)(199004)(189003)(13464003)(7736002)(8676002)(4326008)(14454004)(256004)(5660300002)(11346002)(6246003)(229853002)(33656002)(74316002)(66476007)(66946007)(6916009)(71190400001)(66556008)(71200400001)(14444005)(52536014)(66446008)(7696005)(26005)(2906002)(186003)(64756008)(9686003)(446003)(316002)(66066001)(8936002)(305945005)(25786009)(99286004)(478600001)(55016002)(86362001)(6506007)(76116006)(53546011)(81166006)(6116002)(3846002)(6436002)(81156014)(76176011)(102836004); DIR:OUT; SFP:1102; SCL:1; SRVR:PR1PR07MB4939; H:PR1PR07MB5084.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: dzuz4QSOKBvvJ4OmA9TOuxtGjYQ6JMrxdv9pHEveiCd/rHc1PIO6VpDeARozcNPdessGH7wr8ObhfPMKOmMB5SPieZYuUp6+MAhtAOWkXIv8+ooP0rT1W1bmbz4CybAM6tmQNfGkjyR0J79cN4TwJadIBBGUWkWIGvIdcEfaX5l3rkHdNScQuv5Svy+R3QLGmUAIHs4gj0av256Wkf4QJ3hwBn/Cb8teXpXzE91ZFkCEfc99NysvtkSsBsNvXZs0xLqfJBOarREQgvaDoUrpZimI9jXRfh/UcyBQarZ2maxZ7rXf5uA690Ua6K890OeEypr/TjOSdw5ir+ye0RMcTlsAbS4t6VfXjy+DmqYnwzhf3dI3wF4xmQ+SjNSLJbIDg4vJwz5Gdr3YSDQbLEJxwkR3FwNfJs41Z1bJD9y+zH2EVFRQwCVchKSzQddINxAA
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e96abb54-f3ec-4649-14c2-08d773de420a
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Nov 2019 08:37:52.3425 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: P0aqpWj6rn5WT0uZPQHfc/w9KKRhJWZb3h5CXOyfI+RAmBUPSIr1qadcslOIc9ifdvDL56s+U6mRC9OHG6MPfw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR1PR07MB4939
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/NJRtzMpBBqWAkJDhFXpooyd_KRo>
Subject: Re: [netmod] Question about schema-mount
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: Thu, 28 Nov 2019 08:37:57 -0000

Hi Martin,

-----Original Message-----
From: Martin Bjorklund <mbj@tail-f.com> 
Sent: Thursday, November 28, 2019 9:28 AM
To: Bogaert, Bart (Nokia - BE/Antwerp) <bart.bogaert@nokia.com>
Cc: netmod@ietf.org
Subject: Re: [netmod] Question about schema-mount

Hi,

"Bogaert, Bart (Nokia - BE/Antwerp)" <bart.bogaert@nokia.com> wrote:
> Hi,
> 
> We're trying to figure out whether it is possible to define a module 
> in the parent schema which would use a node being a leafref to a node 
> in a model under a mount point.

In order for this to work, the leafref target would have to be present at compile time / design time.  RFC 8528 defines Design time, Implementation time, and Run time mounts, and says: "Design-time mounts are outside the scope of this document" (see section 1).

Another alternative would be some new kind of "leafref-like" construct that supported this.

What you can do though is to ensure the leaf in the parent module is of the same type as the mounted node you want to refer to, and explain in text what the semantics is.

[Bogaert, Bart] Thanks for this feedback.  The use case we're looking into is the following:
[Bogaert, Bart] A forwarder contains references to interfaces which are defined as leafref with path /interfaces/interface/name.  In the scope of this question the path would be /logical-network/elements/logical-network-element/interfaces/interface/name.  Question is: will this work with leafref?  What will the [Bogaert, Bart] NETCONF server do in such a case, in other word: is it able to resolve this leafref or do we have to define this as a some kind of string that includes the name of the logical-network-element and the name of the interface?


> I don't seem to find any statement
> that would prohibit this but RFC 8530, referred to from the schema 
> mount RFC, uses a leafref to a node in a module which is still in the 
> list of YANG modules of the parent (and consequently in the YANG 
> library of the parent).
> 
> So, using RFC8530 as example:
> 
> Instead of lne:bind-lne-name being a leafref to 
> /logical-network-elements/logical-network-element/name we would point 
> to 
> /logical-network-elements/logical-network-element/interfaces/interface/name.
> 
> The interfaces YANG module is also part of the YANG library of the 
> parent but I'm not so sure whether above construction would work well 
> as the information related to the mounted YANG modules is in a YANG 
> library different from the parent's YANG library.
> 
> Note that there is also some confusion with the examples in RFC8530:
> while the bind-lne-name in the YANG module is a leafref as syntax, the 
> examples work with a string as syntax for that same leaf.

Do you mean the tree diagram?

[Bogaert, Bart] Correct.

Best regards, Bart

   module: ietf-interfaces
     +--rw interfaces
        +--rw interface* [name]
           +--rw name                        string
           +--rw lne:bind-lne-name?          string

This looks like a bug to me; it should be a leafref.


/martin