Subject: [netmod] Adoption Poll: draft-rtgyangdt-netmod-module-tags-02

From: joel jaeggli <[email-masked]>
Date: Tue, 6 Feb 2018 15:47:20 -0800

Hi,

This is the start of a *two* week poll on making
draft-rtgyangdt-netmod-module-tags-02 a working group document.  

https://tools.ietf.org/html/draft-rtgyangdt-netmod-module-tags-02

This document was most recently discussed at IETF 100.

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.

This poll ends on February 8.

Thank you!

Joel Jaeggli and IETF NETMOD Co-Chairs

---

From: joel jaeggli <[email-masked]>
Date: Tue, 6 Feb 2018 15:57:01 -0800

Sorry, Feb 20th is the end date for the adoption call.

regards

joel

On 2/6/18 3:47 PM, joel jaeggli wrote:
> document.  If yes, please also feel free to provide comments you'd
> like to see addressed once the document is a WG document.
>
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Jeff Tantsura <[email-masked]>
Date: Tue, 06 Feb 2018 16:01:36 -0800

Yes/support

Hi, 

This is the start of a *two* week poll on making draft-rtgyangdt-netmod-module-tags-02 a working group document.  

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. 

Thank you! 

_______________________________________________ netmod mailing list [email-masked] https://www.ietf.org/mailman/listinfo/netmod

---

From: Andy Bierman <[email-masked]>
Date: Tue, 6 Feb 2018 16:26:14 -0800

Hi,

support starting this work.
The draft avoids discussion of any useful operations based on tags.
Setting and clearing tags is fine, but what about <get-data>?
What about NACM rules based on tags?
If protocol operations using tags are out of scope, then the draft should
say that.

(And don't forget NMDA compliance ;-)

Andy

On Tue, Feb 6, 2018 at 3:47 PM, joel jaeggli <[email-masked]> wrote:

> Hi,
>
> This is the start of a **two** week poll on making
> document.  If yes, please also feel free to provide comments you'd like to
> see addressed once the document is a WG document.
>

---

From: Lou Berger <[email-masked]>
Date: Tue, 6 Feb 2018 19:27:01 -0500

yes/support

no, I don't know of any IPR that applies to this document...

Lou

(as co-author)

---

From: Dean Bogdanovic <[email-masked]>
Date: Tue, 6 Feb 2018 19:38:34 -0500

yes/support

no, I'm not aware of any IPR that applies to this document...

Dean
> On Feb 6, 2018, at 18:57, joel jaeggli <[email-masked]> wrote:
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 7 Feb 2018 00:42:57 +0000

I support netmod WG adoption.
Thanks,
Acee

From: netmod <[email-masked]> on behalf of joel jaeggli <[email-masked]>
Date: Tuesday, February 6, 2018 at 6:58 PM
To: "[email-masked]" <[email-masked]>
Subject: [netmod] Correction, date It ends Feb 20th Re: Adoption Poll: draft-rtgyangdt-netmod-module-tags-02

regards

joel

Hi,

Thank you!

netmod mailing list

[email-masked]<mailto:[email-masked]>

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 07 Feb 2018 09:07:47 +0100 (CET)

Hi,

I support this document as a working group document.

I do have some things to discuss, e.g., should we try to use a
decentralized approach to tags instead of the proposed IANA registry
(as it happens we have a mechanism for decentralized, hierarchical
identifiers available :)   One use case that I would like to solve is
tagging of mutually exclusive sets of modules, e.g., ietf vs
openconfig vs native models.

/martin

---

From: Robert Wilton <[email-masked]>
Date: Wed, 7 Feb 2018 10:37:55 +0000

Hi,

I conditionally support WG adoption of this draft, with the condition 
being that I think that there are technical areas of this draft that 
should be changed (I've mentioned these previously).

My interpretation of the approach currently documented in the draft 
assumes that the tags are treated as a special type of configuration 
that don't quite adhere to normal configuration rules.  In particular, 
the approach assumes that the server will pre-populate the running 
configuration with the server default tags.  A client can then fetch and 
modify these and push them back to the server.  However, I think that 
this approach will both bloat the configuration and violates the 
principal that the contents of the configuration should be owned by the 
client, not the server.  And probably raise various other corner case 
conditions as well (e.g. what do you do if the server software is 
upgraded and the tags change? how do you merge the current client and 
new server defaults together?)

Instead, I think that the tags should make use of the NMDA architecture 
and be treated entirely as regular configuration:
- <operational> would always report the current set of tags in effect 
(system default values, overridden by any tags add/removed/modified via 
configuration).
- <running> would only contain any configured changes to the tags 
(additional tags could be added, or existing tags could be marked as 
being changed or deleted).
- No reset IPC is required, since it is just regular configuration.

I think that the draft should also support NMDA by augmenting YANG 
library bis.

Thanks,
Rob

---

From: Phil Shafer <[email-masked]>
Date: Wed, 7 Feb 2018 13:59:45 -0500

>The draft avoids discussion of any useful operations based on tags.

Nor does it really clearly say "what" is being tagged.  The absract
talks about "used to help classify and organize modules", but the
Introduction lacks any expansion on this.  There's really no clear
problem statement or a clear definition of why we need tags or what
one would use them for.

It would also be helpful to understand why "#hashtag" and the string
format ("ietf:routing", "vendor:super-duper:...") are chosen over
YANG identities.  It seems like identity naming standards and inheritance
would be good features.

Also it's not clear why these would be configurable rather that
controlled by the module author.  I'd rather have the OAM standard
YANG module say something like:

    module ietf-oam {
        import "ietf-category" { prefix ietf-category; }

        identify ietf-oam {
            base ietf-category:ietf-standard;
            description "This module category represents something
                         OAM related.";
        }

        ietf-category:module-category ietf-oam;
        ...
    }

The draft says:

   Implementations that do not support the reset rpc statement (whether
   at all, or just for a particular rpc or module) MUST respond with an
   YANG transport protocol-appropriate rpc layer error when such a
   statement is received.

The entire idea of NETCONF/YANG is that the client _knows_ what it
can safely send instead of tossing spaghetti at the wall until
something sticks.  Avoid programming-by-error-detection, which
creates fragile infrastructure.

Use "feature" to control optional portions of a YANG module.  I'd
suggest one feature for "reset" support and another for "read-only",
since IMHO the idea of someone munging the categories of standard
modules is, well, disconcerting.

"Local" tags are not well explained.  The idea of a user/admin
tagging modules means that something is broken.  Users shouldn't
understand YANG modules.  Users use applications, some of which are
home-grown.  Is "local" appropriate for my "audit interfaces" script?

6.1 is missing the list "module-tags".

9.1 advocates putting vital information in the description string,
which is IMHO not a good idea.  We want to put as much information
in machine-readable format as possible, so I can ask ietf.org
questions like "give me a list of ietf-oam-related yang modules"
and get a nice list.

It also talks about "SHOULD" and "MAY" tags without giving any
clue as to why or when this would be appropriate or useful.

So my vote would be that this document needs some significant work
and expansion before it's a supportable draft.  I think the authors
have more in their heads than they've put into the draft and I'd
like to see the rest of their thoughts.

Thanks,
 Phil

---

From: "Xufeng Liu" <[email-masked]>
Date: Wed, 7 Feb 2018 16:46:45 -0500

yes/support.

Thanks,

- Xufeng

From: netmod [mailto:[email-masked]] On Behalf Of joel jaeggli
Sent: Tuesday, February 6, 2018 6:47 PM
To: NETMOD Working Group <[email-masked]>
Subject: [netmod] Adoption Poll: draft-rtgyangdt-netmod-module-tags-02

Hi, 

Thank you!

---

From: Andy Bierman <[email-masked]>
Date: Wed, 7 Feb 2018 14:02:55 -0800

Hi,

Many good points.
IMO it will be difficult to agree on the details of this draft
without agreeing on the problem statement first.
As a process issue, this seems like an important step.
It is usually handled with WG charter text, but NETMOD
has a free pass on new YANG modules somehow.

I am interested in these tags as a new type of standard selection filter.
It can be applied to data retrieval, NACM rules, YANG push subtree
selection,
and probably many more use-cases.  So the problem statement
might be:

   There is a need for standardized mechanisms to classify YANG data nodes
with tags,
   which can be used in protocol operations to select matching data nodes,
based on tag values.
   This work includes the management and assignment of tags, and their
generalized use
   within protocol operations.

Andy

---

From: Vladimir Vassilev <[email-masked]>
Date: Thu, 8 Feb 2018 01:41:20 +0100

> As a process issue, this seems like an important step.
+1
>    There is a need for standardized mechanisms to classify YANG data 
> nodes with tags,
>    which can be used in protocol operations to select matching data 
> nodes, based on tag values.
A practical usecase example in addition to this text could really help. 
I suspect Phil is right that "the authors
have more in their heads than they've put into the draft" but even with 
this text an example is needed to illistrate the purpose of this work.

Vladimir
>
>
> Andy
>
>
> On Wed, Feb 7, 2018 at 10:59 AM, Phil Shafer <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Andy Bierman writes:
>     <http://ietf.org>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 8 Feb 2018 08:21:13 +0100

+1

>    within protocol operations.

The I-D talks about tags for YANG _modules_, you are talking about
tags for YANG data nodes and you seem to imply that these tags are
associated to instance data and that they can be used in protocol
operations. (And then I note we already have metadata that can be
associated to instance data. And there was Andy's packages work, which
can be seen as another way to tag collections of schema nodes.)

So yes, there is a need to agree on what the problem is that is to be
solved (and to consider how solutions fit into the framework we
already have in place).

/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: Martin Bjorklund <[email-masked]>
Date: Thu, 08 Feb 2018 09:28:42 +0100 (CET)

Hi,

In the light of this discussion, I would like to clarify that my
support is for the problem of tagging *modules*, which I believe this
draft is all about.  I don't think we should extend this to tagging
*nodes*; I think that requires a different mechanism.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 8 Feb 2018 01:12:48 -0800

> *nodes*; I think that requires a different mechanism.
If it is about tagging modules, then the draft should really explain why
this is useful and provide examples of problems
solved with module tags. It can be used to tag all nodes in a module the
same way.
This might be useful granularity for something.

A vendor might also create their own protocol
mechanisms to utilize the standard tag values
and ignoring the rest of this draft.

Andy

> nodes

---

From: "t.petch" <[email-masked]>
Date: Fri, 9 Feb 2018 15:19:40 -0000

Oppose adoption

As others have said, there is a lack of a problem to solve.

When I ask users of a technology that uses #hashtags where they come
from, how they come into being and similar elements of procedure, I
never get an answer.  #hashtags seem to be provided to allow a storm to
gather on social media, around some vague idea, in order to put pressure
on someone or something that would otherwise be unjustified:-)

The tags listed in Section 10.2 seem just as vague and I do not see a
role for something somewhat ill-defined in YANG.

Tom Petch

----- Original Message -----
From: "Phil Shafer" <[email-masked]>
To: "Andy Bierman" <[email-masked]>
Cc: "NETMOD Working Group" <[email-masked]>
Sent: Wednesday, February 07, 2018 6:59 PM
Subject: Re: [netmod] Adoption Poll:
draft-rtgyangdt-netmod-module-tags-02

---

From: Andy Bierman <[email-masked]>
Date: Fri, 9 Feb 2018 13:57:47 -0800

> As others have said, there is a lack of a problem to solve.

Actually, I see eventual value in the tags themselves if:

   - each tag is defined with a YANG identity
   - there is standard filtering based on derived-from-or-self
   - the standard tags are maintained in an IANA module (iana-yang-tags)
   - there is a standard YANG extension yt:module-tag that can be used to
assign
     tags to an entire module
   - there is a standard YANG extension yt:data-tag that can be used to
assign
     tags to a YANG data subtree
   - standard YANG modules include appropriate tagging

IMO it is similar to iana-if-types, which is much better than each vendor or
each operator assigning all the code-points.

It would be a lot of work to come up with a good set of standard tags
but it seems there are people willing to work on that.

Andy

---

From: joel jaeggli <[email-masked]>
Date: Sun, 18 Feb 2018 22:52:41 -0800

Note that this poll ends in a couple days.

thanks
joel

---

From: joel jaeggli <[email-masked]>
Date: Fri, 23 Feb 2018 08:37:12 -0800

This completes the 2 week poll on making
draft-rtgyangdt-netmod-module-tags-02 a working group document.

Response has been generally favorable and enthusiasic with some interest
in signficant changes. We are adopting the document as a working group item.

The authors should submit an updated draft probably with the title
draft-ietf-netmod-module-tags-02.

thanks
joel