Re: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 10/16/18

[Martin Bjorklund <[e-mail]>]

Hi,

Christian Hopps <[e-mail]> wrote:
> 
> Andy Bierman <[e-mail]> 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?

The word "match" is imo problematic.  Use "equal" if that's what you
mean.  But you're not actually using the word "match" in the draft, so
that's fine.  However, I think the draft can be clarified.  See below.

In this case, it _seems_ like there's some hierarchy with tags
like:

  ietf:routing
  ietf:routing:rib

For example, does ietf:routing:rib imply ietf:routing?

>From your last emails, it seems that the idea is that tags are really
just strings with the only property that they can be compared for
equality.  If this is the case, I think it can be made more clear in
the document.  And if this is the case, I think that type "string" is
actually fine.  If someone wants to assign the tag
"vendor:acme::::::::: ", let them.

OTOH, if the idea is that the tags are hierarchical, and
ietf:routing-rib implies ietf:routing, then a more specific type is
needed, and more text.


/martin



> 
> > 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
>