Re: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 10/16/18

[Christian Hopps <[e-mail]>]

On Oct 2, 2018, at 4:30 PM, Juergen Schoenwaelder <[e-mail]> wrote:
> Not ready, comments posted earlier here:
> 
> https://mailarchive.ietf.org/arch/msg/netmod/qUGyGIxHJKsEXZsG6r3P7R0nirg


Hi Re-quoting to keep the discussion on this thread.

> - What does this mean? In particular the second sentence makes me wonder.
> 
>   Implementations MUST ensure that a modules tag list is consistent
>   across any location from which the list is accessible.  So if a user
>   adds a tag through configuration that tag should also be seen when
>   using any augmentation that exposes the modules tag list.

This text exists b/c originally the module tags list was being proposed to be accessible in 2 places, with a read-only version in a yang library augmentation. The WG decided that this read-only augmentation was not useful so we removed. It.  I'll remove this text as it's now more confusing than useful apparently. :)

> - Wording - suggest to remove 'types':
> 
>    Tags may be IANA assigned or privately defined types.";

Done.

> - Leaf names:
> 
>   module: ietf-module-tags
>       +--rw module-tags* [name]
>          +--rw name          yang:yang-identifier
>          +--rw tag*          string
>          +--rw masked-tag*   string
> 
>   Name seems to refer to a module but this is not clear until you
>   read the description. I understand that in RFC 7895 and its bis we
>   also just use 'name' but I would find things easier to understand
>   if we would have this:
> 
>   module: ietf-module-tags
>       +--rw module-tags* [module]
>          +--rw module        yang:yang-identifier
>          +--rw tags*         string
>          +--rw masked-tags*  string
> 
>   Note that I also used plural for the leaf-lists.
> 
>   In the description, I would also say "A list of tags associated
>   with..."  instead of "A tag associated with...".

I'll change it to module-name, and pluralize "tag" to "tags".

> 
> - Editorial
> 
>  s/This user/A user

Done

> - Adding and masking the same tag
> 
>  What happens if config adds a tag and masks the same tag? Is the
>  masking taking priority in this case, i.e., you first all all tags
>  and then you filter those that are masked?

The mask takes precedence. I'll add text to clarify this.

> - Standard tags defined in description statements
> 
>  I do not like this. YANG has extension statements and having to
>  parse stuff out of free text description statements seems to be a
>  movement backwards.

This is used by the human implementer of the module (i.e., they need to write code to implement the module). As such it was not intended for machine parsing.

> - System management
> 
>  What is 'system management' and a 'system management protocol'?

These were derived from the work the RtgYangDT originally did where we were organizing everything under a single device tree. This tree concept was (rightly) abandoned to be replaced with use of tags. Examples of protocols would be Syslog, TACAC+, SNMP, Netconf, ... I've added that to the description.
 
> - Tag format
> 
>  Apparently, the colon has a special meaning in a tag string and
>  otherwise there do not seem to be any restrictions. (Which is good,
>  I can finally put various smileys on my gear.)
> 
>  Should we state explicitly somewhere that a colon has a special
>  meaning and that tag strings are structured into a sequence of
>  'taggies' separated by colons? Or is definition by example good
>  enough?

I think it's good enough. :)

> - Meaning of tag masks
> 
>  Do masks mean a complete string match or can I mask along the prefix
>  hierarchy, i.e., 'vendor:acme:' masks everything starting with
>  'vendor:acme:'?

Exact match, I've added text to clarify this.

> 
> - Retrieval of the final list of tags
> 
>  Once I have configured tags and masks, how do I obtain the resulting
>  tag list? Do I have to calculate this locally? Or will the final
>  list be found in the operational state datastore (i.e., the applied
>  config

No need to calculate locally, and yes the final list is found in operational state datastore.

The description of the "tags" list includes the following text:

             The operational view of this list will contain all
             user-configured tags as well as any predefined tags that
             have not been masked by the user using the masked-tag leaf
             list below.";

Thanks,
Chris.

> 
> /js
> 
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <https://www.jacobs-university.de/>





> On Oct 2, 2018, at 4:30 PM, Juergen Schoenwaelder <[e-mail]> wrote:
> 
> On Tue, Oct 02, 2018 at 01:21:04PM -0700, joel jaeggli wrote:
>> This is start of a two week working group last-call for
>> draft-ietf-netmod-module-tags-02 a current netmod working group
>> document.
>> 
>> You may review at:
>> https://tools.ietf.org/html/draft-ietf-netmod-module-tags-02
>> 
>> Please send email to the list indicating "yes/support" or "no/do not
>> support".  If indicating no, please state your reservations with the
>> document.  If yes, please also feel free to provide comments you'd like
>> to see addressed once the document is a WG document.
> 
> Not ready, comments posted earlier here:
> 
> https://mailarchive.ietf.org/arch/msg/netmod/qUGyGIxHJKsEXZsG6r3P7R0nirg
> 
> /js
> 
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <https://www.jacobs-university.de/>
> 
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
>