On Mon, Sep 18, 2017 at 8:34 AM, Robert Wilton <[email protected]> wrote:
> > > On 18/09/2017 15:21, Andy Bierman wrote: > > > > 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. > > I think that NMDA acknowledges non standard extensions could exist that > would violate RFC 7950 if/when those features are used, and provides a > standard architecture (i.e. the definition of <intended>) to allow devices > to expose the effects of those bespoke features in a standard way. > > Phil had proposed adding the following text on validation: > > +The implication of the existence of templating mechanisms is that > +<running> is now explicitly allowed to be invalid, since the > +templating mechanism may be supplying additional data that satisfies > +constraints that may not be satisfied by <running> itself. > > Do you think that text like this would help? Or perhaps more generically, > something like this: > > No. I do not agree that the MUST in RFC 7950 can be removed. I do not agree the architecture should update YANG at all. Andy > The implication of the existence of mechanisms that can allow > <intended> to differ from <running> means that <running> is no > longer guaranteed to always be valid. However, when any > change is made to <running>, <intended> must also be updated at > the same time and be successfully validated before the operation > on <running> can be completed. > > Obviously this would then need to update 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. > > I agree. > > Thanks, > Rob > > > > 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
