Re: [netmod] Proposal for minimalist full NMDA support in schema mount

[Lou Berger <[e-mail]>]

Martin/Rob,

     Back when the topic was raised for the first time publicly 
(Yokahama) and discussed in the WG [1] *any* solution would have been 
workable.  At this point > 2 years later, do you really think it is 
reasonable to do a rewrite of the solution ?  Are you really not willing 
to live with a compromise that addresses the issue albeit in way that 
you/some view as suboptimal?

Keep in mind that we had lots of discussions on what is 
optimal/preferred and there are/were different view points on this, 
compromises were made that increased complexity for others and these 
were accepted in interest of progressing *any* deployable solution.

Lou

[1] 
https://datatracker.ietf.org/meeting/interim-2016-netmod-01/session/netmod

On 2/23/2018 4:36 AM, Martin Bjorklund wrote:
> Hi,
>
> Robert Wilton <[e-mail]> wrote:
>> Hi Lou,
>>
>> I think that this solution is inferior to the model presented in
>> pre-09.
> I agree.  Servers that are NMDA-compliant, or implements YANG Library
> bis will have to present schemas in two different structures,
> depending on where the schema is used, and clients will have to code
> for both.  With the solution in pre-09, there is just one structure.
> A single structure also has other benefits (apart from being simpler),
> e.g., if we augment it with the meta data that has been discussed
> recently, we can augment a single structure.
>
>
> /martin
>
>
>
>> I would prefer that we publish pre09 instead, potentially including
>> the -08 model in the appendix if that helps progress the document in a
>> more expedient fashion.
>>
>> Thanks,
>> Rob
>>
>>
>> On 22/02/2018 16:18, Lou Berger wrote:
>>> Hi,
>>>
>>> (I have a bunch of different roles WRT this work.  This mail is being
>>> sent as an individual - as chair, I fully support the previous chair
>>> statements on this draft.)
>>>
>>> Chris and I have come up with a proposal on how to provide full NMDA
>>> as part the existing schema-mount module.  Our motivation was to
>>> enable full NMDA support with *minimal* change to the model and
>>> disruption to the LC'ed work.  The key NMDA limitation, with -08, that
>>> we are aiming to address is the ability to support different mounted
>>> schema in different datastores for non-inline mount points. (See more
>>> detailed description below if interested full nuances of limitations
>>> of -08)
>>>
>>> What we came up with was  to simply add a (leaf)list to identify in
>>> which datastores a
>>> schema-mount schema is valid/present. This is somewhat similar to
>>> YL-bis schema/module-set. Specifically we're proposing (see below for
>>> full tree below):
>>>
>>>             +--ro schema* [name]
>>>                +--ro name           string
>>> ADD          +--ro datastore*    ds:datastore-ref {revised-datastores}
>>>
>>> This approach has the advantages of supporting different mounted
>>> schema in different DSes, working with both NMDA and non-NMDA
>>> implementations, supporting all of the extensively discussed features
>>> of schema mount (including recursive mounts), and having minor/scoped
>>> impact on all dependent work.  The main downside is that it isn't the
>>> most optimal/compact solution possible if we were to base this work on
>>> YL-bis/pre09 draft.  Of course -08 isn't necessarily optimal from all
>>> perspectives, but it is what was agreed to as sufficient by those who
>>> contribute to the WG discussion.
>>>
>>> In short, we see this as a solution to  addresses the raised last call
>>> issue with the minimal impact on -08 and dependent work -- which is
>>> what is appropriate given where we are in the process.
>>>
>>> So our/my question really is:
>>>
>>>      Is this a solution that you/all can live with?
>>>
>>> Note: optimization, design preference and perfect alignment with use
>>> or YL-bis are not part of our question as we both don't think that is
>>> the right question given where we are in the WG process.
>>>
>>> Lou (with ideas developed with Chris, and chair hat off)
>>>
>>> ======
>>> Details -- for those who want
>>> ======
>>> As background, my understanding/view is that the -08 version of the
>>> both NMDA and non-NMDA supporting implementations, but there are
>>> limitations in its NMDA applicability. Used with Yang Library,
>>> [rfc7895], only non-NMDA implementations can be supported.  When used
>>> with the revised Yang Library defined in
>>> [I.D.ietf-netconf-rfc7895bis-],  NMDA implementations  can be
>>> supported with certain limitations. Specifically, this document
>>> requires use of the now deprecated module-list grouping, and the same
>>> schema represented in schema list of the Schema Mount module MUST be
>>> used in all datastores.  Inline type mount points, which don't use the
>>> schema list,  can support different schema in different data stores
>>> not by instantiating the [I.D.ietf-netconf-rfc7895bis-] version of
>>> YANG library under the inline mount point.
>>>
>>>      module: ietf-yang-schema-mount
>>>          +--ro schema-mounts
>>>             +--ro namespace* [prefix]
>>>             |  +--ro prefix    yang:yang-identifier
>>>             |  +--ro uri?      inet:uri
>>>             +--ro mount-point* [module name]
>>>             |  +--ro module        yang:yang-identifier
>>>             |  +--ro name          yang:yang-identifier
>>>             |  +--ro config?       boolean
>>>             |  +--ro (schema-ref)?
>>>             |     +--:(inline)
>>>             |     |  +--ro inline?       empty
>>>             |     +--:(use-schema)
>>>             |        +--ro use-schema* [name]
>>>             |           +--ro name
>>>             |           |       -> /schema-mounts/schema/name
>>>             |           +--ro parent-reference*   yang:xpath1.0
>>>             +--ro schema* [name]
>>>                +--ro name           string
>>> ADD          +--ro datastore*    ds:datastore-ref {revised-datastores}
>>>                +--ro module* [name revision]
>>>                |  +--ro name                yang:yang-identifier
>>>                |  +--ro revision            union
>>>                |  +--ro schema?             inet:uri
>>>                |  +--ro namespace           inet:uri
>>>                |  +--ro feature*            yang:yang-identifier
>>>                |  +--ro deviation* [name revision]
>>>                |  |  +--ro name        yang:yang-identifier
>>>                |  |  +--ro revision    union
>>>                |  +--ro conformance-type    enumeration
>>>                |  +--ro submodule* [name revision]
>>>                |     +--ro name        yang:yang-identifier
>>>                |     +--ro revision    union
>>>                |     +--ro schema?     inet:uri
>>>                +--ro mount-point* [module name]
>>>                   +--ro module        yang:yang-identifier
>>>                   +--ro name          yang:yang-identifier
>>>                   +--ro config?       boolean
>>>                   +--ro (schema-ref)?
>>>                      +--:(inline)
>>>                      |  +--ro inline?       empty
>>>                      +--:(use-schema)
>>>                         +--ro use-schema* [name]
>>>                            +--ro name
>>>                            |       -> /schema-mounts/schema/name
>>>                            +--ro parent-reference*   yang:xpath1.0
>>>
>>> We would expect that the revised-datastores feature would be used
>>> (perhaps required) for any implementation that supports
>>> ietf-datastores
>>> and yl-bis.
>>>
>>>
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/netmod
>> _______________________________________________
>> netmod mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netmod