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

From: joel jaeggli <[email-masked]>
Date: Tue, 2 Oct 2018 13:21:04 -0700

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.

The prior discussion of my mistaken WG adoption call is here

commences here:

https://www.ietf.org/mail-archive/web/netmod/current/msg21290.html

In particular Andy's concerns expressed in that thread here:

https://www.ietf.org/mail-archive/web/netmod/current/msg21348.html

are probably important to tease out in considering this for last call.

so that we are clear on dates. This last call timing resets and runs
from 10/2/18 - 10/16/18

Joel

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 2 Oct 2018 22:30:31 +0200

> 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: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Alex Campbell <[email-masked]>
Date: Thu, 4 Oct 2018 00:22:08 +0000

Do not support.

This document does not make a good case for why tags should exist.
The introduction does not explain what they are useful for, it just makes a comparison to #hashtags (which is something I would expect to see in an April 1st RFC).
The initial registry values, section 8.2, also provide no insight as to the value of any of these tags. At best these values could be used to categorise modules for human browsing.

In short, I see no evidence that the standard this document attempts to define is actually useful.

Additional major concerns:
- the draft does not indicate who should implement the included YANG module.
- there is no automatic mechanism specified (such as an extension statement) by which the server can read the tags from the module (as 4.1 specifies must happen), therefore the implementer will have to do this manually and is likely to forget.
- I do not believe servers should be concerned with classifying their implemented YANG modules, unless there is a good reason. This seems like a client responsibility. How will the system work in a large network with one client reading data from 500 servers, each of which could have different tag data? Or maybe two clients with different tag data, both trying to update the network to hold the "correct" data.

________________________________________
From: netmod <[email-masked]> on behalf of joel jaeggli <[email-masked]>
Sent: Wednesday, 3 October 2018 9:21 a.m.
To: NETMOD Working Group
Subject: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 10/16/18

You may review at:

commences here:

Joel

---

From: Christian Hopps <[email-masked]>
Date: Tue, 16 Oct 2018 08:04:19 -0400

> 
> On Oct 3, 2018, at 8:22 PM, Alex Campbell <[email-masked]> wrote:
> 
> The introduction does not explain what they are useful for

The second sentence of the abstract: "The expectation is for such tags to be used to help classify and organize modules." The introduction repeats this in the first sentence. I'm not sure how much differently we could say "Tags are useful for organizing and classifying modules". Are you asking for justification on the usefulness of organizing and classifying things? I think this concept is rather widely accepted.

> , it just makes a comparison to #hashtags (which is something I would expect to see in an April 1st RFC).

Using tags to help organize collections of data is literally ubiquitous: Movies/music/media, IP routes, and yes even social media are just a few examples.  Regarding April 1st, are you are unfairly restricting your perspective to only the ironic use of hashtags? Hashtags organically developed as a useful and widely used way for people and groups to add meta-data to their messages which then allowed other services to collect and present them in useful ways. Indeed businesses and other groups use hashtags for this purpose to great success. It was hardly a joke, and for many folks it is immediately useful to understand what is being proposed.

Thanks,
Chris.

---

From: Christian Hopps <[email-masked]>
Date: Tue, 16 Oct 2018 08:31:43 -0400

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

> On Oct 2, 2018, at 4:30 PM, Juergen Schoenwaelder <[email-masked]> wrote:
> 
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 16 Oct 2018 15:08:29 +0200

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

I am personally not convinced. The whole reason why we have YANG is
automation and I believe people will go and write tools to extract
tags and having to extract them out of free form text looks like a
step backwards.

> 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 ta…

I am generally not a fan of definition by example. Is SSH a 'system
management protocol'?

> I think it's good enough. :)

I am not convinced this will work well. My understanding is that other
'hashtags' also have restrictions - whitespace and punctuation
characters are often excluded, it seems. Apparently ':' already means
something special here. Should you later need more special meanings,
you will love to have characters available that you can use. What
about tags that include whitespace or control characters? Do we really
want such tags?

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

OK. One obvious extension is then to have at some point in time tag
match expressions, such as 'vendor:acme:*' (assuming that * is not
a valid character for a tag, see above).

/js

---

From: Andy Bierman <[email-masked]>
Date: Tue, 16 Oct 2018 11:45:07 -0700

On Tue, Oct 16, 2018 at 6:08 AM, Juergen Schoenwaelder <
[email-masked]> wrote:

> > On Oct 2, 2018, at 4:30 PM, Juergen Schoenwaelder <
> [email-masked]> wrote:
>
> > 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.
> >
>

It is more than a step backwards.
There is an unexplained procedure for declaring the  module-tag conformance,
in addition to the module-tag mappings.

All YANG designers are supposed to learn the exact text to write (not
free-form at all)
and this draft updates 6087bis with procedures for declaring the module-tags
in the description-stmt.

Also, tool developers are supposed to parse the description-stmt looking
for the
module-tag definitions. But instead, tool developers are going to say "Use
our
proprietary YANG extension because we are never going to parse description
statements"

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

An example is not a definition.
The IETF is supposed to know the difference.

> about tags that include whitespace or control characters? Do we really

Section 3 defines prefixes for different types of module tags
There is no actual definition of a module tag.
Is it UTF-8 encoding? US-ASCII? Is it structured such that a pattern could
be defined?
Is every protocol draft that uses module-tags somehow going to define their
own version?

I don't see how this draft provides enough interoperability to be useful.

> a valid character for a tag, see above).

Andy

---

From: Christian Hopps <[email-masked]>
Date: Tue, 16 Oct 2018 14:57:01 -0400

> tags and having to extract them out of free form text looks like a

I've now added an "module-tag" extension statement.

> about tags that include whitespace or control characters? Do we really

I *really* want to stay away from over-specifying (over-complicating) this by imposing a lot of structure and rules. The text uses ":"s suggestively, but I'd rather remove that than start down the path of standardizing additional structure.

It probably would be useful to restrict the actual characters used in the string to avoid odd whitespace (e.g., tabs, newlines/carriage returns). Is there a standard type that just leaves these specific whitespace characters out? I was hesitant to just use something like yang identifier b/c I figured it might be useful for people to include non-ascii-like characters (umlats etc..)

Thanks,
Chris.

---

From: Christian Hopps <[email-masked]>
Date: Tue, 16 Oct 2018 15:42:48 -0400

> proprietary YANG extension because we are never going to parse description

I've added the extension statement.

> The IETF is supposed to know the difference.

Do you have some suggestions for text that could replace the examples?

Some of these things seem painful obvious, like do we *really* need to define what we mean by a routing protocol?

Thanks,
Chris.

---

From: Andy Bierman <[email-masked]>
Date: Tue, 16 Oct 2018 13:11:09 -0700

> I've added the extension statement.

good

> Some of these things seem painful obvious, like do we *really* need to
> define what we mean by a routing protocol?
>
>

This draft needs to define the module-tag encoding wrt/
   - valid characters (e.g., some subset of UTF-8)
   - min/max length (e.g., implementation MUST support at least 64 chars
and can support larger)

Section 3 (Tag Prefixes) seems to imply that all modules tags follow a
structure to specify the naming authority.

According to the YANG module, the data type is a plain string, which
includes lots of
problematic chars and zero-length strings.

Does the string "routing" match "ietf:routing" or "vendor:routing"? How
about "routing:bgp"?
Is the char ":" allowed in a tag?
Is "vendor::::::::" a valid tag?

IMO this draft does not need to define any specific module-tag content but
it does need to define
in precise terms how a protocol encodes a module-tag and how a module-tag
match is determined.

Thanks,

Andy

---

From: Christian Hopps <[email-masked]>
Date: Tue, 16 Oct 2018 18:15:29 -0400

>    - min/max length (e.g., implementation MUST support at least 64 chars

I'm looking for suggestions on how to do this subset. We had intended to allow for as wide as possible content; however, I think disallowing tabs, newlines, carriage returns is more than reasonable. Has a type like this already been standardized or is there an example available somewhere?

> Does the string "routing" match "ietf:routing" or "vendor:routing"? How

No. Do we need to state that non-matching strings don't match?

> Is the char ":" allowed in a tag?

Yes, why not?

> Is "vendor::::::::" a valid tag?

Again why not?

The only thing the draft talks about are standard prefixes. Why should a standard enumerate a subset of the unbounded set of things it isn't standardizing? This seems more confusing (why was X included as OK but not Y) than just sticking to what it *is* standardizing.

Perhaps a bit of text saying more explicitly that only the prefix is restricted would help though?

> in precise terms how a protocol encodes a module-tag and how a module-tag

We considered leaving out all the predefined tags, but conversely we also thought it would be useful to establish a base set. We went with the latter obviously. Perhaps it just needs to be trimmed down more?

Thanks,
Chris.

---

From: Alex Campbell <[email-masked]>
Date: Tue, 16 Oct 2018 23:32:25 +0000

I have no issue with systems using tags to classify or organize modules, however this seems to me like something that would be specific to the system doing the classifying.
It would not be something that needs to be specified in the module itself (except perhaps as freeform description text), and it certainly would not need to involve the NETCONF server.
What would a server do with module classification data? (unless it is also implementing some kind of module browsing interface, in which case it might be used to supply the browser with data)

Hashtags - all types, that I'm aware of - are inherently freeform and fluid, changing quickly according to the desires of users. I don't think it makes sense to "hard-code" them in published RFCs or even published vendor modules or firmware.

Tomorrow, I might want to list all modules for management plane protocols. As a network operator, should I go and update the ietf-module-tags on all of my network elements? That seems silly. This should be client-side data. (And if I did, what happens when I add a new router and forget to update its tag data? Will that confuse the client?)

Regards, Alex

________________________________________
From: Christian Hopps <[email-masked]>
Sent: Wednesday, 17 October 2018 1:04 a.m.
To: Alex Campbell
Cc: Christian Hopps; joel jaeggli; NETMOD Working Group
Subject: Re: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 10/16/18

Thanks,
Chris.

---

From: Andy Bierman <[email-masked]>
Date: Tue, 16 Oct 2018 16:39:59 -0700

On Tue, Oct 16, 2018 at 3:15 PM, Christian Hopps <[email-masked]> wrote:

> I'm looking for suggestions on how to do this subset. We had intended to
> allow for as wide as possible content; however, I think disallowing tabs,
> newlines, carriage returns is more than reasonable. Has a type like this
> already been standardized or is there an example available somewhere?
>

I suppose yang-identifier type is too restrictive so I will agree that
restricting whitespace and colon chars
is probably good enough

> No. Do we need to state that non-matching strings don't match?

The official prefixes and colon char lead people to believe the string is
structured.
Intelligent searches on sub-sfields might be purpose of such structure. Or
not I guess.

> Is the char ":" allowed in a tag?

Because it confuses people who think the colon character has special
meaning in this string

> The only thing the draft talks about are standard prefixes. Why should a
> standard enumerate a subset of the unbounded set of things it isn't
> standardizing? This seems more confusing (why was X included as OK but not
> Y) than just sticking to what it *is* standardizing.
>
> We considered leaving out all the predefined tags, but conversely we also
> thought it would be useful to establish a base set. We went with the latter
> obviously. Perhaps it just needs to be trimmed down more?
>

I think the registry details have to be there to populate the IANA
registery

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 17 Oct 2018 08:47:54 +0200 (CEST)

Hi,

Christian Hopps <[email-masked]> wrote:
> I'm looking for suggestions on how to do this subset. We had intended
> to allow for as wide as possible content; however, I think disallowing
> tabs, newlines, carriage returns is more than reasonable. Has a type
> like this already been standardized or is there an example available
> somewhere?
> 

The word "match" is imo problematic.  Use "equal" if that's what you
mean.  But you're not actually using the word "match" in the draft, so
that's fine.  However, I think the draft can be clarified.  See below.

In this case, it _seems_ like there's some hierarchy with tags
like:

  ietf:routing
  ietf:routing:rib

For example, does ietf:routing:rib imply ietf:routing?

>From your last emails, it seems that the idea is that tags are really
just strings with the only property that they can be compared for
equality.  If this is the case, I think it can be made more clear in
the document.  And if this is the case, I think that type "string" is
actually fine.  If someone wants to assign the tag
"vendor:acme::::::::: ", let them.

OTOH, if the idea is that the tags are hierarchical, and
ietf:routing-rib implies ietf:routing, then a more specific type is
needed, and more text.

/martin

> The only thing the draft talks about are standard prefixes. Why should
> a standard enumerate a subset of the unbounded set of things it isn't
> standardizing? This seems more confusing (why was X included as OK but
> not Y) than just sticking to what it *is* standardizing.
> 
> We considered leaving out all the predefined tags, but conversely we
> also thought it would be useful to establish a base set. We went with
> the latter obviously. Perhaps it just needs to be trimmed down more?
> 
> Thanks,
> Chris.
> 
> >
> >
> > Thanks,
> >> Chris.
> >>
> >
> > Andy
>

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 17 Oct 2018 08:52:24 +0200 (CEST)

Alex Campbell <[email-masked]> wrote:
> I have no issue with systems using tags to classify or organize
> modules, however this seems to me like something that would be
> specific to the system doing the classifying.
> It would not be something that needs to be specified in the module
> itself (except perhaps as freeform description text), and it certainly
> would not need to involve the NETCONF server.
> What would a server do with module classification data?

It would use it to populate the "/module-tags" list in the operational
state, where operators can read the tags.

/martin

> (unless it is
> also implementing some kind of module browsing interface, in which
> case it might be used to supply the browser with data)
> 
> Hashtags - all types, that I'm aware of - are inherently freeform and
> fluid, changing quickly according to the desires of users. I don't
> think it makes sense to "hard-code" them in published RFCs or even
> published vendor modules or firmware.
> 
> Tomorrow, I might want to list all modules for management plane
> protocols. As a network operator, should I go and update the
> ietf-module-tags on all of my network elements? That seems silly. This
> should be client-side data. (And if I did, what happens when I add a
> new router and forget to update its tag data? Will that confuse the
> client?)
> 
> Regards, Alex
> 
> The second sentence of the abstract: "The expectation is for such tags
> to be used to help classify and organize modules." The introduction
> repeats this in the first sentence. I'm not sure how much differently
> we could say "Tags are useful for organizing and classifying
> modules". Are you asking for justification on the usefulness of
> organizing and classifying things? I think this concept is rather
> widely accepted.
> 
> 
> Using tags to help organize collections of data is literally
> ubiquitous: Movies/music/media, IP routes, and yes even social media
> are just a few examples.  Regarding April 1st, are you are unfairly
> restricting your perspective to only the ironic use of hashtags?
> Hashtags organically developed as a useful and widely used way for
> people and groups to add meta-data to their messages which then
> allowed other services to collect and present them in useful
> ways. Indeed businesses and other groups use hashtags for this purpose
> to great success. It was hardly a joke, and for many folks it is
> immediately useful to understand what is being proposed.
> 
> Thanks,
> Chris.
>

---

From: Christian Hopps <[email-masked]>
Date: Wed, 17 Oct 2018 04:56:05 -0400

The point is to keep this open to however the community might end up choosing to use it. The act of pre-defining tags doesn't disallow other tags being defined, in fact at this point I've sent a bunch of email defending leaving things as open as possible. They both can co-exist. :)

Thanks,
Chris.

> On Oct 16, 2018, at 7:32 PM, Alex Campbell <[email-masked]> wrote:
> 

Sure we support this. That's what user tag configuration is there for.

> What would a server do with module classification data? (unless it is also implementing some kind of module browsing interface, in which case it might be used to supply the browser with data)

The server implements the tags (at least the predefined ones), and the use cases that come to my mind at least involve clients not servers. I'm not saying there wouldn't be a server use case, but it's not as obvious to me. 

And yes implementing some kind of module browsing interface (which could group modules by tags) is a fine example of how tags can be used.

> Tomorrow, I might want to list all modules for management plane protocols. As a network operator, should I go and update the ietf-module-tags on all of my network elements? That seems silly. This s…

I'm a bit confused by this. Not having to go add e.g., an "OAM" tag to modules is exactly the point of pre-defined tags, but you questioned their value at the top of your mail.

Either way configuring a newly installed router is a given, I don't think this is the place to solve the "forgot to add all the config to my new router install" issue. :) If one is using tags in ones network then making sure the newly installed router has tags configured the way you expect is no different from making sure that you configured IS-IS correctly.

Thanks,
Chris.

---

From: Christian Hopps <[email-masked]>
Date: Wed, 17 Oct 2018 05:45:41 -0400

> On Oct 17, 2018, at 2:47 AM, Martin Bjorklund <[email-masked]> wrote:
> 
> Hi,
> 

I'm going to remove the colons (except for the one in the prefix). This has caused a lot of confusion. It is as you say supposed to be free-form after the prefix. Yes, there was an implied structure being suggested, but there was no intention to try and standardize this structure. In the end it comes off as half-baked and confusing so better to remove it.

FWIW I originally envisioned a more flat tag space anyway, so ietf:routing and ietf:igp. I'm not sure how we ended up suggesting hierarchy. 

Thanks,
Chris.

---

From: Christian Hopps <[email-masked]>
Date: Wed, 17 Oct 2018 05:49:30 -0400

> On Oct 16, 2018, at 7:39 PM, Andy Bierman <[email-masked]> wrote:
> 
> 
> 
> I suppose yang-identifier type is too restrictive so I will agree that restricting whitespace and colon chars
> is probably good enough 

I'm going to use:

  typedef tag {
    type string {
      pattern '[a-zA-Z_][a-zA-Z0-9\-_]*:[\S ]+';
      length "1..max";
    }
    description
      "A tag value is composed of a standard prefix followed
       by any string value that does not include carriage return,
       form-feed, newline or tab characters."
  }

I left in space -- lot's of people in the non-unix world use spaces.

Thanks,
Chris.

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 17 Oct 2018 12:42:26 +0200 (CEST)

>       pattern '[a-zA-Z_][a-zA-Z0-9\-_]*:[\S ]+';

Ok.  Note that the legal characters in "string" are different in YANG
version 1 and 1.1, so this is a good reason (theoretical perhaps) to
use 1.1.

I do think that this module should be 1.1.  A number of fixes were
done in 1.1, and unless there are strong reasons not to use 1.1, you
should use it.  The string type is one example, and the effect on the
size of <hello> in NETCONF is another.

/martin

---

From: Alex Campbell <[email-masked]>
Date: Wed, 17 Oct 2018 21:55:43 +0000

Hi,

> The server implements the tags (at least the predefined ones), and the use cases that come to my mind at least involve clients not servers.

I assume that the server here is a network element implementing ietf-module-tags.

I still don't see why network elements should implement ietf-module-tags.
What benefit is gained from storing the tags on the server instead of the client? It seems backwards.

Have I misunderstood? I assumed that ietf-module-tags was meant to be implemented by network elements that are NETCONF servers - but now I see the document doesn't actually specify who is meant to implement the module. Your comment about newly installed routers supports my understanding however.

> I'm a bit confused by this. Not having to go add e.g., an "OAM" tag to modules is exactly the point of pre-defined tags, but you questioned their value at the top of your mail.

The problem with pre-defined tags is that they are never complete. I can always find a useful tag that is not pre-defined.

> Either way configuring a newly installed router is a given, I don't think this is the place to solve the "forgot to add all the config to my new router install" issue. :) If one is using tags in on…

The reason I find this problematic is the same as above - that the router has no use for the tag data.
It's as if my PC were to download its keyboard mapping table from my home router. Then I change ISPs and have to swap the router, and suddenly my keyboard doesn't work correctly.
It would be much better to store the keyboard mapping table for my PC *on my PC* instead of adding needless external dependencies.

Alex

Sent: Wednesday, 17 October 2018 9:56 p.m.

Thanks,
Chris.

Thanks,
Chris.

---

From: Christian Hopps <[email-masked]>
Date: Thu, 18 Oct 2018 06:16:52 -0400

A router has no use for it's capability/feature/deviation advertisements either; module-tags are no different in this respect.

Thanks,
Chris.

---

From: Alex Campbell <[email-masked]>
Date: Thu, 18 Oct 2018 21:51:37 +0000

Capabilities, features and deviations indicate the type of requests the router can respond to.

The capability advertisement may not affect the router, but the capability itself directly does.
The capability advertisement tells the client that the router can answer requests involving the capability in question.

Will clients base their behaviour on module tags, such as fetching all modules with a particular tag?
In that case, as a vendor, I do not understand the implications of adding or removing a tag and I would prefer if the RFC was clearer on that point.

________________________________________
From: Christian Hopps <[email-masked]>
Sent: Thursday, 18 October 2018 11:16 p.m.
To: Alex Campbell
Cc: Christian Hopps; joel jaeggli; NETMOD Working Group
Subject: EXTERNAL: Re: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 10/16/18

Thanks,
Chris.

---

From: Joel Jaeggli <[email-masked]>
Date: Thu, 25 Oct 2018 00:05:02 -0700

This WG LC closed on the 16th. 

Working group last calls serve a useful forcing function even for drafts that may end up looking unready as a result due to the attention. If I am making a judgement call here based on the feedback received during this period and the prior one.

I will try and summarize the major concerns that  see expressed with this draft.

Jurgen had a significant list of comments and edits

https://mailarchive.ietf.org/arch/msg/netmod/qUGyGIxHJKsEXZsG6r3P7R0nirg <https://mailarchive.ietf.org/arch/msg/netmod/qUGyGIxHJKsEXZsG6r3P7R0nirg>

Followed up by Christian

One detail teased out there and in other comments bears revisting

            Juergen

> movement backwards.

Christian

Juergon

Andy 

Alex

I have no issue with systems using tags to classify or organize modules, however this seems to me like something that would be specific to the system doing the classifying. It would not be something that needs to be specified in the module itself (except perhaps as freeform description text), and it certainly would not need to involve the NETCONF server. What would a server do with module classification data? (unless it is also implementing some kind of module browsing interface, in which case it might be used to supply the browser with data)

Wether or not this is intended for or will be parsed by machines remains a significant unresolved concern. The actual mechanics of restricting what goes into them however seems fairly straight forward.

Absent consensus on the above concern this document cannot probably advance, we do have the opportunity for significant face to face discussion in the near future so using that to arrive at a conclusion would probably allow this work to progress or stop.

Thanks
Joel

> On Oct 2, 2018, at 13:21, joel jaeggli <[email-masked]> wrote:
>

---

From: Christian Hopps <[email-masked]>
Date: Thu, 25 Oct 2018 09:12:32 -0400

Hi Joel, WG,

I published a new draft some days ago covering the specific concerns and editorial changes requested during WGLC. This included the addition of an extension statement which covered machine parsing of pre-defined tags which was mentioned by multiple people, and is the only significant change made. I would think we'd have rough consensus (at least) at this point.

I do not agree that we should restrict the usefulness of this work by removing the ability of the module author or the vendor/implementer to add tags due to a single persons view of how they might use the technology. There's nothing gained, and there's obvious loss of functionality.

Thanks,
Chris.

> On Oct 25, 2018, at 3:05 AM, Joel Jaeggli <[email-masked]> wrote:
>

---

From: Joel Jaeggli <[email-masked]>
Date: Thu, 25 Oct 2018 15:57:30 -0700

> On Oct 25, 2018, at 06:12, Christian Hopps <[email-masked]> wrote:
> 
> Hi Joel, WG,
> 

Yes, I don’t think we need to belabor the edits since I think that discussion tailed of to a reasonable conclusion.

> I do not agree that we should restrict the usefulness of this work by removing the ability of the module author or the vendor/implementer to add tags due to a single persons view of how they might…

I’m trying not to inject my own opinion into prejudging an outcome here. 

I do see it as significant point of contention in the working group last call. If I were asking for consensus on the point specifically I do not believe that we have arrived at a point of rough consensus yet.

> Thanks,

Thanks for getting us to this point.

Joel

---

From: Christian Hopps <[email-masked]>
Date: Fri, 26 Oct 2018 00:38:41 -0400

> Will clients base their behaviour on module tags, such as fetching all modules with a particular tag?

It depends on what the tag/meta-data is! This is a way to add meta-data, but we aren't restricting or strictly defining how one will *use* the meta-data on purpose. Tags are meant to be a tool that can be used in many ways even some yet unimagined ways.

> In that case, as a vendor, I do not understand the implications of adding or removing a tag and I would prefer if the RFC was clearer on that point.

So as a vendor don't add or remove tags you don't understand.

This is a general purpose tool we are adding here, the ability to associate tag/meta-data with a module. There are some uses that we can think of now (e.g., from the definition side classifying the origin of a module as IETF or OpenConfig, or from the client side marking a module as "dontuse" for an NMS b/c they found bugs with it on a given device. And there will be uses that are dreamt up later.

The point here is to put in place a way to associate tags with modules, not to restrict how they are used.

Thanks,
Chris.