Hi,
I think there are some legitimate issues that should be addressed for this
work to go forward
wrt/ how it will be used.
1) IANA registry: is this really needed at all? Doesn't the module-tag
extension
make the registry unnecessary?
2) Standard solution: will there be one or is the intent to have
proprietary solutions
to actually utilize module-tags?
3) If there is going to be a standard protocol solution to use module-tags,
then is it
really wise to nail down the tag format before starting work on mechanisms
that use
module tags?
4) How do I distinguish openconfig from mef from bbf from my router vendor?
All their tags seem to share the same prefix "vendor:" What if I want to
match all routing modules? Then the prefix actually gets in the way because
I have to specify 3 tags ("ietf:routing", "vendor:routing" and
"user:routing")
5) Who decides what module tags apply to a new IETF YANG module?
Is it each independent WG? A design team? The IESG? What guidelines exist
for reviewers to determine if the correct module tags have been assigned?
I do not agree this work is being held up because there is no way to use
a module-tag with any standard protocols.
Andy
On Wed, Nov 14, 2018 at 8:44 AM Christian Hopps <[email protected]> wrote:
>
>
> > On Nov 14, 2018, at 10:14 AM, Robert Wilton <[email protected]> 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".
>
> 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.
>
> 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 <[email protected]> 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 <[email protected]>
> 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
> >>>>>> [email protected]
> >>>>>> https://www.ietf.org/mailman/listinfo/netmod
> >>>>> _______________________________________________
> >>>>> netmod mailing list
> >>>>> [email protected]
> >>>>> https://www.ietf.org/mailman/listinfo/netmod
> >>>> .
> >> .
>
> _______________________________________________
> netmod mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/netmod
>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
