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

["Rob Wilton (rwilton)" <[e-mail]>]

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

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


> 
> /js
> 
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <https://www.jacobs-university.de/>