Re: [netmod] I-D Action: draft-ietf-netmod-rfc6991-bis-14.txt

Kent Watsen <kent+ietf@watsen.net> Fri, 09 December 2022 17:42 UTC

Return-Path: <01000184f7fb6464-ae7642e9-596f-460d-9eac-cd8b0b931d98-000000@amazonses.watsen.net>
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 287D2C13B4E2 for <netmod@ietfa.amsl.com>; Fri, 9 Dec 2022 09:42:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com
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 D5Zu9tz7ndal for <netmod@ietfa.amsl.com>; Fri, 9 Dec 2022 09:42:40 -0800 (PST)
Received: from a48-110.smtp-out.amazonses.com (a48-110.smtp-out.amazonses.com [54.240.48.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44852C152705 for <netmod@ietf.org>; Fri, 9 Dec 2022 09:42:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1670607759; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=5q4NjnbOM5rp4EeQLOGdpsJbTdZT00wjtEkPFZ7ZKY0=; b=AifK/DzlzXUIE/96agqgp1Dc7KPnXdQsy2K8o4KXnj1DPmMo/CYTtL6Ua73dV2a6 1wnLKUGzr2njK7whZZ4YA36G4KwrwzIa58cNQlD7c5nZ2Vp2V0/qLc7sUKDXhOC7QrP 8aA9kmnqjwSlWErkkS/nJI9G/IrRY7r3LM5JuOQU=
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
From: Kent Watsen <kent+ietf@watsen.net>
In-Reply-To: <20221209161326.m444a7zslu52cblq@anna>
Date: Fri, 09 Dec 2022 17:42:38 +0000
Cc: "netmod@ietf.org" <netmod@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-ID: <01000184f7fb6464-ae7642e9-596f-460d-9eac-cd8b0b931d98-000000@email.amazonses.com>
References: <167023973660.5119.3909679673368752560@ietfa.amsl.com> <01000184e275372f-35eb9271-1f53-4d2a-bd74-c2b49d2a7c07-000000@email.amazonses.com> <20221205135817.3hmtw6fp2vi6pb3t@anna> <01000184e3f14a15-95feeb1e-c027-4366-ab2c-291ac3f03cc8-000000@email.amazonses.com> <20221205223741.mxeacefm46mkpwrl@anna> <01000184f79d8cfa-d89dcb43-4f2b-4e4e-8963-35ceebb4b512-000000@email.amazonses.com> <20221209161326.m444a7zslu52cblq@anna>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
X-SES-Outgoing: 2022.12.09-54.240.48.110
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/rEL4iC3aOWJa38ZcxbBZJst9o3U>
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6991-bis-14.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.39
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: Fri, 09 Dec 2022 17:42:42 -0000

> Nobody has asked for a 'name' version yet. I just wanted to use this
> example that demonstrate that it is hard to future proof name
> choices.

Fine.  The intended pattern wasn't clear.  Knowing that there is a pattern, it's fine to not have a "name" version.  Should the draft capture the intended pattern, and/or an explanation for why a "name" version isn't defined?


> (And we also do not distinguish between mandatory and
> optional components, our date-and-time type really should be named
> date-and-time-with-optional-zone-offset.)

True, but good luck with that!  ;)


Kent // co-chair and shepherd