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

["Rob Wilton (rwilton)" <[e-mail]>]

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 <[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://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.

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



Mahesh Jethanandani
[e-mail]<mailto:[e-mail]>