2cents: The Yang datastore definition with the conceptual data store is clear to those who already know what is going on.
To me, the shortened term 'Yang datastore' might be misleading because I don't think Yang necessarily provides or defines the format for a data store. Rather, it defines the format for an access portal to a data store. The data store may have other access methods which have little to do with Yang. Perhaps it would be clearer to use a term with less preloading. Instead of Yang or Netconf datastore, maybe Yang of Netconf data portal? -----Original Message----- From: netmod [mailto:[email protected]] On Behalf Of Benoit Claise Sent: Tuesday, May 03, 2016 3:54 AM To: t.petch; Martin Bjorklund Cc: [email protected]; [email protected] Subject: Re: [netmod] datastores Re: AD review draft-ietf-netmod-rfc6020bis-11 (part 1) FYI. https://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/ballot/#benoit-claise Regards, Benoit > Tom, >> 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. > Agreed. > Timely review as draft-ietf-i2rs-pub-sub-requirements is on the next > IESG telechat. > > Regards, Benoit >> >> 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/r >> fc/ >> 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 > . > _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
