Re: [netmod] Alexey Melnikov's Discuss on draft-ietf-netmod-module-tags-07: (with DISCUSS)

[Schönwälder, Jürgen <[e-mail]>]

On Mon, Feb 17, 2020 at 10:40:30AM -0500, Christian Hopps wrote:
> 
> 
> > On Feb 17, 2020, at 9:07 AM, Rob Wilton (rwilton) <[e-mail]> wrote:
> > 
> > Hi Juergen,
> > 
> > Please see inline ...
> > 
> >> -----Original Message-----
> >> From: Schönwälder, Jürgen <[e-mail]>
> >> Sent: 14 February 2020 14:31
> >> To: Rob Wilton (rwilton) <[e-mail]>
> >> Cc: Alexey Melnikov <[e-mail]>; [e-mail]; Joel
> >> Jaeggli <[e-mail]>; Christian Hopps <[e-mail]>; The IESG
> >> <[e-mail]>
> >> Subject: Re: [netmod] Alexey Melnikov's Discuss on draft-ietf-netmod-
> >> module-tags-07: (with DISCUSS)
> >> 
> >> Rob,
> >> 
> >> I think there are two related issues here:
> >> 
> >> a) If we need normalized strings (to avoid comparison suprises), we
> >>   should have a common type for them; rfc6991-bis would be a proper
> >>   home. I am _not_ saying we should delay the tags document for this,
> >>   but we should think about providing a solution that can be easily
> >>   reused. Right now, we often use strings as part of keys, which can
> >>   lead to comparison issues.
> > [RW] 
> > 
> > I agree.  Note, I am also not proposing that we delay module-tags for rfc6991-bis.
> > 
> > RFC 7950 states that strings are not normalized by default (section 9.4.2).  Thinking about this some more, I think that it is reasonable to make it the client's responsibility to normalize strings, if required.
> > 
> > Chris, this would mean that no change to the typedef description is required.
> > 
> >> 
> >> b) It seems that normalized strings only solve part of the problem. If
> >>   an organization creates names for 'things', the organization likely
> >>   wants to further restrict the format of these names to something
> >>   sensible to avoid fun with different kinds of hyphens or emojis or
> >>   ... So while creative unicode characters may technically work,
> >>   there will likely be good reasons to avoid some of them. (There are
> >>   reasons why we have coding styles for most programming languages.)
> >>   These rules may, however, differ between organizations.
> >> 
> >> We should not confuse a) and b). If IANA needs additional guidelines for
> >> tags (their coding style for tags), then we should provide these
> >> guidelines, i.e., this is a type b) action. The type a) action is needed
> >> to technically ensure that comparisons do not lead to surprises. But a)
> >> won't be an answer for all type b) issues. Of course, we could give IANA a
> >> 'coding style' that avoids any normalization issues. This would make IANA
> >> assigned tags safe but would not avoid comparison surprises for other
> >> sources of tags.
> > [RW] 
> > 
> > So, solving B seems reasonable for the IANA defined module tags, following Alexey's suggestion of referencing RFC 5198 for normalization.
> 
> I will not put the additional text in the typedef and instead put it in the guidance for the IANA registry then:
> 
>  This registry allocates tags that have the registered prefix
>  "ietf:". New values should be well considered and not achievable
> -through a combination of already existing IETF tags.
> +through a combination of already existing IETF tags. For comparing
> +non-ascii strings, 'NFC' [[RFC5198]] normalization SHOULD be used.
> 
> Unless there are further objections, I believe this, and a small change to the security section suggested by Benjamin K, will clear the remaining DISCUSS so I will republish soon.

Perhaps this wording is clearer about who is responsible for normalization:

-through a combination of already existing IETF tags.
+through a combination of already existing IETF tags. IANA assigned
+tags must conform to Net-Unicode as defined in RFC 5198 and they shall
+not need normalization.

And then lets hope that others assigning tags follow this advice. ;-)

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>