Re: [netmod] References to the "tags" typedef

"Rob Wilton (rwilton)" <rwilton@cisco.com> Mon, 07 October 2019 09:16 UTC

Return-Path: <rwilton@cisco.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 06AF91200B1 for <netmod@ietfa.amsl.com>; Mon, 7 Oct 2019 02:16:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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=JOysAsq5; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=gm9ZdJb0
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 zV1AiZcI8KSf for <netmod@ietfa.amsl.com>; Mon, 7 Oct 2019 02:16:34 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D9E412006F for <netmod@ietf.org>; Mon, 7 Oct 2019 02:16:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10022; q=dns/txt; s=iport; t=1570439794; x=1571649394; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ec7Po5HRcBzc0ZHwRMK8SF7gWIDDk6yFgRIIOBFmY9s=; b=JOysAsq5JAdWw7mSAYel/9er3TIIP807o54zXmOESliiPurTnGKMOzFG f323QqThR5z4FquNRH/nnb+L9imvh988a6Ipu7DpdC7IzaF0YNwBFlNam x9i/6QHwRy098sX+HuVU0DfBCQr3uF9f2pQvHhDJhAkaedShzZfaT/27A g=;
IronPort-PHdr: =?us-ascii?q?9a23=3AqmOmixPca/vGnw52bN4l6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEu60/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDFf4ETB?= =?us-ascii?q?oZkYMTlg0kDtSCDBjhM//ucys8NM9DT1RiuXq8NBsdFQ=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ApAAApAZtd/4QNJK1jAxoBAQEBAQI?= =?us-ascii?q?BAQEBDAIBAQEBgVYCAQEBAQsBgUokLANtViAECyoKhBmDRwOKSIJciWmOE4F?= =?us-ascii?q?CgRADVAkBAQEMAQEYCwoCAQGDe0UCF4JBIzcGDgIDCQEBBAEBAQIBBQRthS0?= =?us-ascii?q?MhUsBAQEDAQEBEBERDAEBLAsBCwICAgEGAg4CAQQBAQECAiYCAgIZBgYLFQg?= =?us-ascii?q?IAgQOBQgTB4MBgWoDDg8BAgyQR5BhAoE4iGF1gTKCfQEBBYFIQYMADQuCFwM?= =?us-ascii?q?GBYEHKAGMDRiBQD+BV4JMPoIaRwEBAgEBgSoBEgEhBRAKFwINgkYygiaJRIM?= =?us-ascii?q?xIIJYhVmXOUEKgiKHCYkyVoQimT+WTYINjwQCBAIEBQIOAQEFgWgjZ3FwFTu?= =?us-ascii?q?CbFAQFIFPDBeDUDOEYYU/dIEpjX6BIgGBIgEB?=
X-IronPort-AV: E=Sophos;i="5.67,267,1566864000"; d="scan'208";a="345591963"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 07 Oct 2019 09:16:33 +0000
Received: from XCH-ALN-015.cisco.com (xch-aln-015.cisco.com [173.36.7.25]) by alln-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id x979GXAt021577 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 7 Oct 2019 09:16:33 GMT
Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-ALN-015.cisco.com (173.36.7.25) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 7 Oct 2019 04:16:32 -0500
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 7 Oct 2019 04:16:31 -0500
Received: from NAM04-BN3-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 7 Oct 2019 04:16:31 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EAnE0u2kga2dsQi8KJ4VRa0HXfYxwXIhMhwOc1rWMtxzovqYD8YFnRx69Qn/ea+AFemIj1tPkrh0nuHYXJQeB4gCIqDdJt/8kFFOQX9ZR5aWyvNErMrU18qbd9aufBwXYZhYlZqoY8TkajGKN3UStr13TLpM6otJeyuZC/UYG28YWWtYtOIfYL0X1wW3WFNC+/8MZz8PCId1i9tQwgPWDe4+bqakcaeuq2hfJbIykR0b3VF0UG5nYkGhI0kWHdmuIugp+/l1Cxg01COP+DqjaBsBP6vnIuTodJPHM0Pmz3oX0BSwiXX0+OPv/Fr45U/0Fye8VCy1l7ZMPDBq5c7T0A==
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=ec7Po5HRcBzc0ZHwRMK8SF7gWIDDk6yFgRIIOBFmY9s=; b=LSj0K5INJb4/TcXSGDjRAqE91F31YW3RVV+SHFE3ZofQfBQVOu4r99AViWtKzMb3PYvJgXOwhR6mLGaZP4TDZBTLMYEB3QumgdUIFB5ta8LrxuUkZkwd3cplTtfhARMH0MMPUbqBuLix6mIHnWyOOG2B/ky9FvQR0kEg4DsYUS5tqvcCQVLeVMKqVyMVk2O2QcWbFEObnGOR6pwSh+SaqsAfCPLckyVWYwlTCrZ6CvFCtyR5q8SfPQ0uFVOEQIjbBr2RMpDCJvZFpdTnrEZYYSrO5DoMuzA7FV4V3OAXYNHcTyrBv5YqBruD0qFZgKLICq9j3LoCJRm5dwPqgYRqXw==
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=ec7Po5HRcBzc0ZHwRMK8SF7gWIDDk6yFgRIIOBFmY9s=; b=gm9ZdJb0TU9DWa2ROzdsFXfbePdm4xim3Y/p0SB9BwWtXdlDXssQPqId6+c/IAIT3G0D+t7Xqyu0ZAY7EO1l1derqh6r2eRRJzblzbf8Z1AfNkN+iYw/rx2RiRuxuODEDuNWVHN+RDQtqe3vfikL7gJNd7edUzsRPcwhxVjGK70=
Received: from MN2PR11MB4366.namprd11.prod.outlook.com (52.135.38.209) by MN2PR11MB3854.namprd11.prod.outlook.com (20.178.252.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2327.24; Mon, 7 Oct 2019 09:16:30 +0000
Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::cca:41bd:b0bb:c549]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::cca:41bd:b0bb:c549%2]) with mapi id 15.20.2327.023; Mon, 7 Oct 2019 09:16:30 +0000
From: "Rob Wilton (rwilton)" <rwilton@cisco.com>
To: Martin Bjorklund <mbj@tail-f.com>
CC: "J.Schoenwaelder@jacobs-university.de" <J.Schoenwaelder@jacobs-university.de>, "balazs.lengyel@ericsson.com" <balazs.lengyel@ericsson.com>, "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: [netmod] References to the "tags" typedef
Thread-Index: AdV5zjrR87+ocsTFRHuyDJWUSmakTQASvOqAAAKhPIAAGXctcAADYFqAAAA8Z0AAk0qXgAACQXew
Date: Mon, 7 Oct 2019 09:16:30 +0000
Message-ID: <MN2PR11MB436667917E2120C3936ADC81B59B0@MN2PR11MB4366.namprd11.prod.outlook.com>
References: <MN2PR11MB436662777568D8D4746FCED0B59E0@MN2PR11MB4366.namprd11.prod.outlook.com> <20191004093533.cvxscnkgr5y4gh2p@anna.jacobs.jacobs-university.de> <MN2PR11MB4366FEF4B3817E3605D29BBDB59E0@MN2PR11MB4366.namprd11.prod.outlook.com> <20191007.095943.1870966155557583692.mbj@tail-f.com>
In-Reply-To: <20191007.095943.1870966155557583692.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=rwilton@cisco.com;
x-originating-ip: [173.38.220.47]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 46d8c154-8494-45a6-ee6b-08d74b070a3e
x-ms-traffictypediagnostic: MN2PR11MB3854:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-prvs: <MN2PR11MB3854BA61AB9D0B86D77EE80BB59B0@MN2PR11MB3854.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 01834E39B7
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(39860400002)(346002)(366004)(396003)(376002)(199004)(189003)(43544003)(13464003)(51444003)(76116006)(229853002)(86362001)(11346002)(446003)(33656002)(6306002)(9686003)(55016002)(66446008)(64756008)(6436002)(486006)(476003)(66476007)(66556008)(2906002)(74316002)(7736002)(305945005)(3846002)(6116002)(6916009)(66946007)(99286004)(25786009)(76176011)(7696005)(6246003)(966005)(14454004)(8936002)(186003)(53546011)(6506007)(26005)(4326008)(478600001)(54906003)(316002)(66066001)(71190400001)(71200400001)(81156014)(81166006)(8676002)(102836004)(256004)(14444005)(66574012)(5660300002)(52536014); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3854; H:MN2PR11MB4366.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: 1F3CnWE71lCO9LAAdKAdZknOBYMb3aruJ+Q72kaVF9OwiXHd2idZ75XWbpTGjTUDyyNdFW4fZxdPdZvTbgJJBfepx1vtxu627sPs8je95FRtu/1r2ELr7COD1oRt5GhGhNFkM9e1DJnXfDnpWw6nAF8sYNuVUS2juJnlDll0se+xNnAyY1uFgZgzj7Jqq3HhYJ7205h2ojYdDKUhy672jiwBZAUl1loBfl5pAfvA9SGrKTqB8oM74JB0OANU2th4xmXK7RzbViffMtZAIL/k72a6E9v6kX3VhqFB/cQYIy38h8bM/9393cRRz2lV9FVKET9gbeI94znuOVv1eTcqNr1u5DBXfOe01cDdMoMbxrUJsNCo2R5SGn+9op1ArFb8Val8oRgJWHlzHKokV8EISGCkWlbkSUntBAZqW8Dv9BWQML5vnI0zT+aNFWX6cQxBtZWKOzuk4x8yo/u9xyvQHw==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 46d8c154-8494-45a6-ee6b-08d74b070a3e
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Oct 2019 09:16:30.4485 (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: /dPDn5WjiLnvgvFMw3mTQs+xPMJa0N6SIL3Ru23jiNenZJ5JB1b5mZ7t18CUelfMlWqB2zb7Bm/+XxrEBc28yQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3854
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.25, xch-aln-015.cisco.com
X-Outbound-Node: alln-core-10.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/TB5PC7qGdEbL0WKgYBCwfWkMrsg>
Subject: Re: [netmod] References to the "tags" typedef
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: Mon, 07 Oct 2019 09:16:37 -0000

Hi Martin,

> -----Original Message-----
> From: Martin Bjorklund <mbj@tail-f.com>;
> Sent: 07 October 2019 09:00
> To: Rob Wilton (rwilton) <rwilton@cisco.com>;
> Cc: J.Schoenwaelder@jacobs-university.de; balazs.lengyel@ericsson.com;
> netmod@ietf.org
> Subject: Re: [netmod] References to the "tags" typedef
> 
> "Rob Wilton (rwilton)" <rwilton@cisco.com>; wrote:
> > [Copying Balazs because this discussion is moving to instance-data
> > document schema definitions.]
> >
> > > -----Original Message-----
> > > From: Schönwälder, Jürgen <J.Schoenwaelder@jacobs-university.de>;
> > > Sent: 04 October 2019 10:36
> > > To: Rob Wilton (rwilton) <rwilton@cisco.com>;
> > > Cc: Christian Hopps <chopps@chopps.org>;; Mahesh Jethanandani
> > > <mjethanandani@gmail.com>;; netmod@ietf.org
> > > Subject: Re: [netmod] References to the "tags" typedef
> > >
> > > On Fri, Oct 04, 2019 at 08:17:33AM +0000, Rob Wilton (rwilton) wrote:
> > > >
> > > > To use the "tags:tag" typedef, ietf-yang-package had an import on
> > > > "ietf-
> > > module-tags" which both defines a tags type and also a "module-tags"
> > > container as well.  I want the typedef, but not the container,
> > > because I don't want the schema for the package file to be:
> > > >       +--ro yang-package  <-- I do want this
> > > >       |  +--ro name                      yang:yang-identifier
> > > >       |  ...
> > > >       +--ro module-tags   <--  I don't want this
> > > >          +- ...
> > > >
> > >
> > > Isn't import-only-module in YANG library take care of this?
> > [RW]
> > Yes, that is one solution.
> >
> > The instance data document (probably in JSON, but I've given an XML
> > snippet below) could use the "inline-spec" for specifying the schema.
> >
> > But this means that every package instance file, needs to have some
> > boilerplate like this before the actual package definition.:
> >
> > <?xml version="1.0" encoding="UTF-8"?> <instance-data-set xmlns=
> >     "urn:ietf:params:xml:ns:yang:ietf-yang-instance-data">
> >   <name>some-yang-package</name>
> >   <inline-spec>ietf-yang-library@2019-01-04.yang</inline-spec>;
> >   <inline-content-schema>
> >     <yang-library xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library">
> >       <module-set>
> >         <name>all</name>
> >         <module>
> >           <name>ietf-yang-package</name>
> >           <revision>2019-09-11</revision>
> >         </module>
> >         <import-only-module>
> >           <name>ietf-yang-package-types</name>
> >           <revision>xxxx-xx-xx</revision>
> >         </module>
> >         <import-only-module>
> >           <name>ietf-module-tags</name>
> >           <revision>xxxx-xx-xx</revision>
> >         </module>
> >         <import-only-module>
> >           <name>ietf-yang-revisions</name>
> >           <revision>xxxx-xx-xx</revision>
> >         </module>
> >         <module>
> >           <name>ietf-yang-structure-ext</name>
> >           <revision>xxxx-xx-xx</revision>
> >         </module>
> >         <module>
> >           <name>ietf-yang-types</name>
> >           <revision>xxxx-xx-xx</revision>
> >         </module>
> >         <module>
> >           <name>ietf-yang-library</name>
> >           <revision>xxxx-xx-xx</revision>
> >         </module>
> >         <module>
> >           <name>ietf-inet-types</name>
> >           <revision>xxxx-xx-xx</revision>
> >         </module>
> >       </module-set>
> >     </yang-library>
> >   </inline-content-schema>
> >   <content-data>
> >      // Actual package information goes here.
> >   </content-data>
> > </instance-data-set>
> >
> > https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-instance-file-
> > format/?include_text=1
> >
> > The YANG instance data draft provides some other choices:
> > (1) (External Method) Don't define the schema, just assume that
> > clients know what it will be for YANG packages.  E.g. it would be
> > specified in the YANG packages RFC.
> 
> I prefer this solution for the packages document.

The risk here, is that the package definition may get extended/augmented over time. 


> 
> > (2) (URI method) Put the schema in a separate instance data document
> > and reference that.  This could be defined in the YANG packages RFC,
> > but it might open the question of what URI can you use to retrieve it.
> > (3) Simplified inline schema.
> >
> > It is the third one that I would ideally like to use.
> 
> Ugh, I haven't paid enough attention to the instance data document... I
> will comment on this design in a separate email.

OK 😊

There is also a 4th choice here.

My plan is that the latest version of the packaging draft will augment the instance-data-set structure to allow a named package to be used as a specification for a schema.

So, package definitions could make use of this.  It would be still be concise, but complete and extensible.

> 
> > Here, the package data would like something like this (sorry, in JSON
> > this time):
> >
> >   "ietf-yang-instance-data:instance-data-set": {
> >     "name": "example-ietf-network-device-pkg",
> >     "module": [ "ietf-yang-package@2019-09-11.yang"; ],
> >     "description": "YANG package definition",
> >     "content-data": {
> >       "ietf-yang-package:yang-package": {
> >         "name": "example-ietf-network-device-pkg",
> >         // Actual package information goes here.
> >       }
> >     }
> >   }
> >
> > Here, the schema is defined by the "module" line
> > "ietf-yang-package@2019-09-11.yang";.  I think that there are some
> > details to work out, but I think that the import dependencies for
> > "ietf-yang-package.yang" could be automatically resolved as
> > import-only YANG modules.  I have also tried to minimize the required
> > imports (e.g. don't import YANG library, perhaps don't import from
> > module-tags).
> 
> You shouldn't have to do that.  You should use the appriopriate types.

The packages import against YANG library was only pulling in the "grouping location-leaf-list", so for YANG library, having the import doesn't seem to be that helpful.


> 
> > In terms of typedefs, are two typedefs equivalent if they have exactly
> > the same definition in two different modules?  Or does the fact that
> > they are named given them a slightly different meaning?
> 
> By reusing appriopriate typedefs you get clearer semantics.  In the
> extreme case everyting is just strings with some descripton statements
> (you might think that this is absurd, but this approach has been taken by
> some data model designers (not necessarily yang) ...)

Yes, I agree with you in principle, in that referencing the typedef provides more semantic information that just mirroring the type.

Thanks,
Rob


> 
> 
> /martin
> 
> >
> > Thanks,
> > Rob
> >
> >
> > >
> > > /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/>
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> >