Andy Bierman <a...@yumaworks.com> writes:
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)
I'm looking for suggestions on how to do this subset. We had intended to allow
for as wide as possible content; however, I think disallowing tabs, newlines,
carriage returns is more than reasonable. Has a type like this already been
standardized or is there an example available somewhere?
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"?
No. Do we need to state that non-matching strings don't match?
Is the char ":" allowed in a tag?
Yes, why not?
Is "vendor::::::::" a valid tag?
Again why not?
The only thing the draft talks about are standard prefixes. Why should a
standard enumerate a subset of the unbounded set of things it isn't
standardizing? This seems more confusing (why was X included as OK but not Y)
than just sticking to what it *is* standardizing.
Perhaps a bit of text saying more explicitly that only the prefix is restricted
would help though?
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.
We considered leaving out all the predefined tags, but conversely we also
thought it would be useful to establish a base set. We went with the latter
obviously. Perhaps it just needs to be trimmed down more?
Thanks,
Chris.
Thanks,
Chris.
Andy
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
