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