Re: [netmod] A reworking of RFC8343
Schönwälder, Jürgen <J.Schoenwaelder@jacobs-university.de> Tue, 22 October 2019 20:43 UTC
Return-Path: <J.Schoenwaelder@jacobs-university.de>
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 6F0E51200A4 for <netmod@ietfa.amsl.com>; Tue, 22 Oct 2019 13:43:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NONE=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=jacobsuniversity.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 6awhBzbA15IH for <netmod@ietfa.amsl.com>; Tue, 22 Oct 2019 13:43:05 -0700 (PDT)
Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40047.outbound.protection.outlook.com [40.107.4.47]) (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 998A2120096 for <netmod@ietf.org>; Tue, 22 Oct 2019 13:43:05 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jm8ASRrZ3vT1dDskbUl8f5AKBY1hTziUoi5+UWVbTjSWklozp1EfkHf8QF+i3jktK1MmFDJ742Gz5LyZxRuJlwXsjHHaeBC7C3Tiw25+iK5yv9QPAyTBoacwmJjh4QjS0OMkvtj/2t/1R5zeEjyRiVQLK/QRk3WMyCsdSiYrqUkLAKx9iCuSfkZMQRLuNCQKrk8ZNXxxDxuTqqYJy9plVdove5f8X0EH6KrPFT82ZF1JAhCgjC+VG/Nb+aGQkICUma0TteUomOG0Ywb9mFzwvrbpD3s2rgEJJL1RND4g/ohWvmgWpjoBMFKPkVB9CnqAN+81Q3tLHB3MJQim4YzejQ==
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=lf3sv/YCeet7FiqpXAORRszwDSbjmeKyJo/ovB1DW6Q=; b=Jr+BlBcZYPW1Us9Qje8ibxwWnVBORtdGuthBCbpS1TdO71baOx6p8rB2s9gYfClDt9KEjr4+2x4mX41cE6109v9rscZOrvivjmASdJTK1nHWSGmaBS/mZI4bXv8sgdcUf3SOPH7n2SY+mzwo+xT/VwPOmuJqE940Wkz5UcpSRZpnfZzI99fivtkXMdI+zA9QuWbhEo8HzEBFX6tW/tma35L9R3A3XjfGHzIbeRnOSXqY0I4bhZFnqC9vfnxBza8PBMtkLVJE7S99OEhvmWazzZ8+6y6eihZYCGdCGFry4j4In5nkmFf/BLf0Oq3hpFBXJ7XALkfarFMfybJFNBwlBQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lf3sv/YCeet7FiqpXAORRszwDSbjmeKyJo/ovB1DW6Q=; b=N/43ZqY+kTb7XDTQhH2qefkbSNvjmOaBWwnA0sfLKZrCV2vCTajppWRCUuAJv92nAxSEZb7IeMgjzD7dTa5zb4oHlAMivzg9Cr3MxaaBLyGaE4IZwzeJTH9GGIzH+uU4AuriuKJLvhy6+KeHb5Gci3DgBMyGCDkiesLz5VUoSo0=
Received: from AM4P190MB0129.EURP190.PROD.OUTLOOK.COM (10.172.218.17) by AM4P190MB0003.EURP190.PROD.OUTLOOK.COM (10.172.220.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2367.21; Tue, 22 Oct 2019 20:43:03 +0000
Received: from AM4P190MB0129.EURP190.PROD.OUTLOOK.COM ([fe80::1112:b17:e675:4506]) by AM4P190MB0129.EURP190.PROD.OUTLOOK.COM ([fe80::1112:b17:e675:4506%9]) with mapi id 15.20.2367.022; Tue, 22 Oct 2019 20:43:03 +0000
From: "Schönwälder, Jürgen" <J.Schoenwaelder@jacobs-university.de>
To: Dmytro Shytyi <ietf.dmytro@shytyi.net>
CC: Martin Bjorklund <mbj@tail-f.com>, netmod <netmod@ietf.org>
Thread-Topic: [netmod] A reworking of RFC8343
Thread-Index: AQHViRJ+NKRnTgLb7E6oQ8qhAUHquqdnFhMAgAAGMICAAAQwAA==
Date: Tue, 22 Oct 2019 20:43:03 +0000
Message-ID: <20191022204302.5me6qb65f3zkrqad@anna.jacobs.jacobs-university.de>
References: <8736fmtk3d.fsf@nic.cz> <20191021.134014.40553165389352172.mbj@tail-f.com> <039001d588c2$bb3d7e20$4001a8c0@gateway.2wire.net> <20191022.133131.983827662033885262.mbj@tail-f.com> <16df50844b1.bbb67c6096091.5644334168758722892@shytyi.net> <20191022200554.dt6x57eksvqbvngj@anna.jacobs.jacobs-university.de> <16df527b509.f1eff96d96574.7542135600963858099@shytyi.net>
In-Reply-To: <16df527b509.f1eff96d96574.7542135600963858099@shytyi.net>
Reply-To: "Schönwälder, Jürgen" <J.Schoenwaelder@jacobs-university.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: AM0PR06CA0040.eurprd06.prod.outlook.com (2603:10a6:208:aa::17) To AM4P190MB0129.EURP190.PROD.OUTLOOK.COM (2603:10a6:200:5f::17)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=J.Schoenwaelder@jacobs-university.de;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [2001:638:709:5::7]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: d549b9b8-38b1-4183-2e5a-08d757306f07
x-ms-traffictypediagnostic: AM4P190MB0003:
x-ms-exchange-purlcount: 1
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <AM4P190MB00037FD21F82A4A37D517785DE680@AM4P190MB0003.EURP190.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:7691;
x-forefront-prvs: 01986AE76B
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(136003)(376002)(39850400004)(346002)(366004)(199004)(189003)(14454004)(386003)(6506007)(54906003)(486006)(45776006)(316002)(7736002)(3450700001)(6486002)(43066004)(81156014)(25786009)(52116002)(5660300002)(11346002)(102836004)(81166006)(305945005)(476003)(786003)(76176011)(186003)(446003)(6306002)(6512007)(66946007)(99286004)(6116002)(8676002)(8936002)(6246003)(64756008)(6436002)(478600001)(6916009)(66556008)(86362001)(66446008)(4326008)(66476007)(1076003)(2906002)(229853002)(71190400001)(71200400001)(46003)(256004); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4P190MB0003; H:AM4P190MB0129.EURP190.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: jacobs-university.de does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: QSIMbqVfwYEAW2D7MvbEXWwd/gDZG+A6twHzo3d73tHfQdGgXnqDNpXyUA+b+UTdXavBA2Tk3SjifMQ7j26uJVCtluK4icbdKO1sVOe1ljlE6Qk7WNwVUfDMgCXilNc1Of91IayCBR5FJkfbYNU/pcUXavTjIvJjCIL7k/7WTZOWbNLH+G9eHQqoXlojbch/b6TBhaO+Wx6VF0L4haQH2IVRZzdPqLwX8OFecTuMKiAGwQTkzpPSvxgtKxIj2yO7QuZ4/Xvpj1zVdks4RPngNvttagxrNwfOUGqL2iA097uNi8l9XqOyoNK+5IpM/ZkgCnr7ygqiPcqjWMGdHTodirdws2vKGXfhycZo2wkVEjwB6mJgHu456BwTVOhz3MLdZ7N0tXeJDHEt8klj5RV24b/JTWwAoMdxabLvdxM7p7wSHZpwh4LEWVED76hf6Zh6Hdr8JqIqSNtSRImdTxB/ZrSUzfY/kcWb2dQHcFb3B5M=
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <DB31C82E63C960409529A99784D250B6@EURP190.PROD.OUTLOOK.COM>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: jacobs-university.de
X-MS-Exchange-CrossTenant-Network-Message-Id: d549b9b8-38b1-4183-2e5a-08d757306f07
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Oct 2019 20:43:03.1621 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: gKgTktqJMOQhiwo/0Vo9njvpfbjoDYztmoF3LGbTyvuEUBBgwiy8x3rhQctF9P8OAdupQOcjlzJUfFAI8ERcNsDxfzlIkOB2Dd4OjDMfkDI=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4P190MB0003
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/LcbdUVupaPaw1RlxAh1yg1Wvgpk>
Subject: Re: [netmod] A reworking of RFC8343
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, 22 Oct 2019 20:43:08 -0000
On Tue, Oct 22, 2019 at 10:28:03PM +0200, Dmytro Shytyi wrote: > > Cut and paste to change the 'nesting' is _not_ proper usage of > YANG. The value of YANG is that objects with the same semantics are > predictable, this gives you interoperability. By copying modules to > other places (and tweaking semantics), you break the interoperability > promise. > > /js > > > [Dmytro]. > > I find the task much easier if we could just augment the interfaces module without changing it. I see it the next way . The "ietf-interfaces" yang module initially was created for the config, when you have: > > config t > > interfaces interface ... > > Here we have different condition of "nesting"... when module "ucpe-ietf-interfaces" (not "ietf-interfaces") shout augment another module ("ietf-ucpe") > > > > We augment vPorts to phy interfaces. I do not understand your explanation. The ietf-interfaces hierarchy can be found on page 5 of RFC 8343. You can augment additional nodes into it. > >Cut and paste to change the 'nesting' is _not_ proper usage of > > YANG. > > [Dmytro] > > If I understood correctly I can't just derive the parts from the exisiting module (by referencing them) to the new module. > I have no idea what you mean with "(by referencing them) to the new module". You can of course refer to definitions in ietf-interfaces. > So I have two questions: > > If i cant derive the parts from existing module while creating a new, how to address this issue(when we want "ucpe-ietf-interfaces" to augment "ietf-ucpe"). Could you suggest something? I likely do not understand but you can of course augment ietf-interfaces with additional nodes that refer to ietf-ucpe definitions if that is what you are looking for. > So the here I have a question: How we will resolve the leafref in the draft-shytyi-opsawg-vysm-04. if we will not do the augmentation of "ietf-ucpe" in the ""ucpe-ietf-interfaces? > > augment "/ietf-nfv:ucpe/ietf-if:interfaces/ietf-if:interface" { > list ports { > key "port"; > leaf port { > type string; > description > "Name of the connector"; > } > leaf link { > type leafref { > path "../../../../ietf-nfv:links/ietf-nfv:link"; > } > description > "Link that is connected to the port > via connector"; > } > description > "Set of the connectors the physical > interface has"; > } > description > "ucpe ports of the interface"; > } > } I think it is possible to have a path contraint on a leafref that refers to definitions in other modules (see the ABNF definition path-arg which resolves to absolute-path and relative-path and descendant-path and in there you find node-identifier which can carry an optional prefix that allows to refer to definitions in other namespaces). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://www.jacobs-university.de/>
- Re: [netmod] leafref and identityref Ladislav Lhotka
- [netmod] leafref and identityref Ladislav Lhotka
- Re: [netmod] leafref and identityref Martin Bjorklund
- Re: [netmod] leafref and identityref Martin Bjorklund
- Re: [netmod] leafref and identityref Ladislav Lhotka
- [netmod] A reworking of RFC8343 tom petch
- Re: [netmod] A reworking of RFC8343 tom petch
- Re: [netmod] A reworking of RFC8343 Martin Bjorklund
- Re: [netmod] A reworking of RFC8343 Dmytro Shytyi
- Re: [netmod] A reworking of RFC8343 Schönwälder
- Re: [netmod] A reworking of RFC8343 Dmytro Shytyi
- Re: [netmod] A reworking of RFC8343 Schönwälder
- Re: [netmod] [OPSAWG] draft-shytyi-opsawg-vysm-04 Dmytro Shytyi
- Re: [netmod] [OPSAWG] draft-shytyi-opsawg-vysm-04 Schönwälder