On 1/17/2018 1:59 AM, Ladislav Lhotka wrote:
...
I think
it is incumbent upon those revisiting past/closed WG decisions (in
this case, inline schema being represented by YL) to argue why the
decision needs to be revisited.
I'm repeating my self: b/c the current solution doesn't work well with
the NMDA.
I simply don't understand how YL-bis works at the root node but
doesn't work equally at an inline mount point. Can you elaborate?
With NMDA, a server may have one schema for the config datastore and
another one for operational (one is a superset of the other). A
mounted YL can only be present in operational. Thus, there's no way a
client can learn the schema for config.
If the LNE mounted the full YL-bis at the mount point then you would
have the list of datastores, and the schema associated with each
datastore. Of course, this would only be available in operational, but
that is the same as a regular server support YL-bis.
YL-bis is different in that it is in fact metadata even though we call it state
data.
I couldn't agree more. YL and SM are server metadata and are
independent of any DS. They could be accessed via any (as others have
suggested), but we are currently choosing to access if via operational
state. With NMDA, I think personally think server meta data should have
it's own DS. This discussion has convinced me that the current proposed
alternative, of accessing as operational data is flawed and even access
via *any* DS is preferable.
In any case, no matter what datastores the server has, YL-bis is the
single well-known location from which the schema of all datastores can be
retrieved.
That's a nice idea, but as was discussed in december, the direction
being taken doesn't include SM so this statement isn't *currently* true.
We could refer to <operational> as the place from which the mounted schemas of
NMDA-standard config datastores can be retrieved (except for special cases, one
is discussed below). But if there is another config datastore (e.g. dynamic)
with an inline mount point instance, it is unclear where to look for the mounted
schema.
Why? Is it unclear where to look for YL-bis in this case? Why is SM
any different than YL?
With my proposal, the mount point instance will be annotated with
@schema-ref that points to a schema in the top-level YL.
right and as we thrashed out the last time we had discussed this with
the whole WG, having inline schema available at the top level was not
the preferred solution.
I thought that the problem with the current solution and NMDA, was that
there is no way to find out what the LNE schema is if the LNE isn't
booted, and hence isn't providing <operational>. But I'm not sure what
issues that actually causes. E.g. does it cause issues with
pre-configuration of the LNE?
The issue that this causes is that the schema for the pre-configured LNE isn't
known and validity of <intended> is unclear.
Please elaborate on what you see here as a problem. Those working on
LNE's (including myself) don't see an issue here.
Lou
Lada
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
