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

From: Benoit Claise <[email-masked]>
Date: Thu, 16 Mar 2017 02:27:31 -0700

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 16 Mar 2017 11:26:16 +0100

I changed this to "It is based on the LMAP Information Model []" in
my sources.
 
> 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).

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

---

From: Benoit Claise <[email-masked]>
Date: Thu, 16 Mar 2017 12:47:09 +0100

> normative of informative section).
The question is: which one is the source of truth? The IM or the DM?

> When you reuse definitions from ietf-lmap-common, they will appear in
Sure.
> Adding lmap to the type name just makes things look unnecessarily
... 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.

> which makes this at times a bit painful.)
You're maybe right.

Regards, B.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 16 Mar 2017 13:20:46 +0100

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

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

> I would prefer to have typedefs called LMAP-xxx is they're not really

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

---

From: Benoit Claise <[email-masked]>
Date: Thu, 16 Mar 2017 13:54:21 +0100

Hi Jürgen,
> we can state one of them is automatically right.
You're not helping :-)
"It is based on the LMAP Information Model []" is already good change.
Informative versus normative is a smaller issue IMO.
A small preference for normative, but I'll leave it to the responsible 
AD to decide.

The rest below was discussed. Let's move on.

Regards, Benoit