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

[Andy Bierman <[e-mail]>]

On Fri, Oct 4, 2019 at 1:18 AM Rob Wilton (rwilton) <[e-mail]>
wrote:

> Hi Chris, Mahesh,
>
> > -----Original Message-----
> > From: Christian Hopps <[e-mail]>
> > Sent: 03 October 2019 20:50
> > To: Mahesh Jethanandani <[e-mail]>
> > Cc: Christian Hopps <[e-mail]>; Rob Wilton (rwilton)
> > <[e-mail]>; [e-mail]
> > Subject: Re: [netmod] References to the "tags" typedef
> >
> >
> >
> > > On Oct 3, 2019, at 2:34 PM, Mahesh Jethanandani
> > <[e-mail]> wrote:
> > >
> > >
> > >
> > >> On Oct 3, 2019, at 2:37 AM, Rob Wilton (rwilton) <[e-mail]>
> > 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 <[e-mail]> On Behalf Of Christian Hopps
> > >>> Sent: 25 September 2019 17:19
> > >>> To: [e-mail]
> > >>> 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, [e-mail] 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
> > >>>> [e-mail]
> > >>>> https://www.ietf.org/mailman/listinfo/netmod
> > >>>>
> > >>
> > >> _______________________________________________
> > >> netmod mailing list
> > >> [e-mail]
> > >> https://www.ietf.org/mailman/listinfo/netmod
> > >
> > > Mahesh Jethanandani
> > > [e-mail]
>
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
>