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

["Rob Wilton (rwilton)" <[e-mail]>]

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.

Thanks,
Rob


> 
> /js
> 
> On Fri, Feb 14, 2020 at 10:30:50AM +0000, Rob Wilton (rwilton) wrote:
> > Hi Juergen,
> >
> > This sounds potentially useful to me, although should this be for
> general unicode strings (e.g. ones that might include spaces), or just
> identifiers (without any spaces)?.  Is this something that could/should go
> into rfc6991-bis, or at least be discussed in that context?
> >
> > I would have thought that normalization would be required wherever a
> configurable unicode string is used as a list key, or leaf-list.
> >
> > Thanks,
> > Rob
> >
> >
> > > -----Original Message-----
> > > From: iesg <[e-mail]> On Behalf Of Schönwälder, Jürgen
> > > Sent: 13 February 2020 18:39
> > > To: Alexey Melnikov <[e-mail]>
> > > Cc: [e-mail]; [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)
> > >
> > > And a longer term solution might be to define a YANG Net-Unicode
> > > string datatype that can be used in all situations where
> > > non-normalized strings may cause problems. The problem (if one
> > > agrees it is one) is likely much bigger than just YANG tags, there
> > > likely are many uses of YANG strings where normalization would be
> desirable.
> > >
> > > /js
> > >
> > > On Thu, Feb 13, 2020 at 01:10:02PM +0000, Alexey Melnikov wrote:
> > > > Hi Christian,
> > > >
> > > > On Thu, Feb 13, 2020, at 12:30 AM, Christian Hopps wrote:
> > > > > The intent in the document is to place as few restrictions on
> > > > > tags as possible to allow for future-proofing and organic growth
> > > > > of use both within and outside of SDOs. For standard tags we
> > > > > trust IANA (and the human behind the process) to make the call
> > > > > on whether a tag is already present. :)
> > > >
> > > > And the problem with that is that because there might be multiple
> > > > ways
> > > to encode in Unicode visually indistinguishable tags IANA would end
> > > up asking IESG for help.
> > > >
> > > > So you need to at minimum specify a Unicode normalization form to
> > > > use. I
> > > suggest you normatively reference RFC 5198 here.
> > > >
> > > > > Having worked for a company where a lot of XML string data was
> > > > > non-ascii I find limiting to ascii to be rather restrictive.
> > > >
> > > > Best Regards,
> > > > Alexey
> > > >
> > > > >
> > > > > Thanks,
> > > > > Chris.
> > > > >
> > > > > > On Apr 11, 2019, at 9:41 AM, Alexey Melnikov via Datatracker
> > > <[e-mail]> wrote:
> > > > > >
> > > > > > Alexey Melnikov has entered the following ballot position for
> > > > > > draft-ietf-netmod-module-tags-07: Discuss
> > > > > >
> > > > > > When responding, please keep the subject line intact and reply
> > > > > > to all email addresses included in the To and CC lines. (Feel
> > > > > > free to cut this introductory paragraph, however.)
> > > > > >
> > > > > >
> > > > > > Please refer to
> > > > > > https://www.ietf.org/iesg/statement/discuss-criteria.html
> > > > > > for more information about IESG DISCUSS and COMMENT positions.
> > > > > >
> > > > > >
> > > > > > The document, along with other ballot positions, can be found
> here:
> > > > > > https://datatracker.ietf.org/doc/draft-ietf-netmod-module-tags
> > > > > > /
> > > > > >
> > > > > >
> > > > > >
> > > > > > --------------------------------------------------------------
> > > > > > ----
> > > > > > ----
> > > > > > DISCUSS:
> > > > > > --------------------------------------------------------------
> > > > > > ----
> > > > > > ----
> > > > > >
> > > > > > This is generally a fine document, but after checking RFC 7950
> > > > > > syntax for strings I question why you think you need non ASCII
> > > > > > tags. There are so many problems that can arise from that. For
> > > > > > example, how would IANA be able to enforce uniqueness of
> > > > > > Unicode tags written in different Unicode canonicalisation
> forms?
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > > _______________________________________________
> > > > netmod mailing list
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/netmod
> > >
> > > --
> > > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > > Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> > > Fax:   [phone]         <https://www.jacobs-university.de/>
> >
> 
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <https://www.jacobs-university.de/>