Oppose adoption As others have said, there is a lack of a problem to solve.
When I ask users of a technology that uses #hashtags where they come from, how they come into being and similar elements of procedure, I never get an answer. #hashtags seem to be provided to allow a storm to gather on social media, around some vague idea, in order to put pressure on someone or something that would otherwise be unjustified:-) The tags listed in Section 10.2 seem just as vague and I do not see a role for something somewhat ill-defined in YANG. Tom Petch ----- Original Message ----- From: "Phil Shafer" <[email protected]> To: "Andy Bierman" <[email protected]> Cc: "NETMOD Working Group" <[email protected]> Sent: Wednesday, February 07, 2018 6:59 PM Subject: Re: [netmod] Adoption Poll: draft-rtgyangdt-netmod-module-tags-02 > Andy Bierman writes: > >The draft avoids discussion of any useful operations based on tags. > > Nor does it really clearly say "what" is being tagged. The absract > talks about "used to help classify and organize modules", but the > Introduction lacks any expansion on this. There's really no clear > problem statement or a clear definition of why we need tags or what > one would use them for. > > It would also be helpful to understand why "#hashtag" and the string > format ("ietf:routing", "vendor:super-duper:...") are chosen over > YANG identities. It seems like identity naming standards and inheritance > would be good features. > > Also it's not clear why these would be configurable rather that > controlled by the module author. I'd rather have the OAM standard > YANG module say something like: > > module ietf-oam { > import "ietf-category" { prefix ietf-category; } > > identify ietf-oam { > base ietf-category:ietf-standard; > description "This module category represents something > OAM related."; > } > > ietf-category:module-category ietf-oam; > ... > } > > The draft says: > > Implementations that do not support the reset rpc statement (whether > at all, or just for a particular rpc or module) MUST respond with an > YANG transport protocol-appropriate rpc layer error when such a > statement is received. > > The entire idea of NETCONF/YANG is that the client _knows_ what it > can safely send instead of tossing spaghetti at the wall until > something sticks. Avoid programming-by-error-detection, which > creates fragile infrastructure. > > Use "feature" to control optional portions of a YANG module. I'd > suggest one feature for "reset" support and another for "read-only", > since IMHO the idea of someone munging the categories of standard > modules is, well, disconcerting. > > "Local" tags are not well explained. The idea of a user/admin > tagging modules means that something is broken. Users shouldn't > understand YANG modules. Users use applications, some of which are > home-grown. Is "local" appropriate for my "audit interfaces" script? > > 6.1 is missing the list "module-tags". > > 9.1 advocates putting vital information in the description string, > which is IMHO not a good idea. We want to put as much information > in machine-readable format as possible, so I can ask ietf.org > questions like "give me a list of ietf-oam-related yang modules" > and get a nice list. > > It also talks about "SHOULD" and "MAY" tags without giving any > clue as to why or when this would be appropriate or useful. > > So my vote would be that this document needs some significant work > and expansion before it's a supportable draft. I think the authors > have more in their heads than they've put into the draft and I'd > like to see the rest of their thoughts. > > Thanks, > Phil > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
