Kent, Qiufang, all,
>>> Offline validation of <running> alone IS required
>>> Options:
>>> Clients MUST copy/paste any referenced system configuration into <running>,
>>> even though it goes against our objective of avoiding-copy when possible.
>>> Defer work to be a YANG-next effort.
>>
>> In order to move forward, I would propose working out some more options in
>> this list. I have suggested a few to the authors that I think are better
>> than the two above, but I will leave it to the authors make the call for
>> what they want to bring up for discussion.
>
> I don’t think the case has been made that *offline* validation of <running>
> by itself must be valid. Yes, *online* <running> must be valid, as must
> <intended>, with the intention of RFC 8342 being that both are validated in
> one and the same operation by the server (known to me as an author of RFC
> 8342). I understand that implementations may have assumed offline validation
> of <running> must be valid, I just can’t find the RFC reference that demands
> it be supported, and without such reference, it falls into an undefined area.
> Necessitating offline validation of <running>, if that is what the WG
> decides, results in solutions for which none seem nice to me, at least I
> haven’t seen any yet. Please share any “better options” you have in mind.
Here you are introducing two concepts that the RFCs (6020, 7950, 8342) are
never mentioning: online and offline validation. Then you say that because the
RFCs don't talk about these concepts, the behavior is undefined. I strongly
disagree. The RFCs talk about validation, and describes the rules for how that
happens. These rules always apply, regardless of online, offline or the phase
of the moon.
If you think the online and offline validation concepts have merit, I would
like to see proper definitions of them, and how you would like to modify the
existing RFCs with respect to these concepts. It might also be a good idea to
update the proposed draft, which currently does not mention these concepts.
The added value and the core essence of YANG is enabling us to reason about
configurations and compute configuration changes without necessarily asking the
server if a configuration is valid by "trial and error". This is possible
because a YANG model is a detailed and reasonably complete description of the
management interface. Introducing changes to YANG that breaks this basic
premise would be dumbing down YANG, and I can't see the benefit with this
change, or how this would be compatible with YANG 1.0, or 1.1 rules.
I think the ideas behind the system datastore are interesting and in many use
cases useful. We just need to introduce them in a way that doesn't break
existing, agnostic implementations.
I made some proposals earlier, both on the interim and privately to the draft
authors, along these lines:
Option #1
+ We could have a new system datastore that technically is a part of running.
Everything in system would show up in running to clients unaware of the system
datastore. Every time the system datastore changes for whatever reason, the
running datastore transaction ids (if we manage to get that concept defined),
are updated
+ Clients interested to see pure view of the system datastore without anything
else in running could issue a get-data towards the system datastore
+ Clients interested to see a pure view of running without any system datastore
elements could issue a get-data towards running with an extra flag called
'without-system'
+ Since all system elements are already part of running, clients have no need
to copy data between the two datastores
Option #2
+ We could have a system datastore that technically is a part of operational.
Everything in system would show up in operational to clients unaware of the
system datastore. The running datastore always maintains referential integrity,
i.e. cannot reference the system datastore.
+ Clients interested to see pure view of the system datastore could issue a
get-data towards the system datastore
+ Since the system datastore is not part of running, clients can already see a
pure view of running without any system datastore elements using a simple
get-data.
+ Clients that are aware of the system datastore and are interested to
configure references from running to system elements would issue an edit-data
rpc with the additional flag 'resolve-system-references'. This will make the
server copy any system elements referenced into running without the client
doing so explicitly.
+ Clients unaware of the system datastore would have to include (copy)
information from the system datastore to running in order to reference them.
> In the meanwhile, can we discuss the issues around a legacy client failing an
> offline validation? In this case, a production deployment must have 1)
> deployed devices that support <system>, 2) deployed at least one client that
> supports <system>, and 3) decided to let clients start pushing config using
> <system>. While in the pre-production testing phase, it would be quickly
> discovered that all legacy clients need to be updated. By the time of going
> to production, the deployment should have all the clients updated, so it
> seems that only the forgotten (relatively insignificant) clients might have
> an offline validation of <running> failure. Is this a fair assessment?
1) agreed, without devices that support the system datastore, no problem
2,3) well, a "client" in this case could very well be a CLI operator or other
management interface. Even in highly automated networks, CLI operators are
still common
Your description of the operations environment where the operator has full
implementation control of all clients is very different from my field
experience. Not only do I believe the situation with multiple, independent
clients is the most commonly occurring one in the real world across all server
deployments, but I also think the operator usually has limited insight into as
well as control over which specific protocol features the clients implement. I
therefore think your assessment is fair only for a minority of field situations.
Best Regards,
/jan
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
