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

From: Robert Wilton via Datatracker <[email-masked]>
Date: Wed, 04 Nov 2020 09:46:17 -0800

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://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-babel-information-model/

----------------------------------------------------------------------
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.

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].   
But what we end up with is an information model defined in a custom ad hoc
language, which will naturally necessitate for the YANG and TR-181 models to be
generated by hand, and for all three models to be kept up to date and
consistent with each other.  Hence, I wonder whether retrospectively it would
have been better to just define the YANG model in IETF and ask BBF to use that
as source reference to construct the TR-181 model from, ideally as a
programmatic conversion, or failing that by hand.  At least that way there are
only two things to keep in sync rather than three.

Regards,
Rob

---

From: Mahesh Jethanandani <[email-masked]>
Date: Wed, 4 Nov 2020 10:23:50 -0800

Hi Rob,

> On Nov 4, 2020, at 9:46 AM, Robert Wilton via Datatracker <[email-masked]> wrote:
> 

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.

> only two things to keep in sync rather than three.

Mahesh Jethanandani
[email-masked]

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Thu, 5 Nov 2020 12:17:12 +0000

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.

Thanks,
Rob

From: Mahesh Jethanandani <[email-masked]>
Sent: 04 November 2020 18:24
To: Rob Wilton (rwilton) <[email-masked]>
Cc: The IESG <[email-masked]>; [email-masked]; [email-masked]; Babel at IETF <[email-masked]>; Donald Eastlake <[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> wrote:

Thanks.

Regards,
Rob

Mahesh Jethanandani
[email-masked]<mailto:[email-masked]>

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 6 Nov 2020 21:40:25 +0000

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

> Cc: The IESG <[email-masked]>; [email-masked];
> [email-masked]; Babel at IETF <[email-masked]>; Donald Eastlake
> <[email-masked]>
> On Nov 4, 2020, at 9:46 AM, Robert Wilton via Datatracker
> <[email-masked]<mailto:[email-masked]>> wrote:
> 
> Please refer to
> https://urldefense.com/v3/__https://www.ietf.org/iesg/statement/discuss
> -
> criteria.html__;!!BhdT!zLVd1eLtHrXhlZziRBtQT2MAdZ6mm3waQWNOuByJpI
> 16Bb-pj5tYrjseBJzqy6yN$
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-
> babel-information-
> model/__;!!BhdT!zLVd1eLtHrXhlZziRBtQT2MAdZ6mm3waQWNOuByJpI16Bb
> -pj5tYrjseBOB6qxxt$
> 
> 
> 
> 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.
> 
> 
> 
> different data models,  one based on YANG and other based on BBF's [TR-
> 181]

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Sat, 7 Nov 2020 00:04:36 +0000

Hi Rob,
Thanks for your review. Separate from the conversation with Mahesh on
whether the document should have a normative reference to RFC 8342
(which I responded to recently), I wanted to comment on one of your other
points.
Thx,
Barbara
 
> 181].

The short answer to the retrospective question is "No".
Long answer:
Personally, I would have preferred to only do the TR-181 model, and then,
if someone wanted a YANG model, they could figure it out from my TR-181
model. My employer (along with most
ISPs around the world) uses TR-069 to manage
all of its "Residential Gateway" Wi-Fi routers. Babel is well-suited
to such Wi-Fi routers. I'm not aware of any use of NETCONF or YANG 
to manage Wi-Fi routers on a large scale.
I am aware of 2 major ISPs who want to use NETCONF to manage their
Wi-Fi routers and are working in
BBF to translate BBF TR-181 into YANG, so they have a usable data model
for that purpose.
But in the interest of harmonization between BBF and IETF, I thought it best
to do an info model that could drive both.
As it turns out, this has had had unintended good consequences. The Babel protocol
implementors have used the Info model as a basis for the reporting and 
configuration options they expose through their user interfaces and APIs. 
Therefore, we have had good input from the implementors on the info model,
effectively have implementations, and if someone wants to use TR-181 or
YANG for management, the hooks will exist in these implementations. 
None of the implementors have interest in either YANG or TR-181.

Anyway, it may be useful to think of me as primarily a BBF community member
who is participating in IETF to further certain efforts related to my BBF work.
It was very good for Babel WG that Mahesh so kindly agreed to help with the YANG 
model at the time the WG was getting ready to send rfc6126bis for IETF Last Call.
I was just about to start a scorched Earth / no-holds-barred war to get the 
YANG deliverable taken out of the charter (it was included under duress)
because we had no-one with the interest or competency to write a YANG DM. 
Mahesh is a hero. 😊