Tom, please send a comment to i2rs saying that they should import terms rather than trying to (re-)define them. As long as people keep (re-)defining terms, we will have confusion and in this specific case I think it is the NETMOD or NETCONF WGs that should define the terms, not any other WGs.
/js On Wed, Apr 27, 2016 at 12:36:44PM +0100, t.petch wrote: > I see that the definition of 'datastores' has cropped up in this AD > Review, as in the e-mail below. > > Meanwhile, draft-ietf-i2rs-pub-sub-requirements-05.txt is in IETF Last > Call and redefines, or recreates, the term for us > > A YANG datastore is a conceptual datastore that contains hierarchical > data defined in YANG data models. It is what is referred in existing > RFCs as "NETCONF datastore". However, as the same datastore is no > longer tied to NETCONF as a specific transport, the term "YANG > datastore" is deemed more appropriate. > > I think that the concept of datastore has been troublesome to those > coming to YANG lately, such as openconfig and I2RS, and that this will > just muddy the waters more, especially as it is tucked away in an > Informational document. If I2RS want to define such terminology, then > it should be in the I2RS Architecture or some such; but IMHO they should > not be defining YANG datastores at all. > > Tom Petch > > ----- Original Message ----- > From: "Martin Bjorklund" <[email protected]> > To: <[email protected]> > Cc: <[email protected]> > Sent: Thursday, April 21, 2016 2:58 PM > Subject: Re: [netmod] AD review draft-ietf-netmod-rfc6020bis-11 (part 1) > > > > Benoit Claise <[email protected]> wrote: > > > Hi Martin, > > > > > > Thanks for engaging quickly. > > > [I removed the resolved entries] > > > > Hi Benoit, > > > > > > > > Benoit Claise <[email protected]> wrote: > > > >> Dear all, > > > >> > > > >> Here is part 1 of my AD review. > > > >> > > > >> I found this useful: > > > >> > http://tools.ietf.org/rfcdiff/rfcdiff.pyht?url1=http://www.ietf.org/rfc/ > rfc6020.txt&url2=http://www.ietf.org/id/draft-ietf-netmod-rfc6020bis-11. > txt > > > >> > > > >> - Do we want to mention RESTCONF in the abstract? From the new > charter: > > > >> > > > >> The NETMOD working group has defined the data modeling > language > > > >> YANG, which can be used to specify network management data > models > > > >> that are transported over such protocols as NETCONF and > RESTCONF. > > > >> > > > >> OLD: > > > >> > > > >> YANG is a data modeling language used to model configuration > data, > > > >> state data, remote procedure calls, and notifications for > network > > > >> management protocols like the Network Configuration Protocol > > > >> (NETCONF). > > > >> > > > >> NEW: > > > >> > > > >> YANG is a data modeling language used to model configuration > data, > > > >> state data, remote procedure calls, and notifications for > network > > > >> management protocols transported over such protocols as > Network > > > >> Configuration Protocol (NETCONF) and RESTCONF. This document > specifies > > > >> the YANG mappings to NETCONF. > > > > The first paragraph in the introduction mentions other protocols; > > > > RESCTONF and CoMI. My personal opinion is that this is > sufficient, > > > > but I'd like to hear what others think. > > > The current abstract doesn't even mention the mapping to NETCONF. > > > > See Juergen's proposal, I think that one is better. > > > > > >> - Section 1.1 > > > >> Since this document introduces the NETCONF mapping, the protocol > > > >> change must be included in section 1.1 > > > >> Example: no NETCONF capability exchange in YANG 1.1, we use > > > >> exclusively the YANG library > > > >> Any other ones? > > > And this one? > > > > NEW: > > > > The following changes are done to the NETCONF mapping: > > > > o A server advertises support for YANG 1.1 modules by using ietf- > > yang-library [I-D.ietf-netconf-yang-library] instead of listing > > them as capabilities in the <hello> message. > > > > > >> - Terminology: > > > >> The following terms are defined in [RFC6241 > > > >> <https://tools.ietf.org/html/rfc6241>]: > > > >> > > > >> ... > > > >> > > > >> o configuration datastore: a configuration datastore is an > > > >> instantiated data tree with configuration data > > > >> > > > >> o datastore: an instantiated data tree > > > >> > > > >> RFC6241 has different definition for "configuration datastore" > and > > > >> "datastore". > > > >> I would just provide the pointer to the RFC 6241 definitions. > > > >> If you intend to provide an adapted definition for the YANG > mappings, > > > >> then you should say so. > > > > How about: > > > > > > > > OLD: > > > > > > > > o configuration datastore: a configuration datastore is an > > > > instantiated data tree with configuration data > > > > > > > > o datastore: an instantiated data tree > > > > > > > > NEW: > > > > > > > > o configuration datastore: When modelled with YANG, a > configuration > > > > datastore is an instantiated data tree with configuration > data > > > > > > > > o datastore: When modelled with YANG, an instantiated data > tree > > > > > > > This issue is with "The following terms are defined in [RFC6241]", > but > > > you re-define those terms. > > > So give a warning about the redefinition to the readers. > > > > Yes, that's what my proposed text does. It says that "datastore" is > > defined in 6241, and when YANG is used, it means the instantiated data > > tree. > > > > > >> - Section 4.1 > > > >> > > > >> YANG models can describe constraints to be enforced on the > data, > > > >> restricting the appearance or value of nodes based on the > presence or > > > >> value of other nodes in the hierarchy. > > > >> > > > >> I was looking for an example of appearance. > > > >> NEW? > > > >> YANG models can describe constraints to be enforced on the > data, > > > >> restricting the appearance (for example, with the "when" > statement) > > > >> or value of nodes based on the presence or value of other > nodes in > > > >> the hierarchy. > > > > This is very early in the document, and the text tries to give a > very > > > > high level function overview. I am not sure that mentioning > "when" at > > > > this time actually helps a first time reader. > > > The first time I read this, I was wondering how YANG data models can > > > describe constraints on HOW data appear, while you wanted to express > > > WHETHER a data appear. Maybe "when" is not the best way to help the > > > first time user, but something is needed. > > > > How about "restricting the presence or value of nodes"? > > > > > > /martin > > > > _______________________________________________ > > netmod mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
