From: =?iso-8859-1?Q?Sch=F6nw=E4lder=2C_J=FCrgen?=
 <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: =?iso-8859-1?Q?Sch=F6nw=E4lder=2C_J=FCrgen?=
 <J.Schoenwaelder@jacobs-university.de>
Accept-Language: en-US
Content-Language: en-US
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:
> =20
> Cut and paste to change the 'nesting' is _not_ proper usage of=20
> YANG. The value of YANG is that objects with the same semantics are=20
> predictable, this gives you interoperability. By copying modules to=20
> other places (and tweaking semantics), you break the interoperability=20
> promise.=20
> =20
> /js
>=20
>=20
> [Dmytro].=20
>=20
> I find the task much easier if we could just augment the interfaces modul=
e without changing it. I see it the next way . The "ietf-interfaces" yang m=
odule initially was created=A0 for the config, when you have:
>=20
> config t=A0
>=20
> =A0 =A0 =A0 interfaces interface ...
>=20
> Here we have different condition of "nesting"... when module "ucpe-ietf-i=
nterfaces" (not "ietf-interfaces") shout augment another module ("ietf-ucpe=
")
>=20
>=20
>=20
> 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=20
>=20
> YANG.
>=20
> [Dmytro]
>=20
> If I understood correctly I can't just derive the parts from the exisitin=
g module=A0 (by referencing them) to the new module.
>=20

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.
=20
> So I have two questions:
>=20
> 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=A0 here I have a question: How we will resolve the leafref in the=
=A0draft-shytyi-opsawg-vysm-04. if we will not do the augmentation of "ietf=
-ucpe" in the ""ucpe-ietf-interfaces?
>=20
> 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

--=20
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/>