On 1/16/2018 8:50 AM, Martin Bjorklund wrote:
Lou Berger <lber...@labn.net> wrote:
On January 16, 2018 8:24:42 AM Martin Bjorklund <m...@tail-f.com>
wrote:
Lou Berger <lber...@labn.net> wrote:
Lada,
On January 16, 2018 7:07:15 AM Ladislav Lhotka <lho...@nic.cz> wrote:
On Tue, 2018-01-16 at 06:30 -0500, Lou Berger wrote:
Lada,
It sounds like you are proposing in (1) a fairly significant change in
the
direction of the draft and in (2) a basic approach that has been
It is no change in direction, just a simplification of the
schema-describing
state data. Given the recent developments in 7895bis it makes no sense
to me to
have two "schema" lists if we can have just one.
Managing transition is hard. It's also highlights why Yang Library
this needs to be at least equally discussed in this group.
I will talk with my co-chairs and perhaps the ADs to get their opinion
on making such a change this point in the process.
rejectected by the WG multiple times. FWIW there are drafts already
with
No at all. The first and last time I proposed this was on 15 December
2017:
https://www.ietf.org/mail-archive/web/netmod/current/msg19753.html
Oh, I certainly would call you proposing that the schema for inline be
part of the rest of the schema Mount module well before that. I'm sure
I can dig up mail / slides it really necessary...
I don't think this has been proposed before. All previous proposals
were basically variants on what is now "use-schema", which works fine
when all instances have the same schema. This new proposal solves the
issue with different schemas in different instances.
I thought the previous proposals that as well, so don't see material
difference - at least from the usage standpoint. I also don't see why
the previous arguments that resulted in consensus for using Yang
Library underneath the an in line Mount Point don't apply.
B/c it doesn't work well with the NMDA. You can't mount yang library
in the configuration datastores; it has to be mounted in operational.
With meta-data, you can actually report the correct schema even in
running. (This is actually true also for pre-NMDA systems).
Understood and agree there is nothing new here and the current version
of SM (including inline) has the same limitation as rfc7895, and I'd
expect it to behave the same once we have rfc7985bis -- in fact the
inline case "just works" with YL-bis as defined today.
The argument I recall being the key point on inline was handling the
large variety of possible different implementation approaches for
modules using inline. For example an LNE that is implemented using VMs
which can be managed by the host at different times of the VMs
operational life cycle based on customer/provider requirements. I
really don't see how YL-bis has any bearing on this point and 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.
Lou
/martin
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
