On Sun, Sep 17, 2017 at 8:31 AM, Andy Bierman <a...@yumaworks.com> 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. > > I would prefer to solve this problem by making disabled nodes part of the standard: https://tools.ietf.org/html/draft-kwatsen-conditional-enablement-00 Bring back Kent's draft -- define a simple boolean for enabled/disabled. I don't understand why templates are mentioned in the draft. since they are not really defined. Isn't it good enough to say that the server can add configuration nodes to the <intended> datastore, without getting specific about non-standard mechanisms? There are many other ways the server can inject configuration that are not mentioned. Andy > Andy > > > On Sun, Sep 17, 2017 at 6:41 AM, Martin Bjorklund <m...@tail-f.com> wrote: > >> Andy Bierman <a...@yumaworks.com> wrote: >> > On Sat, Sep 16, 2017 at 12:24 AM, Juergen Schoenwaelder < >> > j.schoenwael...@jacobs-university.de> 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 netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod