Hi Juergen, Please see inline ...
> -----Original Message----- > From: Schönwälder, Jürgen <[email protected]> > Sent: 14 February 2020 14:31 > To: Rob Wilton (rwilton) <[email protected]> > Cc: Alexey Melnikov <[email protected]>; [email protected]; Joel > Jaeggli <[email protected]>; Christian Hopps <[email protected]>; The IESG > <[email protected]> > 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 <[email protected]> On Behalf Of Schönwälder, Jürgen > > > Sent: 13 February 2020 18:39 > > > To: Alexey Melnikov <[email protected]> > > > Cc: [email protected]; [email protected]; > > > [email protected]; Joel Jaeggli <[email protected]>; Christian Hopps > > > <[email protected]>; The IESG <[email protected]> > > > 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 > > > <[email protected]> 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 > > > > [email protected] > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > -- > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > > Fax: +49 421 200 3103 <https://www.jacobs-university.de/> > > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <https://www.jacobs-university.de/> _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
