On Mon, Sep 18, 2017 at 2:28 AM, Robert Wilton <[email protected]> wrote:
> Hi Andy, > > At the moment, NMDA does not change the definition of <running> for a > standards compliant implementation of YANG/NETCONF/RESTCONF. It is still > the same as in 7950, and <running> must still be a "valid configuration > data tree" for a standards complaint implementation. > > However, the draft acknowledges that proprietary extensions exist that can > modify the behaviour of <running> in ways that means that <running> is not > always a valid configuration data tree. The draft gives two examples of > how <running> could be manipulated (inactive config, and templates). > I don't see how NMDA can both acknowledge and violate the MUST be valid in RFC 7950. That statement is quite clear in RFC 7950. > If those extensions are standardized then I think it is likely that those > RFCs would need to update 7950 to indicate that <running> isn't necessarily > a "valid configuration data tree" when those extensions are used. But I > don't think that needs to be stated in the NMDA architecture at this time. > Right -- because 7950 still holds any any server that does not have a valid <running> is non-compliant to 7950. Andy > So, what is <intended>? > - this is meant to represent the configuration that the system will > actually attempt to apply after any and all manipulation (e.g. by > templates, inactive removal, perhaps system scripts, etc) of the > configuration has been performed. > - it must always be a valid configuration data tree. > - If <running> is updated then <intended> is always updated at the same > time. Hence, any successful change to <running> requires that <intended> > has also been updated and validated. E.g. in RESTCONF terms, I think that > both <running> and <intended> should get the same last-change timestamp > whenever <running> is updated. > - It provides a known fixed point so that any client can see the full > validated config, i.e. even for devices that implement proprietary > manipulations of the configuring in <running>. > - If the device doesn't support any extra proprietary config > manipulations, then <intended> is identical to <running>. > > I think that we can possibly do a bit more to better define what <intended > is>. My previous suggestion as an improvement was below (perhaps you think > it needs more clarification)?: > > *OLD:* > > 4.4. The Intended Configuration Datastore (<intended>) > > The intended configuration datastore (<intended>) is a read-only > configuration datastore. It is tightly coupled to <running>. When > data is written to <running>, the data that is to be validated is > also conceptually written to <intended>. Validation is performed on > the contents of <intended>. > > For simple implementations, <running> and <intended> are identical. > > <intended> does not persist across reboots; its relationship with > <running> makes that unnecessary. > > ... > > *NEW:* > > 4.4. The Intended Configuration Datastore (<intended>) > > The intended configuration datastore (<intended>) is a read-only > configuration datastore. It represents the configuration after all > configuration transformations to <running> are performed (e.g. > template expansion, inactive configuration removal), and is the > configuration that the system attempts to apply. > > It is tightly coupled to <running>. When data is written to > <running>, the data that is to be validated is also conceptually > written to <intended>. Validation is performed on the contents of > <intended>. > > For simple implementations, <running> and <intended> are identical. > > The contents of <intended> is also related to the 'config true' > subset of <operational>, and hence a client can determine to what > extent the intended configuration is currently applied by checking > whether the contents of <intended> also appears in <operational>. > > <intended> does not persist across reboots; its relationship with > <running> makes that unnecessary. > ... > > Thanks, > Rob > > On 17/09/2017 16:31, Andy Bierman wrote: > > Hi, > > My concern is that the definition of <running> is being changed to > include undefined and undeclared proprietary extensions. > This is counter-productive to the IETF's stated goal of interoperability. > > > Andy > > > On Sun, Sep 17, 2017 at 6:41 AM, Martin Bjorklund <[email protected]> wrote: > >> Andy Bierman <[email protected]> wrote: >> > On Sat, Sep 16, 2017 at 12:24 AM, Juergen Schoenwaelder < >> > [email protected]> wrote: >> > >> > > On Fri, Sep 15, 2017 at 02:07:58PM -0700, Andy Bierman wrote: >> > > > Hi, >> > > > >> > > > I strongly agree with Tom that the current draft is an update to RFC >> > > 7950. >> > > > I also strongly disagree with the decision to omit RFC 2119 in a >> > > standards >> > > > track document. IMO RFC 2119 terms need to be used in normative >> text, >> > > > especially when dealing with XPath and YANG compiler behavior. >> > > > >> > > >> > > RFC 8174: >> > > >> > > o These words can be used as defined here, but using them is not >> > > required. Specifically, normative text does not require the use >> > > of these key words. They are used for clarity and consistency >> > > when that is what's wanted, but a lot of normative text does not >> > > use them and is still normative. >> > > >> > > >> > So what? >> > Existing YANG specifications use RFC 2119 terms. >> > This draft uses those terms, just with lower-case. >> >> Actually, section 5.1 XPath Context in the revised datastore draft >> uses the same language as section 6.4.1 XPath Context in RFC 7950. In >> fact, the text in the draft is copied (and adjusted) from RFC 7950. >> >> >> /martin >> > > >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
