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

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Thu, 3 Oct 2019 09:37:57 +0000

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.

(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-masked]> On Behalf Of Christian Hopps
> Sent: 25 September 2019 17:19
> To: [email-masked]
> 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-masked] 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-masked]
> > https://www.ietf.org/mailman/listinfo/netmod
> >

---

From: Mahesh Jethanandani <[email-masked]>
Date: Thu, 3 Oct 2019 11:34:25 -0700

> On Oct 3, 2019, at 2:37 AM, Rob Wilton (rwilton) <[email-masked]> wrote:
> 
> Hi Chris,
> 

I know it is late. But what will it take to split the tags-types module from the tags module?

>>> ftp://ftp.ietf.org/internet-drafts/

Mahesh Jethanandani
[email-masked]

---

From: Christian Hopps <[email-masked]>
Date: Thu, 3 Oct 2019 15:49:43 -0400

> On Oct 3, 2019, at 2:34 PM, Mahesh Jethanandani <[email-masked]> wrote:
> 
> 
> 

I do not understand why this is important at all. What does "pulls in" exactly mean?

Thanks,
Chris.

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Fri, 4 Oct 2019 08:17:33 +0000

Hi Chris, Mahesh,

> From: Christian Hopps <[email-masked]>
> Sent: 03 October 2019 20:50
> To: Mahesh Jethanandani <[email-masked]>
> Cc: Christian Hopps <[email-masked]>; Rob Wilton (rwilton)
> <[email-masked]>; [email-masked]
> Subject: Re: [netmod] References to the "tags" typedef
> 
> 
> 
> >> 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.
> >> 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.
> >>
> >> (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.
> >

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 ...

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
> >>
> >>
> >>
> >>>> 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.
> >>>>
> >>>>

---

From: Andy Bierman <[email-masked]>
Date: Fri, 4 Oct 2019 01:48:55 -0700

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

> 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:
> 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".
> 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.

> Rob
Andy

---

From: Christian Hopps <[email-masked]>
Date: Fri, 4 Oct 2019 05:18:22 -0400

> On Oct 4, 2019, at 4:17 AM, Rob Wilton (rwilton) <[email-masked]> wrote:
> 
> Hi Chris, Mahesh,
> 

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.

---

From: Schönwälder, Jürgen <[email-masked]>
Date: Fri, 4 Oct 2019 09:35:35 +0000

>       +--ro module-tags   <--  I don't want this

Isn't import-only-module in YANG library take care of this?

/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/>

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Fri, 4 Oct 2019 10:04:56 +0000

[Copying Balazs because this discussion is moving to instance-data document schema definitions.]

> From: Schönwälder, Jürgen <[email-masked]>
> Sent: 04 October 2019 10:36
> To: Rob Wilton (rwilton) <[email-masked]>
> Cc: Christian Hopps <[email-masked]>; Mahesh Jethanandani
> <[email-masked]>; [email-masked]
> > 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"
[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>[email-masked]</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.
(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.

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": [ "[email-masked]" ],
    "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 "[email-masked]".  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).

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?

Thanks,
Rob

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Fri, 4 Oct 2019 10:28:43 +0000

> Sent: 04 October 2019 10:18

[RW] snipped.
> > 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.
> 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.
[RW] 
I agree that this is a generic issue.

 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?
[RW] 
I don't know.

I don't particularly like the "implemented" vs "import-only" behaviour in YANG.  This is partly because the information about whether a module needs to be implemented, or is an "import only" dependency isn't contained within YANG import statement.  Partly this is because to use identities the server must implement the module.  Partly this is because it is possible to "import-only" multiple revisions of a YANG module (which sort of seems strange, and perhaps also an unwanted complexity).

I also know that when OpenConfig were trying to reuse some of the IETF definitions they got stuck.
They wanted to use "iana-if-types.yang", but that has an import dependency on "ietf-interfaces.yang" which they didn't really want, but needed to import the "if:interface-type" base identity, which probably then requires that "ietf-interfaces.yang" is implemented.  Possibly the "interface-type" identity shouldn't have been defined in "ietf-interfaes.yang" at all.  Maybe it should have been part of "iana-if-types.yang" or perhaps a separate "ietf-interfaces-types.yang", or maybe the tight dependency is fine.
 
Hence, I'm not convinced that mixing type definitions and data node definitions in the same module is necessarily a good idea.  I'm not proposing that we go back and change what we have already done, but I'm also not convinced that the YANG modularity is really working as well as one might hope.

Thanks,
Rob

> > 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.
> >>
> >>>
> >>>>
> >> 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.
> >>>>
> >> approach at this time, but wanted to check whether you or the WG had
> >> an opinion.
> >>>>
> >>>> Thanks,
> >>>> Rob
> >>>>
> >>>>
> >>>>
> >>>>>> dynamically defined and set by users.  This document also
> >>>>>> provides guidance to future model writers; as such, this document
> >>>>>> updates
> >> RFC8407.
> >>>>>>
> >>>>>>
> >>>>>> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-module-ta
> >>>>>> gs
> >>>>>> -09
> >>>>>>

---

From: Schönwälder, Jürgen <[email-masked]>
Date: Fri, 4 Oct 2019 11:50:59 +0000

> Here, the schema is defined by the "module" line "[email-masked]".  I think that there are some details to work out, but I think that the import dependencies for "ietf-yang-package.yang" could be a…

The import vs. implement distinction is today in the schema. If people
invent other ways to express schemas, then they will likely have to
find a way to express that distinction. Right now, there is no rule
that says import only definitions must be in separate modules. (In
fact, in several cases, you will only learn over time what people
import only.)

> 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?

Two typedefs foo:t1 and bar:t2 may be semantically the same but they
also remain to be two different definitions. Equivalence of typedefs
may mean two different things, depending on the context (or the kind
of equivalence you care about in a certain context).

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 07 Oct 2019 09:59:43 +0200 (CEST)

"Rob Wilton (rwilton)" <[email-masked]> wrote:
> > > "ietf-
> 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.:
> 
> (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.

> (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.

Ugh, I haven't paid enough attention to the instance data
document... I will comment on this design in a separate email.

> Here, the schema is defined by the "module" line
> "[email-masked]".  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.

> 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) ...)

/martin

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Mon, 7 Oct 2019 09:16:30 +0000

Hi Martin,

> From: Martin Bjorklund <[email-masked]>
> Sent: 07 October 2019 09:00
> Cc: [email-masked]; [email-masked];
> [email-masked]
> > > container as well.  I want the typedef, but not the container,
> > > because I don't want the schema for the package file to be:
> > <?xml version="1.0" encoding="UTF-8"?> <instance-data-set xmlns=

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

> 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.

> 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.

> (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