On 02/07/2018 11:02 PM, Andy Bierman wrote:
Hi,
Many good points.
IMO it will be difficult to agree on the details of this draft
without agreeing on the problem statement first.
As a process issue, this seems like an important step.
+1
It is usually handled with WG charter text, but NETMOD
has a free pass on new YANG modules somehow.
I am interested in these tags as a new type of standard selection filter.
It can be applied to data retrieval, NACM rules, YANG push subtree
selection,
and probably many more use-cases. So the problem statement
might be:
There is a need for standardized mechanisms to classify YANG data
nodes with tags,
which can be used in protocol operations to select matching data
nodes, based on tag values.
This work includes the management and assignment of tags, and their
generalized use
within protocol operations.
A practical usecase example in addition to this text could really help.
I suspect Phil is right that "the authors
have more in their heads than they've put into the draft" but even with
this text an example is needed to illistrate the purpose of this work.
Vladimir
Andy
On Wed, Feb 7, 2018 at 10:59 AM, Phil Shafer <[email protected]
<mailto:[email protected]>> wrote:
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
<http://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
