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

[Ladislav Lhotka <[e-mail]>]

Hi Rob,

Robert Wilton <[e-mail]> writes:

> Hi Chris,
>
> I've got no desire or intent to try and slow down the NI and LNE drafts, 
> or any that depend on them.  I actually agree that this is critically 
> important that IETF gets modules standardized/finished so that everyone 
> can use them.
>
> However, ...
>
> YLbis has quite a different structure to YL.  The main part of this 
> change was to support NMDA, the other part of this change was to better 
> support things like SM, or YANG packages.
>
> I don't think that there is a clean, backwards compatible, way to go 
> from the YANG module in SM -08 to one that is going to work well with 
> YLbis and other YLbis extensions/augmentations that seem to be coming

I don't think this is true - all YANG modules that work with -08 should
work with pre-09.

> down the line.  Given what we know now, I believe that the correct 
> medium/long term structure for the SM YANG module, taking YLbis into 
> account, is the one proposed in pre09, because it directly augments the 
> YLbis structure, and hence any future augmentations to YLbis should 
> automatically extend to SM mounted schema as well.
>
> I think that the likely future technical issues with the -08 module will be:
> - supporting NMDA in a clean consistent way
> - adding in support for SemVer
> - additional capability reporting as an augmentation to YANG library
>
> So, if -08 proceeds as is, then it seems to me like one of three things 
> will need to happen:
> 1) Their will need to be a non backwards compatible update to the SM 
> model that is the same/similar to pre09.
> 2) YLbis and SM diverge, stuff that augments YLbis doesn't work for 
> explicitly mounted schema.

An acceptable compromise for me would be to publish -08 and accept both
1 and 2 above. The benefits of doing so would be

- LNE/NI work won't be blocked

- some experience may be gained from the implementers that can improve
  the ultimate YLbis-based solution

- there will be more time to reconsider the design and presentation of
  the two concepts (inline and use-schema).

> 3) We accrue technical debt, implementations need to support two YL 
> module structures, the one in SM and the one in YLbis, and future 
> extensions need to augment both the SM structure and YLbis structure.

If we eventually do the right thing, then SM in the -08 form will be
abandoned along with the old YL.

Lada

>
> I don't like the idea of (2) or (3), but I don't know if others will 
> find (1) acceptable.
>
> But I do agree that we are just going round in circles on this:
> - Using the pre09 structure is not acceptable to some folks
> - Publishing a draft with both -08 and pre09 structure is liked by even 
> less folks.
>
> Perhaps publishing -08 is the only option.  My hope is that the WG will 
> support somebody subsequently doing solution (1), otherwise it seems 
> like a missed opportunity to get this right.
>
> Thanks,
> Rob
>
>
> On 24/02/2018 13:54, Christian Hopps wrote:
>> My position,
>>
>> It may be the case that there's even a better cleaner solution; 
>> however, it's simply too late for major modifications to this work 
>> that don't actually address functional failures.  The draft as 
>> proposed works for the people who need to get work done.
>>
>> We have multiple pending RFCs - MISREF on this document. These RFCs 
>> would have to be pulled from the RFC EDITOR queue, and reworked to be 
>> compliant again, and this very well could lead to discovering issues 
>> with your new proposal. Any new issues discovered in either the 
>> pending RFCs *or* in the new solution would then need to be worked out 
>> and fixed. Please recall that this actually occurred on the first 
>> round (i.e., doing the examples led to discovering problems with the 
>> drafts), so it's not unreasonable at all to assume this would happen 
>> again.
>>
>> Look this just isn't a simple change your proposing. It involves a 
>> large upheaval, killing the pending RFC status on multiple documents 
>> that the industry is waiting on. Please see this.
>>
>> Thanks,
>> Chris.
>>
>>
>> Martin Bjorklund <[e-mail]> writes:
>>
>>> 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
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/netmod
>>
>> .
>>
>
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67