On Sun, Sep 30, 2018 at 4:28 PM, Anees Shaikh <aasha...@google.com> wrote:
> I'm afraid I missed the discussion of tags at recent IETF meetings where > this may have been covered. In my read of this draft, I'm still not sure > what the intended use cases are (i.e., is #hashtag ubiquity really the > primary motivation)? What is the difference with a tag extension? > > The YANG extension vs. description-stmt issue is related to how the module author assigns a module-tag mapping to a module. Perhaps it's overkill to have a separate use cases draft for such a small > model, but I think the draft really does need a section or two explaining > why and how this is envisioned to be used, and what server implementors are > supposed to do with it. > A module-tag provides a 1:N mapping so instead of specifying (e.g.) every routing module by name, a tag like "routing" can be used instead. This mapping allows the tag to be stable even if the modules in the mapping are not stable. The mappings can change release to release or server to server. We have implemented module tags as a new filter type, for get and get-config operations., as well as a rule-type for NACM rules. I assume the plan is that NETMOD WG would work on the data model and NETCONF WG would eventually do the protocol work. > thanks. > -- Anees > > On Sun, Sep 30, 2018 at 4:15 PM Andy Bierman <a...@yumaworks.com> wrote: > >> >> >> On Sun, Sep 30, 2018 at 1:17 PM, joel jaeggli <joe...@bogus.com> wrote: >> >>> On 9/26/18 09:23, Andy Bierman wrote: >>> > >>> > >>> > On Wed, Sep 26, 2018 at 9:09 AM Juergen Schoenwaelder >>> > <j.schoenwael...@jacobs-university.de >>> > <mailto:j.schoenwael...@jacobs-university.de>> wrote: >>> >>> > >>> > It is even worse than a step backwards. >>> > The draft specifies a lot of details about module tag conformance >>> > that needs to be present in the description-stmt. >>> >>> this seems like an important issue to square away before we move ahead. >>> >>> >> agreed. >> >> Also, what does it mean to match a module-tag? >> There is text that implies it is an opaque string and other text that >> suggests it is a colon-separated list of terms. >> It cannot really be both. >> >> >> >>> > The idea that tools must screen-scrape description statements goes >>> against >>> > everything YANG-based management is all about. YANG has extension >>> > statements, so we don't need to put complex syntax into comments and >>> > descriptions.. >>> >>> and parse descriptions for meaning. >>> >> >> So what the choices? >> >> 1) IANA >> 2) YANG extension >> 3) ad-hoc >> 4) do nothing >> >> IMO IANA has enough to do and it only covers IETF modules anyway, so (1) >> is out. >> The current approach is (3). It is slightly better than (4), but there >> is nothing >> preventing every module from declaring the module tags differently. >> This does not help the YANG reader (#1 priority). >> >> Only a YANG extension (or real statement in YANG 2.0) supports all modules >> in a way that is consistent for all readers. >> >> >> >> >>> >>> > IMO all text about module tag conformance and defining tags in >>> > description-stmts >>> > should be removed. There is no explanation why a standard YANG module >>> > would define multiple module-tags for the same module in the first >>> place, >>> > let alone why each different tag would have different conformance >>> > requirements. >>> > >>> > >>> > >>> > ..... >>> > >>> > /js >>> > >>> > >>> > Andy >>> > >>> >> >> Andy >> >> >> >>> > >>> > >>> > -- >>> > Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | >>> Germany >>> <https://maps.google.com/?q=Campus+Ring+1+%7C+28759+Bremen+%7C+Germany&entry=gmail&source=g> >>> > Fax: +49 421 200 3103 <https://www.jacobs-university.de/ >>> > >>> > >>> > >>> > >>> > _______________________________________________ >>> > 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
