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

[Benoit Claise <[e-mail]>]

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?

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

>
> 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.)
You're maybe right.

Regards, B.
>   
>> Editorial:
>> - figure 1
>> OLD: ietf-lmap-comman.yang
>> NEW: ietf-lmap-common.yang
> Already fixed in my sources.
>
> /js
>