On Tue, Oct 16, 2018 at 3:15 PM, Christian Hopps <[email protected]> wrote:
> > Andy Bierman <[email protected]> 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? > I suppose yang-identifier type is too restrictive so I will agree that restricting whitespace and colon chars is probably good enough > 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? > The official prefixes and colon char lead people to believe the string is structured. Intelligent searches on sub-sfields might be purpose of such structure. Or not I guess. > Is the char ":" allowed in a tag? >> > > Yes, why not? > Because it confuses people who think the colon character has special meaning in this string > > 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? > I think the registry details have to be there to populate the IANA registery > > Thanks, > Chris. > > >> >> Thanks, >> >>> Chris. >>> >>> >> Andy >> > > Andy
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
