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

Robert Wilton via Datatracker <noreply@ietf.org> Wed, 04 November 2020 17:46 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: babel@ietf.org
Delivered-To: babel@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E0B2B3A13B1; Wed, 4 Nov 2020 09:46:17 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Robert Wilton via Datatracker <noreply@ietf.org>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-babel-information-model@ietf.org, babel-chairs@ietf.org, babel@ietf.org, Donald Eastlake <d3e3e3@gmail.com>, d3e3e3@gmail.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.21.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Robert Wilton <rwilton@cisco.com>
Message-ID: <160451197790.28880.17597785068103610213@ietfa.amsl.com>
Date: Wed, 04 Nov 2020 09:46:17 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/5itCpdhznS5dvGt2lzNlcljIJrI>
Subject: [babel] Robert Wilton's No Objection on draft-ietf-babel-information-model-11: (with COMMENT)
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "A list for discussion of the Babel Routing Protocol." <babel.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/babel>, <mailto:babel-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/babel/>
List-Post: <mailto:babel@ietf.org>
List-Help: <mailto:babel-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/babel>, <mailto:babel-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Nov 2020 17:46:18 -0000

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:


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.