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

[Christian Hopps <[e-mail]>]

> On Oct 4, 2019, at 4:17 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".

If there's a problem here it doesn't seem to be with module tags, but more generically with this "pulling in" issue you have with instance data documents. Are we now going to require *all* YANG types be defined in their own modules so their re-use in instance data documents doesn't "pull in" the other stuff? Are we going to go back and revise and republish all current YANG modules splitting them up this way?

Thanks,
Chris.



> 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 ...
> 
> Thanks,
> Rob
> 
> 
>> 
>> 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]