Hi Balazs,
I also wanted to comment on validation. Please see inline below ...
On 14/09/2017 15:04, Balazs Lengyel wrote:
Hello,
Reading the draft-ietf-netmod-revised-datastores-04 some comments:
General) The system often adds data to the <running> or <intended>
datastore already not just to <operational>: e.g.
UC1: I have a server configured in running. I need to bind it to an
ip-address. The ip-address might be the local loopback address,
however if that is only added to the <operational>, validation will
fail indicating that the server is bound to a non-existent address.
How to handle this?
UC2: I have a set of capabilities set by the system e.g.
supported-reporting-intervals. I need to configure a job that MUST use
one of these intervals. If the supported-reporting-intervals are only
added to <operational> I can not validate the selected-interval in my
configured job.
My proposal is to allow the system to add data to running as well.
Actually I think that is a more relevant case then adding
configuration just to <operation>.
CH 4.4.) "Validation is performed on the contents of <intended>."
This to me means that default data is not considered at validation
which would be a backwards incompatible change. Also if validation
does not consider system configured data that would allow cases like
multiple interfaces named lo0. One from <intended> one from system
configuration. IMHO while it is OK to violate uniqueness because of
remnant data, the above violation of uniqueness seems a bad idea.
When we have been previously discussed this as part of the design team,
we wanted the invariant that <running>/<intended> should not be able to
become invalid due to an external change in the system (e.g. a linecard
is removed or changed, or the device has run out of some resource). I
think that the corollary to this is that when the existing NETCONF
validation is performed, the validation must not take into account
anything specific to the device that could change due to some external
event (e.g. linecard is changed etc). So this means that a valid
configuration just represents what could be applied to the device, if
enough resources were available, and the correct types of linecards had
been populated and were working, etc.
But often, clients want more than this. They don't want to just know
whether the configuration could theoretically work, but actually want to
know whether the device anticipates that it will be able to enact the
configuration successfully. So, I think that NETCONF actually also
needs a separate "should apply ok" extension RPC. This "should apply
ok" RPC would do everything that validate does today, but can also do
many more checks to try and ensure that the configuration change is
likely to be successful applied to <operational> (e.g. check that the
necessary hardware is present and working, licenses have been enabled,
resources are available, etc). Obviously, this "should apply ok"
invariant would not necessarily always hold for the configuration
datastores. An engineer may pull out a linecard that means that
configuration currently in <running>/<intended> is valid (as is required
in RFC 7950), but would not be applied successfully due to the missing
hardware.
But I also think that this is beyond the scope of the current NMDA
architecture, but perhaps something that could be specified by a
separate draft, if others also think that this would be useful to
standardize?
Thanks,
Rob
Ch. 4.7) Is it allowed to violate uniqueness of key values? IMHO it
should not be.
Ch 5.1) IMHO actions and rpcs should be allowed to include other
datastores in their XPath evaluation. My suggestion is that they need
to specify it somehow. (Yang extension?)
UC1) I want to define a convinience action that allows me to do a big
modification in <running> in one step. I wan't to validate what it is
doing based on the current contents of running. E.g. configure the OAM
settings for the system including SNMP/Netconf/FTP in one step, but
for each step I need to check that I am putting the relevant server on
an existing interface.
If specifying the datastore is an overkill, I would still rather chose
runing as the accessible datastore. XPath is mostly use for checks.
Checks are done against configuration.
Appendix B)
"4. How applied : automatic" This is definitely not enough to
understand what happens even as an example. I propose:
Changes are automatically propagated to <operational>
C.1) During the example the
<ip>2001:db8::10</ip>
<prefix-length>32</prefix-length>
is changed to 64 its. Is that intentional? It is not mentioned in the
text.
regards Balazs
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
