Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\))
From: Christian Hopps <chopps@chopps.org>
In-Reply-To: <c6d24aae-267e-1b0e-0602-7e9d2e9d3961@cisco.com>
Date: Tue, 13 Nov 2018 16:05:11 -0500
Cc: Christian Hopps <chopps@chopps.org>, joel jaeggli <joelja@gmail.com>,
 NETMOD Working Group <netmod@ietf.org>,
 draft-ietf-netmod-module-tags.authors@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <A6608120-8F38-4FB6-9B44-BA4D1755264A@chopps.org>
References: <8C4CE813-D0D1-4F4F-B813-B451D9A8D8DF@gmail.com>
 <c6d24aae-267e-1b0e-0602-7e9d2e9d3961@cisco.com>
To: Robert Wilton <rwilton@cisco.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/wo6568CvTMgXqaf0IOeo8ujz6O8>
Subject: Re: [netmod] Confirming draft-ietf-netmod-module-tags-03 consensus
 call
Precedence: list

The servers implement the modules which can have predefined tags from =
the module designer as well as the implementer (vendor) which literally =
cannot come from anywhere *but* the server that implements the module.

This is not what I thought would hold this work up.

Thanks,
Chris.

> On Nov 13, 2018, at 5:58 AM, Robert Wilton <rwilton@cisco.com> wrote:
>=20
> Hi Joel, authors,
>=20
> I have to confess that I didn't have time to review this during the =
last call (but have reviewed/provided comments on previous versions).
>=20
> These comments may be too late, but I will provide them anyway, so =
make of them what you will :-)
>=20
> In summary, I like the idea of tags and I think that they are a good =
fit for classifying YANG models.  In particular, I think that a flexible =
classification of YANG modules is better than a rigid structure that can =
never be changed.
>=20
> For me the one of the great utilities of module tags could be in =
applications like YANG catalog search =
(https://yangcatalog.org/yang-search/).  Being able to search for =
modules by tag seems like it would be a particularly useful thing to be =
able to do.
>=20
> However, I do have some sympathy with Alex's comment, in that it is a =
bit unclear as to benefits of configuring the tag information on the =
devices.  At the moment, the configuration doesn't have any material =
affect on the device, and the only thing that a client can do is read =
back the tag configuration.  Is the intention that the protocols may be =
extended in future to allow filter queries to be based on module tags?
>=20
> So, I am supportive of Alex's comment that it would give the document =
more clarity if some of the specific use cases could be described.
>=20
>=20
> Some other random comments/nits:
>=20
> 1) 6087bis references can be updated to RFC 8407.  Is a reference even =
allowed in the abstract?
>=20
> 2) Abstract: "writing a modules tags" =3D> "writing a module's tags" =
or "writing module tags"
>=20
> 3) The module is YANG 1.1, so RFC 6020 reference can be changed to RFC =
7950.
>=20
> 4) Section 3.4: Should there be a tag prefix for "experimental"? Or =
perhaps this would be "ietf:experimental:<tag-name>" anyway.
>=20
> 5) Section 5.1: It might be useful if the tags were also reported =
under YANG library, e.g. as an augmentation to rfc7895bis.  E.g. this =
would report the same information as "modules-tags/module[name]/tag" =
leaf-list.
>=20
> 6) YANG module: Should you limit the maximum size of a tag? Perhaps to =
255, or 1000 characters.
>=20
> 7) Line length for "The operational view of this list is constructed =
..." looks like it may be too long.
>=20
> 8) Section 7, Guidelines to authors.  I was wondering if this section =
should state that YANG modules SHOULD define standard tags that are =
associated with it.  At the moment, it just states what can be done, =
without providing guidance of what should be done.
>=20
> 9) Section 9.2.  A few more possible categories: discovery protocol, =
vpn, tunnel.  I'm not sure that I particularly like "rfc8199-" as a =
module name, and possibly "classification-" would be better.
>=20
> Apologies for the tardy review comments,
> Rob
>=20
>=20
> On 12/11/2018 16:46, joel jaeggli wrote:
>> During the Thursday nov 8 session of netmod, we asked if there were =
any objections to the publication of the Draft-03 version of =
draft-ietf-netmod-module-tags which addresses comments and concerns =
raised during the WGLC. In the meeting there were none. This commences a =
comment period to confirm that call. As this follows closely on the =
heels of the IETF 103 meeting we=E2=80=99ll let the call run through =
Monday the 26th of November.
>>=20
>> =
https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-module-tags-03.txt=

>>=20
>>=20
>> Thanks
>> Joel
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod