On Fri, Oct 4, 2019 at 1:18 AM Rob Wilton (rwilton) <[email protected]> wrote:
> Hi Chris, Mahesh, > > > -----Original Message----- > > From: Christian Hopps <[email protected]> > > Sent: 03 October 2019 20:50 > > To: Mahesh Jethanandani <[email protected]> > > Cc: Christian Hopps <[email protected]>; Rob Wilton (rwilton) > > <[email protected]>; [email protected] > > Subject: Re: [netmod] References to the "tags" typedef > > > > > > > > > On Oct 3, 2019, at 2:34 PM, Mahesh Jethanandani > > <[email protected]> wrote: > > > > > > > > > > > >> On Oct 3, 2019, at 2:37 AM, Rob Wilton (rwilton) <[email protected]> > > wrote: > > >> > > >> Hi Chris, > > >> > > >> I know that this is late, but ... > > >> > > >> The YANG packages draft (https://tools.ietf.org/html/draft-rwilton- > > netmod-yang-packages-01, but an updated version will be posted soon), is > > currently using the module-tags typedef to allow a package definition to > > contain a list of tags. > > >> > > >> E.g. > > >> module: ietf-yang-package > > >> +--ro yang-package > > >> +--ro name yang:yang-identifier > > >> +--ro version yang-sem-ver > > >> +--ro revision-date? yanglib:revision-identifier > > >> +--ro location* inet:uri > > >> +--ro description? string > > >> +--ro reference? string > > >> +--ro previous-version? yang-sem-ver > > >> +--ro tag* tags:tag > > >> +--ro referentially-complete? Boolean > > >> ... > > >> > > >> This package definition goes into an instance data document, for which > > the schema should just be ietf-yang-package, but by it importing ietf- > > module-tags.yang, it effectively also pulls in the "container > module-tags" > > into the schema for the package definition, that I don't think should be > > there. > > >> > > >> If we keep package tags, then I think that there are two ways to fix > > this: > > >> > > >> (1) Split ietf-module-tags into an ietf-module-tags-types.yang and a > > ietf-module-tags.yang. But it would be very late to do this, and the > > packages draft isn't even a workgroup document at this stage. > > > > > > I know it is late. But what will it take to split the tags-types module > > from the tags module? > > > > I do not understand why this is important at all. What does "pulls in" > > exactly mean? > > To put YANG instance data into a document you need to know what the schema > is associated with the instance data. > > Ideally, I want the schema for a YANG package instance data document to > just be the ro yang-package structure described above (actually now defined > using YANG data extension from draft-ietf-netmod-yang-data-ext). > > 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 > +- ... > > There are a few solutions: > > 1) Split ietf-module-tags into a ietf-module-tags-types.yang that only > defines the typedef and the extension, and hence the ietf-module-tags.yang > only defines the module-tags container, and ietf-yang-packages.yang can > just import ietf-module-tags-types.yang > 2) Have ietf-yang-package.yang define its own "tags" type, hence there is > no dependency on "ietf-module-tags.yang" at all. > 3) Tweak the schema specification for simplified-inline-schema in > instance-data documents so that the use of ietf-module-tags.yang module > effectively becomes "import-only" rather than "implemented". > 4) Don't worry about the fact that the file schema for a YANG package > contains more than it should. > > I strongly dislike (4) as an option. > But I think that probably either (2) or (3) would be OK as a solution. > > Hence, it is probably not necessarily to split ietf-module-tags.yang into > two files, because there are other solutions available. It isn't even > clear to me that (1) is necessarily the best solution anyway ... > > I think this is just an implementation detail. There is no problem using just a typedef from a an imported module. It does not cause any data nodes to be part of the importing module. > Thanks, > Rob > > > Andy > > > > Thanks, > > Chris. > > > > > > > >> > > >> (2) Have the package draft define its own "package tag" typedef, and > > not have an import reference on module-tags at all. Probably if we do > > keep package tags, then we should also consider a mechanism by which they > > can be updated on a device equivalently to module tags. > > >> > > >> I'm currently thinking that the second choice might be a better > > approach at this time, but wanted to check whether you or the WG had an > > opinion. > > >> > > >> Thanks, > > >> Rob > > >> > > >> > > >> > > >>> -----Original Message----- > > >>> From: netmod <[email protected]> On Behalf Of Christian Hopps > > >>> Sent: 25 September 2019 17:19 > > >>> To: [email protected] > > >>> Subject: Re: [netmod] I-D Action: > > >>> draft-ietf-netmod-module-tags-09.txt > > >>> > > >>> This adds the deprecated non-NMDA state module. > > >>> > > >>> Thanks, > > >>> Chris. > > >>> > > >>>> On Sep 25, 2019, at 12:15 PM, [email protected] wrote: > > >>>> > > >>>> > > >>>> A New Internet-Draft is available from the on-line Internet-Drafts > > >>> directories. > > >>>> This draft is a work item of the Network Modeling WG of the IETF. > > >>>> > > >>>> Title : YANG Module Tags > > >>>> Authors : Christian Hopps > > >>>> Lou Berger > > >>>> Dean Bogdanovic > > >>>> Filename : draft-ietf-netmod-module-tags-09.txt > > >>>> Pages : 18 > > >>>> Date : 2019-09-25 > > >>>> > > >>>> Abstract: > > >>>> This document provides for the association of tags with YANG > modules. > > >>>> The expectation is for such tags to be used to help classify and > > >>>> organize modules. A method for defining, reading and writing a > > >>>> modules tags is provided. Tags may be registered and assigned > > >>>> during module definition; assigned by implementations; or > > >>>> dynamically defined and set by users. This document also provides > > >>>> guidance to future model writers; as such, this document updates > > RFC8407. > > >>>> > > >>>> > > >>>> The IETF datatracker status page for this draft is: > > >>>> https://datatracker.ietf.org/doc/draft-ietf-netmod-module-tags/ > > >>>> > > >>>> There are also htmlized versions available at: > > >>>> https://tools.ietf.org/html/draft-ietf-netmod-module-tags-09 > > >>>> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-module-tags > > >>>> -09 > > >>>> > > >>>> A diff from the previous version is available at: > > >>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-module-tags-09 > > >>>> > > >>>> > > >>>> Please note that it may take a couple of minutes from the time of > > >>>> submission until the htmlized version and diff are available at > > >>> tools.ietf.org. > > >>>> > > >>>> Internet-Drafts are also available by anonymous FTP at: > > >>>> ftp://ftp.ietf.org/internet-drafts/ > > >>>> > > >>>> _______________________________________________ > > >>>> netmod mailing list > > >>>> [email protected] > > >>>> https://www.ietf.org/mailman/listinfo/netmod > > >>>> > > >> > > >> _______________________________________________ > > >> netmod mailing list > > >> [email protected] > > >> https://www.ietf.org/mailman/listinfo/netmod > > > > > > Mahesh Jethanandani > > > [email protected] > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
