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 netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod