[netmod] Re: Artart last call review of draft-ietf-netmod-rfc6991-bis-16

Jürgen Schönwälder <jschoenwaelder@constructor.university> Mon, 21 October 2024 20:38 UTC

Return-Path: <jschoenwaelder@constructor.university>
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 EDAB9C15793B; Mon, 21 Oct 2024 13:38:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.244
X-Spam-Level:
X-Spam-Status: No, score=-1.244 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_SOFTFAIL=0.665, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I4K3w9OCQIiT; Mon, 21 Oct 2024 13:38:11 -0700 (PDT)
Received: from beadg.de (beadg.de [178.254.54.206]) by ietfa.amsl.com (Postfix) with ESMTP id 126E3C1F4C42; Mon, 21 Oct 2024 13:38:08 -0700 (PDT)
Received: from localhost (firewallix.jacobs-university.de [212.201.44.246]) by beadg.de (Postfix) with ESMTPSA id 8D0B616A04B; Mon, 21 Oct 2024 22:38:04 +0200 (CEST)
Date: Mon, 21 Oct 2024 22:38:02 +0200
From: Jürgen Schönwälder <jschoenwaelder@constructor.university>
To: Bron Gondwana <brong@fastmailteam.com>
Message-ID: <Zxa7qi7jDf_RyrK4@alice.eecs.jacobs-university.de>
Mail-Followup-To: Bron Gondwana <brong@fastmailteam.com>, art@ietf.org, draft-ietf-netmod-rfc6991-bis.all@ietf.org, last-call@ietf.org, netmod@ietf.org
References: <172762727635.431226.8440698767996901523@dt-datatracker-7bbd96684-zjf54>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <172762727635.431226.8440698767996901523@dt-datatracker-7bbd96684-zjf54>
Message-ID-Hash: BGH5SPF2EELIGEWQIZ7GBXSRPZBFJSJR
X-Message-ID-Hash: BGH5SPF2EELIGEWQIZ7GBXSRPZBFJSJR
X-MailFrom: jschoenwaelder@constructor.university
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-netmod.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: art@ietf.org, draft-ietf-netmod-rfc6991-bis.all@ietf.org, last-call@ietf.org, netmod@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Reply-To: Jürgen Schönwälder <jschoenwaelder@constructor.university>
Subject: [netmod] Re: Artart last call review of draft-ietf-netmod-rfc6991-bis-16
List-Id: NETMOD WG list <netmod.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/PePGt7_5e-R9xMDIebRt1edDTBs>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Owner: <mailto:netmod-owner@ietf.org>
List-Post: <mailto:netmod@ietf.org>
List-Subscribe: <mailto:netmod-join@ietf.org>
List-Unsubscribe: <mailto:netmod-leave@ietf.org>

Thanks for your review, Bron. See my response inline...

On Sun, Sep 29, 2024 at 09:27:56AM -0700, Bron Gondwana via Datatracker wrote:
> Reviewer: Bron Gondwana
> Review result: Not Ready
> 
> I'm the designated ARTART reviewer for this document.  It's generally well
> written and clear; I didn't see any issues with the document itself, however
> there are some obsolete references and changes to align with work done
> elsewhere in the IETF which I believe would improve the overall
> cross-compatibility of IETF specifications significantly, hence my marking it
> as "NOT READY".
> 
> *Date-Time:*
> 
> While the date-time format duplicates the description found in RFC 6021 and
> later RFC 6991, the construct -00:00 has been identified as being incompatible
> with the latest ISO8601 by the work in the SEDATE working group.  I would refer
> you to section 2 of RFC 9557 for the full description and update of RFC 3339
> which was done there.  I suggest that this document should be updated to align
> with (and reference) RFC 9557 and deprecate the usage of -00:00; instead using
> "Z" to mean "local time reference point is unknown" as is common practice. 
> This will improve future interoperability with ISO8601.
> 
> Likewise the same issue occurs with the new "date" format and "time" format.

This has been discussed in the WG and the conclusion was to not change
the 'date-and-time' format as it is widely implemented. Note that RFC
6020 picked -00:00 as the canonical representation for values in UTC
with an unknown local time-offset. RFC 9557 now suggests to use Z
instead. If we change date-and-time to use Z instead of -00:00, then
existing implementations of 'date-and-time' become non-compliant.
Hence, we prefer to stick to what we have.

For the new 'date' and 'time' definitions we can adopt RFC 9557 and
use Z instead of -00:00. This of course means that UTC values with an
unknown local time-offset will be reported differently in 'date-and
time' values and 'date' or 'time' values. Yes, all this is somewhat
unfortunate. I will update the definitions of 'date' and 'time' to
follow RFC 9557 but I will not touch 'date-and-time' for now unless
lets say the IESG decides that alignment with RFC 9557 is more
important than our concerns about compliance of existing
implementations generating canonical representations.
 
> *Email Address:*
> 
> The email-address construct in this document is limited to 7-bit.
> RFC 6531 and RFC 6532 have extended Email Address to allow UTF-8
> characters.  There's a good analysis of the changes at:

[...]
 
> Since this is a new datatype being added, it should support all legal email
> addresses as defined in current IETF RFCs; so be extended for 8 bit
> local-parts. Similarly, the domain part of the address should explicitly
> mention A-labels for Internationalized domain names, as the "domain-name"
> construct does.

I agree that we should support internationalized email addresses.
Given the complexity of defining a tight regular expression, this
seems to be the wrong path to go. (You pointed to a regular expression
that is already close to 1k long and according to its author still has
limitations.) Instead, we should leave it to implementations to do
validation using regular code. 

My take is that standardizing a regex to validate email addresses is
not something this WG should do. Instead, we should leave it to
implementations to do validation in regular code.

I will replace the current regular expression with a rather generic
expression that accepts international characters, I will add a
reference to RFC 6531, and I will add text spelling out that this
email type supports u-labels and a-labels in DNS names.

/js

-- 
Jürgen Schönwälder              Constructor University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany