Hi Tom, First, thanks for writing this draft. I found the summary of what NetConf and YANG do to be useful - despite having read through many of the relevant RFCs. I think it is also pulling out lots of the questions about what does using NetConf/RestConf and YANG mean; some of been touched on in various email threads also, of course.
For the discussion of the meaning of terms like configuration state and operational state, I come at this from the perspective of implementing a protocol - and there, I am used to configuration state being data that is passed to the process from the netmgmt system. There's learned state from elsewhere in the network. There are statistics or measured state. There's physical state (say of an interface). There can be operational state - which is sometimes derived from a combination of what was configured and what the physical state is. The easiest example is probably an interface state - which can be admin-down, oper-down, or oper-up. Personally, I am now much more aware of the use of configuration state and operational state from the network management perspective - but find that they are in conflict and inadequately descriptive for the protocol/process perspective. In Section 5, it says "It seems likely, to the author, that this logic does not apply to I2RS operations on operational state, that is the set of data that I2RS may want to edit will be a subset of the data that is of interest to I2RS; read-only statistics, for example, will not be in the former but will be in the latter. From this it follows that while a single, boolean substatement may be sufficient, and that anything else can be achieved with filters, it would much simpler and less error-prone for I2RS to have a further substatement that defines the set of data that is of interest to I2RS so that such data can be readily retrieved by an additional NETCONF RPC, get-i2rs perhaps (NETCONF, like YANG, is extensible). Such substatements would, like config, apply to all nodes in the subtree unless overridden. By analogy with the config substatement, it would seem likely that an 'edit-data true' node should not appear under an 'edit-data false' node (although quite why is not clear to the author)." I quite agree that the set of data that I2RS will want to edit will be a subset of the data that is of interest to I2RS. Rather than trying for a subtree approach where the editable aspect applies to the whole subtree, I'd pictured more of a read/write/modify attribute so that logically grouped information doesn't have to be repeated or separated in the models. I don't see the same need to pull i2rs state in the same way that config state is acquired. In Sec 6, the draft asks: "Will I2RS, having made changes to the operational state of a box, want to copy those changes to somewhere else, perhaps so that they can be re-applied at a later time, such as after a reboot, or is the underlying assumption of I2RS that such changes should be lost at a reboot? Will such a copy be required as an audit trail, a check on what actually happened, given that the changes that I2RS make are likely to be of higher risk to the integrity of the routing system than those made via configuration and NETCONF?" My personal opinion for the first question is no - that the changes made via I2RS are coming from network-oriented applications which will reimpose the appropriate operations after a reboot or when necessary. For an audit trail or a check on what actually happened, I can see wanting to know which client asked for what operation at what time. I think of this as an event flow that an auditor/troubleshooting system could listen to. I can also see it being provided via syslog; I suspect that Wes George and Joe Clarke problably have more refined opinions on how to do this, but I don't see it coming from reading the compressed set of most recent changes done. In Sec 6, the draft asks: "Will I2RS also want to create a set of changes on the box, like a candidate configuration datastore, so that they can be reviewed, validity checked by YANG logical statements, before they are applied?" I'd be interested in others thoughts, but I really don't think so. Regards, Alia
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
