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

From: joel jaeggli <[email-masked]>
Date: Wed, 26 Sep 2018 08:40:46 -0600

This is start of a two week poll on making
draft-ietf-netmod-module-tags-02 a 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.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 26 Sep 2018 14:42:03 +0000

Yes/support
Thanks,
Acee

On 9/26/18, 10:41 AM, "netmod on behalf of joel jaeggli" <[email-masked] on behalf of [email-masked]> wrote:

    You may review at:

---

From: Robert Wilton <[email-masked]>
Date: Wed, 26 Sep 2018 15:51:13 +0100

Yes/support.

Thanks,
Rob

On 26/09/2018 15:40, joel jaeggli wrote:
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Andy Bierman <[email-masked]>
Date: Wed, 26 Sep 2018 07:55:44 -0700

> draft-ietf-netmod-module-tags-02 a NetMod working group

I think we did this step already.
https://www.ietf.org/mail-archive/web/netmod/current/msg20344.html

Otherwise how would the draft be named draft-ietf-netmod?
Maybe you mean to start a WGLC, which I also support.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 26 Sep 2018 18:09:42 +0200

> Maybe you mean to start a WGLC, which I also support.

While we figure out what the action is, here are a few quick review
comments:

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

- Wording - suggest to remove 'types':

    Tags may be IANA assigned or privately defined types.";

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

- Editorial

  s/This user/A user

- 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?

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

- System management

  What is 'system management' and a 'system management protocol'?

- 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?

- 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:'?

- 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

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Andy Bierman <[email-masked]>
Date: Wed, 26 Sep 2018 09:23:09 -0700

On Wed, Sep 26, 2018 at 9:09 AM Juergen Schoenwaelder <
[email-masked]> 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.

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.

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.

> .....

Andy

---

From: joel jaeggli <[email-masked]>
Date: Sun, 30 Sep 2018 13:17:41 -0700

On 9/26/18 09:23, Andy Bierman wrote:
> 
> 
> On Wed, Sep 26, 2018 at 9:09 AM Juergen Schoenwaelder
> <[email-masked]
> <mailto:[email-masked]>> wrote:

> that needs to be present in the description-stmt.

this seems like an important issue to square away  before we  move ahead.

> descriptions..

and parse descriptions for meaning.

---

From: Andy Bierman <[email-masked]>
Date: Sun, 30 Sep 2018 16:15:42 -0700

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

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

Andy

---

From: Anees Shaikh <[email-masked]>
Date: Sun, 30 Sep 2018 16:28:21 -0700

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?

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.

thanks.
-- Anees

On Sun, Sep 30, 2018 at 4:15 PM Andy Bierman <[email-masked]> wrote:

> IMO IANA has enough to do and it only covers IETF modules anyway, so (1)
> is out.

---

From: Andy Bierman <[email-masked]>
Date: Sun, 30 Sep 2018 16:57:29 -0700

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

> why and how this is envisioned to be used, and what server implementors are

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.

>> The current approach is (3).  It is slightly better than (4), but there
>> is nothing
>>> <https://maps.google.com/?q=Campus+Ring+1+%7C+28759+Bremen+%7C+Germany&entry=gmail&source=g>
>>> >     Fax:   +49 421 200 3103         <https://www.jacobs-university.de/
>>> >
>>> >
>>> >
>>> >