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

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

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

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