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

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

Hi Martin,

> -----Original Message-----
> From: Martin Bjorklund <[e-mail]>
> Sent: 07 October 2019 09:00
> To: Rob Wilton (rwilton) <[e-mail]>
> Cc: [e-mail]; [e-mail];
> [e-mail]
> Subject: Re: [netmod] References to the "tags" typedef
> 
> "Rob Wilton (rwilton)" <[e-mail]> wrote:
> > [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.
> 
> I prefer this solution for the packages document.

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


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

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


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

Yes, I agree with you in principle, in that referencing the typedef provides more semantic information that just mirroring the type.

Thanks,
Rob


> 
> 
> /martin
> 
> >
> > Thanks,
> > Rob
> >
> >
> > >
> > > /js
> > >
> > > --
> > > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > > Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> > > Fax:   [phone]         <https://www.jacobs-university.de/>
> >
> > _______________________________________________
> > netmod mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/netmod
> >