Hi Balazs, Thanks for your review. Comments inline.
Balazs Lengyel <[email protected]> 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>. I think the consensus is that in general it is a bad idea if servers (spontaneously) add data to <running>. However, there is nothing in the new or old architectures that prohibits this. Also note that the draft says: Currently there are no standard mechanisms defined that affect <intended> so that it would have different contents than <running>, but this architecture allows for such mechanisms to be defined. which means that you can also define your own mechanisms for adding things to <intended>, before validation. > CH 4.4.) "Validation is performed on the contents of <intended>." > This to me means that default data is not considered at validation Note that RFC 7950, section 6.4.1, says: In the accessible tree, all leafs and leaf-lists with default values in use exist (see Sections 7.6.1 and 7.7.2). So defaults are taken into account when intended is validated. > 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. If your system adds data to <running>, or to <intended>, it will be validated. > Ch. 4.7) Is it allowed to violate uniqueness of key values? IMHO it > should not be. Agreed. Note that the draft explicitly lists the constraints that can be violated, and uniqueness of keys is not listed. > 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?) This is something that the WG has discussed in the past as well, but so far no concrete proposal has been made. I think such extensions can be done in a separate document in the future, or maybe if we do a new version of YANG. But note that for rpc and action, this section only talks about XPath in input/output parameters. > 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. I think this is covered. If you have an rpc that modifies <running>, the result will be valdiated according to the must expression in the data models. > 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> I agree this is better. > 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. No this is a bug, will be fixed! /martin _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
