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

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Thu, 16 March 2017 12:20 UTC

Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: lmap@ietfa.amsl.com
Delivered-To: lmap@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C095129471; Thu, 16 Mar 2017 05:20:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZDmQ4jfCI6XD; Thu, 16 Mar 2017 05:20:46 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11060129456; Thu, 16 Mar 2017 05:20:46 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 92DD711D1; Thu, 16 Mar 2017 13:20:44 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id kNNig6BvLGsr; Thu, 16 Mar 2017 13:20:42 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 16 Mar 2017 13:20:44 +0100 (CET)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id F2D4E20038; Thu, 16 Mar 2017 13:20:43 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id T152CE6nnhCX; Thu, 16 Mar 2017 13:20:43 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 87E1820035; Thu, 16 Mar 2017 13:20:42 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 92A353EE7993; Thu, 16 Mar 2017 13:20:47 +0100 (CET)
Date: Thu, 16 Mar 2017 13:20:46 +0100
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Benoit Claise <bclaise@cisco.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-lmap-yang@ietf.org, Dan Romascanu <dromasca@gmail.com>, lmap-chairs@ietf.org, lmap@ietf.org, bill.wu@huawei.com
Message-ID: <20170316122046.GD59698@elstar.local>
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Mail-Followup-To: Benoit Claise <bclaise@cisco.com>, The IESG <iesg@ietf.org>, draft-ietf-lmap-yang@ietf.org, Dan Romascanu <dromasca@gmail.com>, lmap-chairs@ietf.org, lmap@ietf.org, bill.wu@huawei.com
References: <148965645153.14126.14781157103683840032.idtracker@ietfa.amsl.com> <20170316102616.GC59698@elstar.local> <15ca48cf-f407-2fb3-6ce8-dafffa0c1c0e@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <15ca48cf-f407-2fb3-6ce8-dafffa0c1c0e@cisco.com>
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lmap/HG9l4QX5bhMbh1SdFSciQTOZLKY>
Subject: Re: [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
Precedence: list
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 12:20:49 -0000

On Thu, Mar 16, 2017 at 12:47:09PM +0100, Benoit Claise wrote:
> On 3/16/2017 11:26 AM, Juergen Schoenwaelder wrote:
> > On Thu, Mar 16, 2017 at 02:27:31AM -0700, Benoit Claise wrote:
> > > ----------------------------------------------------------------------
> > > 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?
> > I changed this to "It is based on the LMAP Information Model []" in
> > my sources.
> > > >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?
> > I don't quite understand the logic above. That said, I can go either
> > way (means I do not really care whether the reference is in the
> > normative of informative section).
> The question is: which one is the source of truth? The IM or the DM?

When it comes to implementation, I think it is the YANG model you have
to conform to. If the YANG model has a conflict with the information
model somewhere, we need to discuss and resolve this. I do not think
we can state one of them is automatically 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?

I do not care. I leave it up to whoever wants to reuse them to decide.
The definitions are clearly common for the LMAP modules, everything
beyond that is up in the air.

Recall the SnmpAdminString where the name indicates it is for SNMP
adminitrative names but then later it got used in many places as a
common string type supporting UTF-8. Prediction of future use and
encoding that into names is difficult.

> > When you reuse definitions from ietf-lmap-common, they will appear in
> > your YANG module as:
> > 
> >       type lmap:identifier;
> Sure.
> > 
> > Adding lmap to the type name just makes things look unnecessarily
> > ugly:
> ... from a LMAP point of view.
> > 
> >       type lmap:lmap-identifier;
> 
> I come from this angle:
> http://www.yangcatalog.org/yang-search/yang-search.php
> And I search for any identifier typedef I could reuse.
> I would prefer to have typedefs called LMAP-xxx is they're not really
> common.

Obviously, the typedefs were written primarily for LMAP
purposes. However, for all typedefs, I can imagine situations where
they may be reused outside LMAP. The groupings are more likely LMAP
specific but even then I can also imagine that perhaps some future
IPPM modules may want to use them. Predicting future is difficult.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>