Juergen, Thanks for the pointers. Some of them are very enlightening.
The specific concern that caused me to send this email was the comment about applicable datastores for NACM, hence I was considering whether or not to submit an erratum on rfc6536 section 3.2.
However, that section is specifically only talking about datastores, and given that operational state isn't (currently) formally defined as being a datastore in NETCONF/YANG then that section is probably still valid as it stands.
Personally I think that it would be generally helpful if the drafts did provide some more explicit details on how operational data is/is not represented, and from some of your references it appears that I might not be the only one. :-)
Rob On 01/03/2016 16:39, Juergen Schoenwaelder wrote:
I once again point to section 4.3 and more specifically to section 4.3.3 of RFC 6244. There have also been several I-Ds and discussions during past WG meetings on how to deal with this issue. See for example this: https://tools.ietf.org/html/draft-bjorklund-netmod-operational-00 Some of the discussion took place in NETCONF. See for example http://www.ietf.org/proceedings/84/minutes/minutes-84-netconf http://www.ietf.org/proceedings/85/minutes/minutes-85-netconf It is actually interesting to look at Phil's slides: http://www.ietf.org/proceedings/85/slides/slides-85-netconf-6.pdf This was November 2012, i2rs was just getting born and open config likely did not even exist. All I want to point out is that this is not a new topic for people who have been around long enough and yes there were quite some discussions before we created the structure that is found in a couple of RFCs. The RFCs are reasonably consistent in saying what a configuration datastore is. The rest simply never was defined and so you can't find an answer in the RFCs (except perhaps section 4.3.3 of RFC 6244 documenting that whether operational state is a datastore or not is somewhat undefined). /js (in his historian role ;-) On Tue, Mar 01, 2016 at 04:20:18PM +0000, Robert Wilton wrote:Hi, In some of the previous opstate related discussions on this alias, I had some confusion as to which datastore operational state is held in (or whether it is held in a datastore at all :-) It also seems that the NETCONF/YANG related RFCs are vague on whether operational state is actually held in a datastore, or if so what it is. I've given some snippets below. Is this something that needs to be clarified as errata to those standards (particularly NACM)? -- rfc6020bis, section 7.21.1. The config Statement states: " If "config" is "false", the definition represents state data. Data nodes representing state data are not part of configuration datastores." ... which obviously indicates that they are not part of any configuration datastore, but doesn't indicate that they are part of an operational state datastore. -- rfc6241 (section 1.1 terminology) defines datastore and configuration datastore as: o datastore: A conceptual place to store and access information. A datastore might be implemented, for example, using files, a database, flash memory locations, or combinations thereof. o configuration datastore: The datastore holding the complete set of configuration data that is required to get a device from its initial default state into a desired operational state. The NETCONF RFC then goes on to describe/use configuration datastores in various ways, but makes no further mention of any operational state datastore. E.g. the one line description of a NETCONF get request is "Description: Retrieve running configuration and device state information." -- rfc6536 NACM, (section 3.2. Datastore Access) states: Only the standard NETCONF datastores (candidate, running, and startup) are controlled by NACM. Local or remote files or datastores accessed via the <url> parameter are not controlled by NACM. Which implies that if operational state is held in a datastore then it is not controlled by NACM - which presumably can't be right. Thanks, Rob _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
