Re: [netmod] WG adoption poll draft-ietf-netmod-module-tags-02

[Andy Bierman <[e-mail]>]

On Sun, Sep 30, 2018 at 4:28 PM, Anees Shaikh <[e-mail]> wrote:

> I'm afraid I missed the discussion of tags at recent IETF meetings where
> this may have been covered.  In my read of this draft, I'm still not sure
> what the intended use cases are (i.e., is #hashtag ubiquity really the
> primary motivation)?   What is the difference with a tag extension?
>
>

The YANG extension vs. description-stmt issue is related to how the module
author
assigns a module-tag mapping to a module.


Perhaps it's overkill to have a separate use cases draft for such a small
> model, but I think the draft really does need a section or two explaining
> why and how this is envisioned to be used, and what server implementors are
> supposed to do with it.
>


A module-tag provides a 1:N mapping so instead of specifying (e.g.) every
routing module
by name, a tag like "routing" can be used instead.

This mapping allows the tag to be stable even if the modules in the mapping
are not stable.
The mappings can change release to release or server to server.

We have implemented module tags as a new filter type, for get and
get-config operations.,
as well as a rule-type for NACM rules.

I assume the plan is that NETMOD WG would work on the data model and
NETCONF WG
would eventually do the protocol work.



> thanks.
> -- Anees
>
> On Sun, Sep 30, 2018 at 4:15 PM Andy Bierman <[e-mail]> wrote:
>
>>
>>
>> On Sun, Sep 30, 2018 at 1:17 PM, joel jaeggli <[e-mail]> wrote:
>>
>>> On 9/26/18 09:23, Andy Bierman wrote:
>>> >
>>> >
>>> > On Wed, Sep 26, 2018 at 9:09 AM Juergen Schoenwaelder
>>> > <[e-mail]
>>> > <mailto:[e-mail]>> wrote:
>>>
>>> >
>>> > It is even worse than a step backwards.
>>> > The draft specifies a lot of details about module tag conformance
>>> > that needs to be present in the description-stmt.
>>>
>>> this seems like an important issue to square away  before we  move ahead.
>>>
>>>
>> agreed.
>>
>> Also, what does it mean to match a module-tag?
>> There is text that implies it is an opaque string and other text that
>> suggests it is a colon-separated list of terms.
>> It cannot really be both.
>>
>>
>>
>>> > The idea that tools must screen-scrape description statements goes
>>> against
>>> > everything YANG-based management is all about. YANG has extension
>>> > statements, so we don't need to put complex syntax into comments and
>>> > descriptions..
>>>
>>> and parse descriptions for meaning.
>>>
>>
>> So what the choices?
>>
>> 1) IANA
>> 2) YANG extension
>> 3) ad-hoc
>> 4) do nothing
>>
>> IMO IANA has enough to do and it only covers IETF modules anyway, so (1)
>> is out.
>> The current approach is (3).  It is slightly better than (4), but there
>> is nothing
>> preventing every module from declaring the module tags differently.
>> This does not help the YANG reader (#1 priority).
>>
>> Only a YANG extension (or real statement in YANG 2.0) supports all modules
>> in a way that is consistent for all readers.
>>
>>
>>
>>
>>>
>>> > IMO all text about module tag conformance and defining tags in
>>> > description-stmts
>>> > should be removed.  There is no explanation why a standard YANG module
>>> > would define multiple module-tags for the same module in the first
>>> place,
>>> > let alone why each different tag would have different conformance
>>> > requirements.
>>> >
>>> >
>>> >
>>> >     .....
>>> >
>>> >     /js
>>> >
>>> >
>>> > Andy
>>> >
>>>
>>
>> Andy
>>
>>
>>
>>> >
>>> >
>>> >     --
>>> >     Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>>> >     Phone: [phone]         Campus Ring 1 | 28759 Bremen |
>>> Germany
>>> <https://maps.google.com/?q=Campus+Ring+1+%7C+28759+Bremen+%7C+Germany&entry=gmail&source=g>
>>> >     Fax:   [phone]         <https://www.jacobs-university.de/
>>> >
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > netmod mailing list
>>> > [e-mail]
>>> > https://www.ietf.org/mailman/listinfo/netmod
>>> >
>>>
>>>
>>>
>> _______________________________________________
>> netmod mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>