Hi Jan,
You correctly wrote:
Then the choices become:
* Offline validation of <running> alone is NOT required
* Servers internally validate <running> via validating <intended>
*
SB> but in fact this is what declared, for my understanding, in RFC 8342, for
which “validation” is done on “intended” by the server , as also shown in
figure 2 of the RFC. Is it needed to change also RFC?
* 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.
Thanks
Sergio
From: netmod <netmod-boun...@ietf.org> On Behalf Of Jan Lindblad
Sent: Tuesday, November 23, 2021 10:59 AM
To: maqiufang (A) <maqiufang1=40huawei....@dmarc.ietf.org>
Cc: netmod@ietf.org
Subject: Re: [netmod] Must offline-validation of <running> alone be valid?
Qiufang,
Regarding the presentation of “system-defined
configuration(draft-ma-netmod-with-system)” in IETF 112, I would like to
initiate a separate thread to discuss “MUST offline-validation of <running>
alone be valid”.
Thank you for bringing this up again.
This is unknown if any RFC requires offline validation of <running>.
I do not consider this unknown. RFC 7950 is quite clear on the subject, with
numerous statements about configuration validity that are incompatible with the
current draft text. The most obvious contradiction is the last paragraph of
section 8.1, which consists of a single sentence:
The running configuration datastore MUST always be valid.
If you read the entire section, there will be no doubt that "valid" is defined
clearly and quite technically with what conditions must hold true. The current
draft is not adhering to these principles. One concrete example of such a
technical definition can be found in section 6.4.1:
6.4.1<https://datatracker.ietf.org/doc/html/rfc7950#section-6.4.1>. XPath
Context
o If the XPath expression is defined in a substatement to a data
node that represents configuration, the accessible tree is the
data in the datastore where the context node exists. The root
node has all top-level configuration data nodes in all modules as
children.
My conclusion is that the draft text needs to be changed to stay within the
bounds of RFC 7950.
Then the choices become:
* Offline validation of <running> alone is NOT required
* Servers internally validate <running> via validating <intended>
* 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.
Any thoughts on this?
The possibility to reason about and compute configuration changes without
involving the server is a key principle of the entire YANG project. By
declaring the complete interface in a machine readable way, orchestration
clients can do things that were note possible in the past. The effect of the
current draft text is to remove that possibility.
With some quite reasonable changes, however, I think the goals of the draft can
be accomplished in ways that are compatible with RFC 7950. I have discussed
these changes with you, so you know I have in mind. My opinion therefore is
that validation without the involvement of the server is required, regardless
of the options above. Having said that, I think there are more and better
options than option 1 and 2 above.
Best Regards,
/jan
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
