Martin,
On 2/23/2018 7:55 AM, Martin Bjorklund wrote:
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.
The requirement to use YL-bis is enough for me classifying the change as
a rewrite. The current draft is usable with both RFC7895 and YL-bis.
This is a pretty major change, particularly for anyone working on a
client or server implementation now, or who wants to soon.
This is
quite trivial.
From *your* perspective. There are other's that disagree (See Dean's
and Chris' mail - they don't want *any* changes and are perfectly happy
with -08).
We have documented this in the pre09 branch, and this
is imo ready to be published.
It would still need to go through normal working processing which would,
hopefully, garner some review from some/any of the users or operator who
contributed to the development of -08. For example, in PRE09 I see
some complexities in how mount points with different schema in different
DS works that seem unnecessary, also the recursive case is not
documented - even if I'm wrong and all that is needed is better
understanding (by me) or clarification (in the doc), it still would
need to addressed as part of normal WG processing.
Lou
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
