On Tue, Oct 16, 2018 at 12:42 PM, Christian Hopps <cho...@chopps.org> wrote:
> > Andy Bierman <a...@yumaworks.com> writes: > > On Tue, Oct 16, 2018 at 6:08 AM, Juergen Schoenwaelder < >> j.schoenwael...@jacobs-university.de> wrote: >> >> On Tue, Oct 16, 2018 at 08:31:43AM -0400, Christian Hopps wrote: >>> > >>> > On Oct 2, 2018, at 4:30 PM, Juergen Schoenwaelder < >>> j.schoenwael...@jacobs-university.de> wrote: >>> >>> > > - Standard tags defined in description statements >>> > > >>> > > I do not like this. YANG has extension statements and having to >>> > > parse stuff out of free text description statements seems to be a >>> > > movement backwards. >>> > >>> > This is used by the human implementer of the module (i.e., they need to >>> write code to implement the module). As such it was not intended for >>> machine parsing. >>> > >>> >>> I am personally not convinced. The whole reason why we have YANG is >>> automation and I believe people will go and write tools to extract >>> tags and having to extract them out of free form text looks like a >>> step backwards. >>> >>> >> >> It is more than a step backwards. >> There is an unexplained procedure for declaring the module-tag >> conformance, >> in addition to the module-tag mappings. >> >> All YANG designers are supposed to learn the exact text to write (not >> free-form at all) >> and this draft updates 6087bis with procedures for declaring the >> module-tags >> in the description-stmt. >> >> Also, tool developers are supposed to parse the description-stmt looking >> for the >> module-tag definitions. But instead, tool developers are going to say "Use >> our >> proprietary YANG extension because we are never going to parse description >> statements" >> > > I've added the extension statement. > good > > > > - System management >>> > > >>> > > What is 'system management' and a 'system management protocol'? >>> > >>> > These were derived from the work the RtgYangDT originally did where we >>> were organizing everything under a single device tree. This tree concept >>> was (rightly) abandoned to be replaced with use of tags. Examples of >>> protocols would be Syslog, TACAC+, SNMP, Netconf, ... I've added that to >>> the description. >>> > >>> >>> I am generally not a fan of definition by example. Is SSH a 'system >>> management protocol'? >>> >>> >> >> An example is not a definition. >> The IETF is supposed to know the difference. >> > > Do you have some suggestions for text that could replace the examples? > > Some of these things seem painful obvious, like do we *really* need to > define what we mean by a routing protocol? > > This draft needs to define the module-tag encoding wrt/ - valid characters (e.g., some subset of UTF-8) - min/max length (e.g., implementation MUST support at least 64 chars and can support larger) Section 3 (Tag Prefixes) seems to imply that all modules tags follow a structure to specify the naming authority. According to the YANG module, the data type is a plain string, which includes lots of problematic chars and zero-length strings. Does the string "routing" match "ietf:routing" or "vendor:routing"? How about "routing:bgp"? Is the char ":" allowed in a tag? Is "vendor::::::::" a valid tag? IMO this draft does not need to define any specific module-tag content but it does need to define in precise terms how a protocol encodes a module-tag and how a module-tag match is determined. Thanks, > Chris. > Andy
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
