Hi,

Lou Berger <lber...@labn.net> wrote:
> 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 ?

I don't agree that this is a rewrite of the solution.  I want to keep
the mountpoint statement.  I want to keep the two mechanisms inline
and use-schema.  The only change we're talking about is alinging the
read-only data that the server makes available with YLbis.  This is
quite trivial.  We have documented this in the pre09 branch, and this
is imo ready to be published.

> 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.

Yes.  I don't want to give up these compromises.  I know that others
want to, and/or explore other solutions.  That's *not* what I'm
proposing.


/martin



> 
> 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 <rwil...@cisco.com> 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
> >>> netmod@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/netmod
> >> _______________________________________________
> >> netmod mailing list
> >> netmod@ietf.org
> >> https://www.ietf.org/mailman/listinfo/netmod
> 
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to