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

Christian Hopps <chopps@chopps.org> Thu, 13 February 2020 19:51 UTC

Return-Path: <chopps@chopps.org>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D1B8120219; Thu, 13 Feb 2020 11:51:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hxt0dWJtnKXe; Thu, 13 Feb 2020 11:51:53 -0800 (PST)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id E36201201CE; Thu, 13 Feb 2020 11:51:52 -0800 (PST)
Received: from stubbs.int.chopps.org (66-227-211-29.dhcp.trcy.mi.charter.com [66.227.211.29]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 1DEF060B8E; Thu, 13 Feb 2020 19:51:52 +0000 (UTC)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\))
From: Christian Hopps <chopps@chopps.org>
In-Reply-To: <2ee6b71c-bd2c-4676-9e14-cb240c6845c9@www.fastmail.com>
Date: Thu, 13 Feb 2020 14:51:51 -0500
Cc: Christian Hopps <chopps@chopps.org>, The IESG <iesg@ietf.org>, draft-ietf-netmod-module-tags@ietf.org, Joel Jaeggli <joelja@gmail.com>, netmod-chairs@ietf.org, netmod@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <C9A4A3B5-B692-4C7C-AFE2-B95377452999@chopps.org>
References: <155499006434.22705.5858614581630974980.idtracker@ietfa.amsl.com> <7F3B9E7F-6AD8-4801-AE60-9F2D704DC69B@chopps.org> <2ee6b71c-bd2c-4676-9e14-cb240c6845c9@www.fastmail.com>
To: Alexey Melnikov <aamelnikov@fastmail.fm>
X-Mailer: Apple Mail (2.3608.40.2.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/o8ZVbuhtWSP8FtrMihWFdnUeuso>
Subject: Re: [netmod] Alexey Melnikov's Discuss on draft-ietf-netmod-module-tags-07: (with DISCUSS)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Feb 2020 19:51:55 -0000


> On Feb 13, 2020, at 8:10 AM, Alexey Melnikov <aamelnikov@fastmail.fm> 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.

I don't have a problem including some text in the IANA guidance if we need it; however, the guidance already says:

  "New values should be well considered and not achievable through a
   combination of already existing IETF tags."

How could we arrive at a place where IANA is confused about allowing 2 visually indistinguishable strings given the above statement? The registry already requires IETF review, and it seems counter to the existing IANA guidance to even be talking about distinguishing visually indistinguishable tag values. IOW simply by talking about the need to compare 2 strings that are visually indistinguishable, we diminish the much more important intent of the initial guidance.

Thanks,
Chris.

> 
> 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 <noreply@ietf.org> 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?
>>> 
>>> 
>>> 
>>> 
>> 
>> 
>