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