Re: [netmod] js review of draft-ietf-netmod-schema-mount-09

[Martin Bjorklund <[e-mail]>]

Juergen Schoenwaelder <[e-mail]> wrote:
> On Tue, Apr 10, 2018 at 10:58:00PM +0200, Martin Bjorklund wrote:
> > Juergen Schoenwaelder <[e-mail]> wrote:
> > > On Tue, Apr 10, 2018 at 04:15:46PM +0200, Martin Bjorklund wrote:
> > > > > 
> > > > > Yes, the checksum (which I think is actually a version identifier).
> > > > > Anyway, the question is whether a client can draw any conclusions from
> > > > > seeing YANG library instances with the same checksum and whether a
> > > > > client must simpy treat this as a clash. If multiple mounted schemas
> > > > > have the same YANG library, then reading one of them would be
> > > > > sufficient. The question is whether the checksum is a tool for
> > > > > deciding whether a YANG library is similar to an already known one or
> > > > > whether a client must not make this assumption, i.e., a checksum is
> > > > > always scoped to the YANG library instance and you have to read them
> > > > > all.
> > > > 
> > > > Options:
> > > > 
> > > > 1.  Be silent about the YL checksum in this document.
> > > > 
> > > > 2.  State that the server MUST ensure that if two mounted YL
> > > >     instances have the same checksum, then the YL contents MUST be
> > > >     the same.
> > > > 
> > > > 3.  State that just b/c the YL checksum is the same in two mounted
> > > >     instances, it does not mean that the YL contents is the same.
> > > > 
> > > > 4.  State that for use-schema, the YL contents and YL checksum MUST be
> > > >     the samem but for inline, equal YL checksum is no guarantee for
> > > >     equal YL contents.
> > > > 
> > > > From a client perspective, 2 is preferrable.  It is probably not
> > > > difficult to implement on a server either; except in the peer mount
> > > > case where the data is just read from some device.
> > > 
> > > The more I think about it, it seems option 4. is the right thing to
> > > do.
> > 
> > Ok.  How about adding two sentences at the end of the last paragraph
> > in section 3.3, giving: 
> > 
> >   The mounted schema is determined at run time: every instance of the
> >   mount point that exists in the operational state MUST contain a copy
> >   of YANG library data that defines the mounted schema exactly as for
> >   a top-level schema. A client is expected to retrieve this data from
> >   the instance tree, possibly after creating the mount point.  In the
> >   "inline" case, instances of the same mount point MAY use different
> >   mounted schemas, whereas in the "shared-schema" case, all instances
> >   MUST use the same mounted schema.  In the "inline" case, if two
> >   instances have the same YANG library checksum it is not guaranteed
> >   that the YANG library contents are equal for these instances.
> 
> This text says "A client is expected to retrieve this data from the
> instance tree, possibly after creating the mount point.", which seems
> a bit odd. How does a client create a mount point? First, a mount
> point is created by defining it in a YANG module, so this is
> specification time not runtime. Perhaps you mean 'instantiated' rather
> than 'created' but even then it is somewhat unclear how a client does
> that in general. Perhaps simple drop ', possibly after creating the
> mount point'.

Ok, I will do that.


/martin