Re: [babel] Robert Wilton's No Objection on draft-ietf-babel-information-model-11: (with COMMENT)

["STARK, BARBARA H" <[e-mail]>]

Hi Rob and Mahesh,

> Hi Mahesh,
> 
> Making it a normative reference only means draft-ietf-babel-information-
> model contains some text (i.e. the text about datastores) that can only be
> properly understood by reading some of RFC 8342.
> 
> Making RFC 8342 an informative reference would mean that there isn't any
> text in draft-ietf-babel-information-model that needs RFC 8342 to properly
> understand it, but that it contains information that may be
> interesting/helpful to the reader.  If you want RFC 8342 to only be an
> informative reference (or potentially not be a reference at all), then I think
> that this document would either need to not talk about datastores at all, or
> provide more description about the concepts that it is ascribing to the
> 'enable' properties in the information model.

It seems that the terms causing a problem are "operational datastore" and "running
datastore"? I looked around on the Internet to see what I could find about these terms
(because I know the concepts have been around since long before RFC 8342).
Here is a link to a definition of "Operational Datastore" from 2013, that makes no
mention of YANG: 
https://www.techopedia.com/definition/1226/operational-data-store-ods
and the more generic "Datastore" definition (also from 2013):
https://www.techopedia.com/definition/23343/datastore

"Running datastore" does seem to be more specific to YANG. My brief searches
haven't found that term outside YANG (yet). The first use of it in YANG I find
is RFC6241, where both "running datastore" and "operational datastore" are used in
Appendix C (YANG Module for NETCONF Protocol Operations) in node descriptions.
For example:
anyxml config {
              description
                "Inline Config content: <config> element.  Represents
                 an entire configuration datastore, not
                 a subset of the running datastore.";

Note the lower case usage. Interestingly,
"operational datastore" does not appear in this RFC. Instead, it includes the term
"configuration datastore". In terminology, "configuration datastore" and "running
configuration datastore" are both there (lowercase), but they aren't described as
being concepts unique to YANG or NETCONF. They appear more to be defined as
terms of art.

I've never read RFC 8342, and had thought Mahesh was including them as well-
understood terms of art (I certainly immediately understood what concepts he
was referring to when he introduced the words, in spite of my lack of familiarity
with YANG or NETCONF). I note that babel-information-model uses the terms
in lowercase. 

I don't think a reference to RFC 8342 is appropriate to indicate where these
terms of art come from. They clearly predate RFC 8342 and NETCONF. There is no 
terminology section in this draft. I'm not keen on adding a terminology 
section to the draft just for these 2 rather well-understood terms of art.
But I would do that (and maybe find a few other terms of art to include
so they don't seem out of place), if that were a suitable compromise.
Barbara

> Thanks,
> Rob
> 
> 
> From: Mahesh Jethanandani <[e-mail]>
> Sent: 04 November 2020 18:24
> To: Rob Wilton (rwilton) <[e-mail]>
> Cc: The IESG <[e-mail]>; [e-mail];
> [e-mail]; Babel at IETF <[e-mail]>; Donald Eastlake
> <[e-mail]>
> Subject: Re: Robert Wilton's No Objection on draft-ietf-babel-information-
> model-11: (with COMMENT)
> 
> Hi Rob,
> 
> 
> On Nov 4, 2020, at 9:46 AM, Robert Wilton via Datatracker
> <[e-mail]<mailto:[e-mail]>> wrote:
> 
> Robert Wilton has entered the following ballot position for
> draft-ietf-babel-information-model-11: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to
> https://urldefense.com/v3/__https://www.ietf.org/iesg/statement/discuss
> -
> criteria.html__;!!BhdT!zLVd1eLtHrXhlZziRBtQT2MAdZ6mm3waQWNOuByJpI
> 16Bb-pj5tYrjseBJzqy6yN$
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-
> babel-information-
> model/__;!!BhdT!zLVd1eLtHrXhlZziRBtQT2MAdZ6mm3waQWNOuByJpI16Bb
> -pj5tYrjseBOB6qxxt$
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thank you for this document.
> 
> I support Ben's discuss regarding reusing the terminology from NMDA.  I
> think
> that the document should have a normative reference to RFC 8342, and
> probably
> explain that in some places the information model is using the same concepts
> of
> configuration and operational data separation described in NMDA.
> 
> While I am not against a reference to the terminology from NMDA in the
> information model, (BTW, I am ignorant on what it means for an
> informational draft to have a normative reference), I am not sure whether it
> needs to normative or whether it can be informative. By making it normative,
> are we making this information model more YANG specific? Could the
> reference to NMDA be normative in the YANG model of this information
> model  (which the YANG model already does)?
> 
> Thanks.
> 
> 
> 
> I also support Alvaro's question about whether the source-routing
> component
> should be included.
> 
> This is just a comment, and I'm not proposing that you change tack, but I
> have
> to confess that I question how beneficial publishing an Information Model
> really is.  I understand that the goal here is to be able to publish two
> different data models,  one based on YANG and other based on BBF's [TR-
> 181]