On Fri, Feb 14, 2020 at 3:01 AM Christian Hopps <[email protected]> wrote:
> I was not approaching this discuss with this level of change in mind. How > many years does it take to get a YANG model even one as simple as this > completed? > > I strongly agree. Just because there are refinements to the YANG "string" data type that are possible does not mean the Module Tags RFC has to solve that problem, or wait until it is solved. Every YANG module using the "string" data type (all of them?) could have the same problem. > Thanks, > Chris. > Andy > > > On Feb 14, 2020, at 5:43 AM, Rob Wilton (rwilton) <[email protected]> > wrote: > > > > Hi Alexey, Christian, > > > > Allowing Unicode but requiring normalization as per RFC 5198 for IANA > managed tags makes sense to me. > > > > But does the server also need to normalize any configured tags? I.e. > should the description for the tag typedef also specify that tags SHOULD be > normalized, and specify a normalization method that SHOULD be used? Or is > the onus on the client to use sensible (i.e. already normalized) values, > and if so, does that need to be stated? > > > > Thanks, > > Rob > > > > > >> -----Original Message----- > >> From: iesg <[email protected]> On Behalf Of Alexey Melnikov > >> Sent: 13 February 2020 13:10 > >> To: Christian Hopps <[email protected]> > >> Cc: [email protected]; Joel Jaeggli <[email protected]>; The IESG > >> <[email protected]>; [email protected]; > [email protected] > >> Subject: Re: Alexey Melnikov's Discuss on draft-ietf-netmod-module-tags- > >> 07: (with DISCUSS) > >> > >> 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 >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
