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 10:26 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 2A270127333; Thu, 16 Mar 2017 03:26:17 -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 t1547mIzXOkz; Thu, 16 Mar 2017 03:26:15 -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 5634F127097; Thu, 16 Mar 2017 03:26:15 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 23D36375; Thu, 16 Mar 2017 11:26:14 +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 lfTJuq-Gj5rM; Thu, 16 Mar 2017 11:26:12 +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 11:26:13 +0100 (CET)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8E10920035; Thu, 16 Mar 2017 11:26:13 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id L6EpQ7W0lbYc; Thu, 16 Mar 2017 11:26:12 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9AA4A20038; Thu, 16 Mar 2017 11:26:11 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id E2C063EDBDBE; Thu, 16 Mar 2017 11:26:16 +0100 (CET)
Date: Thu, 16 Mar 2017 11:26:16 +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: <20170316102616.GC59698@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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <148965645153.14126.14781157103683840032.idtracker@ietfa.amsl.com>
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lmap/oMk-PybWXy1NX6bSRVBg81zQSpA>
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 10:26:17 -0000

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

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

When you reuse definitions from ietf-lmap-common, they will appear in
your YANG module as:

     type lmap:identifier;

Adding lmap to the type name just makes things look unnecessarily
ugly:

     type lmap:lmap-identifier;

I am not sure it is useful to speculate who might be reusing what in
the future. I would rather keep an eye on things and if we observe
that definitions get reused or duplicated, consider moving these
definitions into a common place (ietf-yang-types, ietf-inet-types)
since I do understand that people prefer to not depend on definitions
contained in some arbitrary YANG modules where maintenance may be less
clear over time. It may not be bad to spin the common yang types
document every ~3 years. (But then I also recall that last time the
nitpicking during the approval process was on types that already
existed in the first revision and not on the stuff that was added,
which makes this at times a bit painful.)
 
> Editorial:
> - figure 1
> OLD: ietf-lmap-comman.yang
> NEW: ietf-lmap-common.yang

Already fixed in my sources.

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