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

[Juergen Schoenwaelder <[e-mail]>]

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: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <http://www.jacobs-university.de/>