On 14/11/2018 16:43, Christian Hopps wrote:
On Nov 14, 2018, at 10:14 AM, Robert Wilton <rwil...@cisco.com> wrote:
Hi Chris,
On 14/11/2018 13:46, Christian Hopps wrote:
Do you have similar objections over comments in CLI config files?
No, not at all.
But one difference here is that the tags are bound to modules, not to the
config, or config paths.
This has nothing to do with the point I am addressing that you and Alex raised regarding
"Servers not using the tags so why should they store them".
My point was not that "servers shouldn't have to do this", but more "it
is isn't obvious why operators want servers to do this".
The answer is:
1) B/c there's literally no where else they could be stored (no way for a
vendor to add tags)
2) There are other examples of servers storing things they don't use like comments, so
"server not using what it stores" isn't a reason to not store them on the
server in the first place.
Regarding the rest. Maybe we should write a requirements draft and a use cases
draft for the use of meta-data/tags for organizing things.
That is not what I was suggesting.
I was suggesting text something like this:
Introduction:
OLD:
The use of tags for classification and organization is fairly ubiquitous
not only within IETF protocols, but in the internet itself (e.g.,
#hashtags). Tags can be usefully standardized, but they can also serve
as a non-standardized mechanism available for users to define
themselves. Our solution provides for both cases allowing for the most
flexibility. In particular, tags may be standardized as well as assigned
during module definition; assigned by implementations; or dynamically
defined and set by users.
NEW:
The use of tags for classification and organization is fairly ubiquitous
not only within IETF protocols, but in the internet itself (e.g.,
#hashtags). One benefit of using tags for organization over a rigid
structure is that it is more flexible and can more easily adapt over
time as technologies evolve. Tags can be usefully standardized, but they
can also serve as a non-standardized mechanism available for users to
define themselves. This document provides a mechanism to define tags and
associate them with YANG modules in a flexible manner. In particular,
tags may be standardized as well as assigned during module definition;
assigned by implementations; or dynamically defined and set by users.
NEW: 1.1 Some example use cases of YANG module tags
Tags can be used to help filter different discrete categories of YANG
modules supported by a device. E.g., if modules are suitably tagged,
then an XPath query can be used to list all of the vendor modules
supported by a device.
Tags can also be used to help coordination when multiple
semi-independent clients are interacting with the same devices. E.g.,
one management client could mark that some modules should not be used
because they have not been verified to behave correctly, so that other
management clients avoid querying the data associated with those modules.
Tag classification is useful for users searching module repositories
(e.g. YANG catalog). A query restricted to the 'ietf:routing' module tag
could be used to return only the IETF YANG modules associated with
routing. Without tags, a user would need to know the name of all the
IETF routing protocol YANG modules.
Future management protocol extensions could allow for filtering queries
of configuration or operational state on a server based on tags. E.g.,
return all operational state related to system-management.
If you think that this text is helpful, and it allowed, then please add
it, refining as required. If you think that it detracts from the
clarify of document, and is superfluous then leave it out, that is also
fine with me ...
Thanks,
Rob
And maybe let's put this work on hold until we can find someone that is willing
to do all that busy work.
I understand more and more why openconfig exists.
Thanks,
Chris.
Routers (the server) certainly don't use those and clients write them and
read them -- yet they are stored on the server. Perhaps if you thought of there
being more than just one client possible this might all make more sense?
Yes, perhaps.
Regarding the yang library you keep bringing up. This was in the work
originally and the WG decided that we should remove it.
Sorry, I had missed the WG discussion where this was removed. But OK.
I do not think the tail end of a WGLC is an appropriate time or place to
start wondering out loud about whether it would be a good to have. I admit to
being confused by this since I believe you were actively participating WRT this
work when it had the yang library augmentation as well as after we removed it.
My apologies, but I had intended to review this more thoroughly during the WG
LC but ran out of time. If was when I read Alex's comments that I thought that
he was raising some valid points. The key one that struck a chord is that this
document describes a solution but doesn't seem to clearly describe what problem
it is solving (other than tags are good), or how it is intending to be used.
When I reviewed this document after reading Alex's comments, I was asking
myself how this was going to be used, and the answer I came up with was that I
didn't really know. Or the case that I had in mind (YANG catalog filtering on
module tag) doesn't seem to match the authors envisaged use cases. Looking
back at some of the previous comments on this work (not just Alex), others have
also questioned what problem it is solving and how it will be used.
I'm OK with taking the editorial suggestions. I'm not so OK with going back and
redoing this document or it's fundamental design at the tail end of a WGLC.
Unless the WG agrees that it's truly broken. This would be pretty odd given it
seemed like we were done, including during the 103 meeting in which you were in
attendance.
You say your not trying to hold the work up; however, that is exactly what your
last minute public pondering is doing.
Yes, I admit that I should have reviewed it earlier. My aim is not to slow it
down but to ensure that the document is as clear as possible. As I've said
lots of times, I like the idea of tags for classifying YANG modules :-)
Given all that, it is still my opinion that this document would benefit from
the introduction being slightly clearer on the specific problem being solved -
e.g. I think that the abstract is more clear than the introduction, and also
think that the document would benefit having some examples of how module tags
could be used.
But I appreciate that my comments are after the WGLC and have no issues if the
authors/chairs decide that they are too late. After all, no one else, other
than Alex, has expressed any concern.
Thanks,
Rob
Thanks,
Chris.
On Nov 14, 2018, at 5:04 AM, Robert Wilton <rwil...@cisco.com> wrote:
Hi Chris,
On 13/11/2018 21:05, Christian Hopps wrote:
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.
Clients should also be able to know find out the predefined tags from the
module definition. I agree that the any tags added by the implementation can
only be known by querying the server, although its not obvious to me what those
tags would be. E.g. if Cisco had a YANG module for EIGRP and wanted to give it
the ietf:protocol and ietf:routing tag then it would ideally use the extension
and put it in the YANG file.
This is not what I thought would hold this work up.
Sorry, I'm not trying to hold anything up.
It not obvious to me how the ietf-module-tags modules will actually be used on
a device:
1) being able to ask a device: "What are all the YANG modules that are implemented
on this device that are routing protocols" seems a useful thing to do. Although
personally I would ideally want the answer in the context of YANG library. I.e. to see
the modules with the given tags, along with module evision/version, features and any
deviations. This can probably be achieved today with an appropriate xpath query, if
supported, or could perhaps be achieved more easily if the operational list of tags also
augmented the module entries in the YANG library structure. But perhaps for your
envisaged use case just getting back the list of modules with that tag is sufficient and
is what you are after.
Is this how you are envisaging YANG module tags would be used, and if so, would
it do any harm to add a short section near the intro explaining this (and
perhaps the YANG catalogue example as well)? Or do you think that this would
just be needless noise.
2) Being able to filter queried data based on tags may also be useful, but this
would require protocol extensions, perhaps something to be done in future?
Thanks,
Rob
Thanks,
Chris.
On Nov 13, 2018, at 5:58 AM, Robert Wilton <rwil...@cisco.com> wrote:
Hi Joel, authors,
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).
These comments may be too late, but I will provide them anyway, so make of them
what you will :-)
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.
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.
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?
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.
Some other random comments/nits:
1) 6087bis references can be updated to RFC 8407. Is a reference even allowed
in the abstract?
2) Abstract: "writing a modules tags" => "writing a module's tags" or "writing
module tags"
3) The module is YANG 1.1, so RFC 6020 reference can be changed to RFC 7950.
4) Section 3.4: Should there be a tag prefix for "experimental"? Or perhaps this would be
"ietf:experimental:<tag-name>" anyway.
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.
6) YANG module: Should you limit the maximum size of a tag? Perhaps to 255, or
1000 characters.
7) Line length for "The operational view of this list is constructed ..." looks
like it may be too long.
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.
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.
Apologies for the tardy review comments,
Rob
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’ll let the call run through Monday the 26th of November.
https://tools.ietf.org/rfcdiff?url2=draft-ietf-netmod-module-tags-03.txt
Thanks
Joel
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
.
.
.
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
