IETF Logo Mail Archive

[netmod] Re: AD review of draft-ietf-netmod-rfc6991-bis-15

Carsten Bormann <cabo@tzi.org> Wed, 07 August 2024 10:44 UTC

Return-Path: <cabo@tzi.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 C0A29C17C884 for <netmod@ietfa.amsl.com>; Wed, 7 Aug 2024 03:44:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_TEMPERROR=0.01] autolearn=ham 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 lZfUCKK9bMCJ for <netmod@ietfa.amsl.com>; Wed, 7 Aug 2024 03:43:58 -0700 (PDT)
Received: from smtp.zfn.uni-bremen.de (smtp.zfn.uni-bremen.de [134.102.50.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 161C0C151069 for <netmod@ietf.org>; Wed, 7 Aug 2024 03:43:56 -0700 (PDT)
Received: from clients-pool3-0220.vpn.uni-bremen.de (clients-pool3-0220.vpn.uni-bremen.de [134.102.69.220]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4Wf6Gx5Hl2zDCdG; Wed, 7 Aug 2024 12:43:53 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <ZrMpUB4LO6EY9sqr@alice.eecs.jacobs-university.de>
Date: Wed, 07 Aug 2024 12:43:53 +0200
X-Mao-Original-Outgoing-Id: 744720233.2195311-25c7ebc049fe0250c09c756d1868b7ea
Content-Transfer-Encoding: quoted-printable
Message-Id: <3BB5CAA3-6024-4299-A018-F0106DE0AA81@tzi.org>
References: <AM7PR07MB624840744B6F925E96C6F526A0879@AM7PR07MB6248.eurprd07.prod.outlook.com> <CABCOCHRBPrHk8Wk0xJtYzhB8aTiS+bwUPxi70LtAPEL5Qy87kw@mail.gmail.com> <7CC7D3A9-B5DD-4857-B50B-82B7903B32C6@gmail.com> <bffad8a0-7321-463a-aca3-278527e570e6@constructor.university> <2A6786B6-2F57-4466-8813-64191518DA15@gmail.com> <ZiEatXg_zUxbxlNk@alice.eecs.jacobs-university.de> <DC155020-FD8F-4321-BA77-D0C4A8B1952D@gmail.com> <44400A17-C2E9-49EC-9CF9-54225E7DBC8A@tzi.org> <0100018fe0055319-8ddc8435-a68e-43d9-8c9c-75f5c90786a7-000000@email.amazonses.com> <7C184A93-2E5B-4278-8541-D1D43C132A6C@tzi.org> <ZrMpUB4LO6EY9sqr@alice.eecs.jacobs-university.de>
To: Jürgen Schönwälder <jschoenwaelder@constructor.university>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Message-ID-Hash: KFZTVWC6X423KC6RY5I4MWIYYIIJWWN4
X-Message-ID-Hash: KFZTVWC6X423KC6RY5I4MWIYYIIJWWN4
X-MailFrom: cabo@tzi.org
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: Kent Watsen <kent@watsen.net>, "netmod@ietf.org" <netmod@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [netmod] Re: AD review of draft-ietf-netmod-rfc6991-bis-15
List-Id: NETMOD WG list <netmod.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/nG7t8h6tS30RkywQSYOKR48nxaA>
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>

On 2024-08-07, at 09:59, Jürgen Schönwälder <jschoenwaelder@constructor.university> wrote:
> 
> It is what it is.

I agree that this is a valid approach for keeping YANG-XML and YANG-JSON forward compatible; date/times do not need to be ISO 8601 compatible to be useful YANG data.

Separately, for generating a good stand-in spec for YANG-CBOR (which allows binary representation of dates and timestamps), it would be good to have some more information about how the timezone-offset is used in practice in the YANG ecosystem.  I haven’t done a proper survey (lacking a corpus to work from), but anecdotical I’m seeing examples with Z in place of a timezone-offset that appear to target the semantics of -00:00 (which is what RFC 9557 recognizes as the de-factor meaning of Z).

Grüße, Carsten

v2.26.15 | Report a Bug | By Email | System Status