On Thu, Nov 7, 2019 at 12:25 AM Martin Bjorklund <[email protected]> wrote:

> Andy Bierman <[email protected]> wrote:
> > On Wed, Nov 6, 2019 at 2:40 PM Balázs Lengyel <
> [email protected]>
> > wrote:
> >
> > > See below!    Balazs
> > >
> > >
> > >
> > > *From:* netmod <[email protected]> *On Behalf Of *Andy Bierman
> > > *Sent:* 2019. október 10., csütörtök 17:34
> > > *To:* Martin Bjorklund <[email protected]>
> > > *Cc:* NetMod WG <[email protected]>
> > > *Subject:* Re: [netmod] comments on
> > > draft-ietf-netmod-yang-instance-file-format-04
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Thu, Oct 10, 2019 at 5:06 AM Martin Bjorklund <[email protected]>
> wrote:
>
> [...]
>
> > >   o  Data node naming.
> > >
> > >     The current structure of the model is:
> > >
> > >         +--rw (content-schema-spec)?
> > >         |  +--:(simplified-inline)
> > >         |     +--rw module*                 string
> > >         |  +--:(inline)
> > >         |  |  +--rw inline-spec*            string
> > >         |  |  +--rw inline-content-schema   <anydata>
> > >         |  +--:(uri)
> > >         |     +--rw schema-uri?           inet:uri
> > >         ...
> > >         +--rw content-data?         <anydata>
> > >
> > >
> > >     To make the instance document more understandable, I suggest the
> > >     following structure, which adds a wrapping container for the
> > >     schema, and renames the inline and uri nodes:
> > >
> > >         +--rw content-schema
> > >            +--rw (content-schema-spec)?
> > >            |  +--:(simplified-inline)
> > >            |     +--rw module*                 string
> > >            |  +--:(inline)
> > >            |  |  +--rw inline-module*          string
> > >            |  |  +--rw inline-schema           <anydata>
> > >            |  +--:(uri)
> > >            |     +--rw same-schema-as-file?    inet:uri
> > >         ...
> > >         +--rw content-data?         <anydata>
> > >
> > >
> > >
> > > +1, except not in favor of so many ways to specify schema.
> > >
> > > That means the file reader MUST support all of them.
> > >
> > >
> > >
> > > BALAZS: All 3 formats have been explicitly requested by earlier
> > > commenters. I see a rational for each:
> > >
> > > Simplified-inline: it is simple and usually enough
> > >
> > > Inline: if you need to specify not just the modules but also the
> supported
> > > features and deviations you need this full format
> > >
> > > Uri: if you don’t really want to specify the content-schema in detail,
> > > e.g., because you are generating many files with the same schema, all
> you
> > > need is reference that identifies the content-schema
> > >
> > >
> > >
> > > Which one would you like to implementing? Maybe we could make the
> inline
> > > method optional with a feature (feature if-feature),
> > >
> > >
> > >
> >
> > I will just deviate out the stuff not worth implementing. ;-)
> > I prefer the schema-uri approach but simplified-inline is probably
> easiest
> > to implement.
> >
> > The schema-uri looks standard but the contents of the referenced YANG
> > instance file can be
> > anything (as opposed to a pre-defined YANG template like /yang-library)..
>
> Note that the name of this leaf is misleading (see my ealrier
> comments).  It is really 'same-schema-as-file', which means that it
> point to another YANG instance data file, which must specify its
> schema in one of the three ways.  Which may be another schema-uri, but
> in the end the recursion must stop and you must find a YANG instance
> data file that usses 'simplified-inline' or 'inline'.
>
>

OK -- much worse than I thought...


> > The inline-content-schema object looks broken because a YANG file is a
> text
> > string.
>
> It is supposed to be data nodes for /yang-library or perhaps
> /module-sets, or perhaps something else.  See the examples in section
> 3.2.
>
>

It seems strange that the details that don't matter at all (like the
filename) have lots
of rules that MUST be followed and the details that actually add standards
value are left unspecified.


>
> /martin
>
>

Andy


>
> > How does one use anydata to encode a text string? (It must be a container
> > of YANG data nodes).
> > Even the YIN representation is not a set of YANG data nodes, so anydata
> > encoding seems wrong.
> > Including all the YANG modules in this file seems especially heavyweight.
> > (I have no intention of supporting this mode.)
> >
> >
> >
> > > Andy
> > >
> >
> >
> > Andy
> >
> >
> > > _______________________________________________
> > > netmod mailing list
> > > [email protected]
> > > https://www.ietf.org/mailman/listinfo/netmod
> > >
>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to