[lmap] Benoit Claise's No Objection on draft-ietf-lmap-yang-11: (with COMMENT)

Benoit Claise <bclaise@cisco.com> Thu, 16 March 2017 09:27 UTC

Return-Path: <bclaise@cisco.com>
X-Original-To: lmap@ietf.org
Delivered-To: lmap@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E716126DED; Thu, 16 Mar 2017 02:27:31 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benoit Claise <bclaise@cisco.com>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-lmap-yang@ietf.org, Dan Romascanu <dromasca@gmail.com>, lmap-chairs@ietf.org, dromasca@gmail.com, lmap@ietf.org, bill.wu@huawei.com
X-Test-IDTracker: no
X-IETF-IDTracker: 6.47.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148965645153.14126.14781157103683840032.idtracker@ietfa.amsl.com>
Date: Thu, 16 Mar 2017 02:27:31 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/lmap/bbZi69xsFwLcQVgxW5LvF_S3k0A>
Subject: [lmap] Benoit Claise's No Objection on draft-ietf-lmap-yang-11: (with COMMENT)
X-BeenThere: lmap@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Large Scale Measurement of Access network Performance <lmap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lmap>, <mailto:lmap-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lmap/>
List-Post: <mailto:lmap@ietf.org>
List-Help: <mailto:lmap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lmap>, <mailto:lmap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Mar 2017 09:27:31 -0000

Benoit Claise has entered the following ballot position for
draft-ietf-lmap-yang-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-lmap-yang/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- No objection to the publication, but the following phrasing puzzles
me.

   It aims to be consistent with the
   LMAP Information Model [I-D.ietf-lmap-information-model].

Actually, the data model is based on information model, right?

>From the charter:
5. The Report protocol and the associated data model: The definition of

how the Report is delivered from a MA to a Collector; this includes a 
Data Model consistent with the Information Model plus a transport 
protocol (to be selected, perhaps REST-style HTTP(s) or IPFIX).

This is reason why the information model is standard track in the
charter.
Therefore the information model must be a normative reference, right?

- one question about the typedefs naming.
It would nice to be able to reuse YANG constructs, typedefs being of
them
We created http://www.yangcatalog.org/yang-search/yang-search.php with
that goal in mind.
	=> insert "identifier"
	=> select typedef
Some of the typedefs are so generically named in LMAP YANG module:
identifier, tag, cycle-number, wildcard, etc.
Do you expect YANG designers to reuse them outside of LMAP? Some of them,
I guess so
Should the other ones be renamed with LMAP in mind. Ex:
lmap-identifier?
In other words, are all the ietf-lmap-common.yang typedef common?


Editorial:
- figure 1
OLD: ietf-lmap-comman.yang
NEW: ietf-lmap-common.yang