Re: [netmod] [Netconf] Alternative YANG library structure for 7895bis

[Andy Bierman <[e-mail]>]

On Wed, Dec 13, 2017 at 6:55 AM, Robert Wilton <[e-mail]> wrote:

>
>
> On 11/12/2017 20:55, Andy Bierman wrote:
>
>
>
> On Mon, Dec 11, 2017 at 2:57 AM, Robert Wilton <[e-mail]> wrote:
>
>> Hi,
>>
>> On 08/12/2017 18:01, Andy Bierman wrote:
>>
>> Hi,
>>
>> A library per datastore sounds too complicated.
>> I prefer the proposal that was made at the IETF meeting that had
>> a 'not-implemented-in' leaf-list and a single module list.
>>
>> The use case that this particular design doesn't work particularly well
>> for is if you have a dynamic datastore that just contains a few modules
>> that are not supported via the conventional datastores.
>>
>> I think that there are future uses cases where the set of modules used
>> for a dynamic datastore could be really quite different and separate from
>> conventional configuration.  E.g. if dynamic subscribers were managed
>> through a dynamic configuration datastore rather than RADIUS.
>>
>>
>> Why is it interesting to have a separate module list for regular modules
>> and imported modules?
>>
>> Several reasons:
>> 1) It means that the list of implemented modules have a single key and
>> hence any references to an implemented module are cleaner/simpler.
>>
>
>
> IMO you are replacing universally meaningful keys  (module-name,
> revision-date) with an arbitrary name,
> It is not cleaner and not simpler for a client.
>
> No, for alternatives A and B, the list key is the module name itself, nor
> an arbitrary name.
> Alternative C uses an arbitrary name.
>
>
>
>
> 2) The model structure naturally more strictly enforces that only a single
>> revision/version of a module is implemented.  (E.g. it prevents a server
>> stating that two revisions of a module are both implemented).
>>
>
>
> How is that the case if the schema list includes its own module list?
> You mean there is a "unique" statement in the outer list that insures that
> a module/revision
> shows up at most once in all instances of the inner module list?
>
> For alt A, each schema represents a single list (so no duplicated
> implemented modules are possible).
>
> For alt B, yes, the rule is that there must be no duplicates in the
> module-sets that are combined into a single schema.
>
>
>

The alt-B approach that seems to be favored is not constrained, but even if
the server does conform
(and not have any overlaps between schema lists) this approach is rather
complicated in order
to answer the simple question "What datastores are supported for module
foo, revision A?"

If the previous design was used, a client could simply retrieve the module
entry and check
the 'not-implemented-in' leaf-list.  Now a client has to retrieve the
entire library, then analyze the
datastore lists (built from the schema entries for the datastore). The
client has to match
instances and look for module "foo" in multiple places.  The client then
assumes that
any missing entry means the module is not supported in that datastore
(assumes read access control
is never applied to the YANG library).

The corner case used as an excuse to redesign the library (ephemeral
datastore with a few modules in it)
is not very interesting, and also not expensive in terms of processing
complexity and bandwidth.
IMO the library should be optimized for conventional + operational, and
also be optimized for
the long-term, not a short-term transition period, biased for server
developers who want
to release partial implementations.


Andy



>
>
>> 3) I genuinely think that the list of implemented modules is more
>> interesting to the client than the imported, but not implemented modules.
>>
>
>
> The conformance leaf was good enough.
> Duplicating the module list and removing the conformance leaf is
> aggressively non-backward compatible.
>
>
>
>>
>> For a server, I would design it to "implement" one revision of every
>> module that it uses (including those that don't contain any data nodes,
>> RPCs, actions, notifications, or deviations), and then the "import-only"
>> list becomes the list of modules that the server implements to satisfy
>> "import-by-revision" and these are stated in the implemented schema anyway.
>>
>>
>> I prefer to keep the conformance leaf and not change the module list.
>>
>> NMDA needs to be possible to implement with a single schema tree such
>> that a module
>> is implemented in all datastores, or a subset of all datastores.
>> Otherwise it probably won't
>> get supported in clients.
>>
>> All solutions accommodate this requirement.
>>
>
>
> Seems to me all new solutions allow a server to violate the MUST in the
> NMDA draft that
> there is a superset of all modules.  A client has to look for every module
> in a server-specific
> set of named schema sets, and then reconcile all these sets.
> I still prefer the single module list with a conformance leaf and a
> leaf-list indicating
> the supported (or unsupported) datastores.
>
> So, this is a trade off between a more expressive model vs a more
> constrained model.
>
> It is worth noting that the existing YANG library (RFC 7895) allows
> servers to produce illegal module lists because they could implement
> multiple revisions of the same module.
>
> Thanks,
> Rob
>
>
>
>
>
>> For me, some of the interesting design questions have revolved around:
>> - is it better to reduce duplication in the list of modules reported at
>> the cost of increased model complexity?
>> - does the solution extend to schema mount?
>> - how well does the solution cope with with configuration datastores that
>> support very different sets of modules?
>>
>> To a lesser extent we have also been considering how well the solution
>> extends to packaging and semantic versioning, but I think that it is quite
>> tricky to know who these are going to pan out.  E.g. I think that the
>> restriction that a given schema will only implement a single revision of a
>> module will end up still holding, but I'm not sure that everyone has that
>> same view point.
>>
>> Thanks,
>> Rob
>>
>>
>>
>
> Andy
>
>
>>
>>
>> Andy
>>
>>
>>
>> On Fri, Dec 8, 2017 at 9:21 AM, Kent Watsen <[e-mail]> wrote:
>>
>>> CC-ing NETCONF, where the draft is being worked on.
>>>
>>> Kent
>>>
>>>
>>> On Fri, 2017-12-08 at 16:34 +0100, Juergen Schoenwaelder wrote:
>>> > On Fri, Dec 08, 2017 at 04:19:28PM +0100, Vladimir Vassilev wrote:
>>> > >
>>> > > Yes. The default value for yang-library-datastore leaf is
>>> ds:operational
>>> > > (the only possible one for the ds:operational datastore). This is
>>> backward
>>> > > compatible. If one needs different model for 'running', etc. then a
>>> new
>>> > > datastore identity has to be defined  and set in place of the
>>> default value.
>>> > > Then this identity can be used to read the yang-library data with
>>> > > <get-data>.
>>> > >
>>> >
>>> > Sorry, but I have to ask this: How do I obtain the schema for the
>>> > datastore (lets call it <running-library>) that reports the schema for
>>> > <running>? Is there another <running-library-library> datastore? Will
>>> > the recursion end? Perhaps it does since <running-library-library>
>>> > might have itself listed as the schema defining datastore. I guess
>>> > Lada will like these kind of meta and meta-meta datastores.
>>>
>>> Not really. Metadata needn't be in datastores.
>>>
>>> Lada
>>>
>>> >
>>> > /js
>>> >
>>> --
>>> Ladislav Lhotka
>>> Head, CZ.NIC Labs
>>> PGP Key ID: 0xB8F92B08A9F76C67
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> [e-mail]
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iet
>>> f.org_mailman_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh
>>> 0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTv
>>> jISlaJdcZo&m=5qj6BQUSwqYmkAVeKz5axFV8k3gxYEPSJ5Cp0RSnxrE&s=I
>>> 7fR1GY5lN2hVMkDuvryrhDeRypike3wPeFRrvQI5l8&e=
>>>
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/netmod
>>>
>>
>>
>>
>> _______________________________________________
>> Netconf mailing [e-mail]://www.ietf.org/mailman/listinfo/netconf
>>
>>
>>
>
>