Re: [core] [art] [Last-Call] Artart last call review of draft-ietf-core-problem-details-05

Carsten Bormann <cabo@tzi.org> Mon, 04 July 2022 17:01 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C572EC14CF13; Mon, 4 Jul 2022 10:01:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-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 XYw5IVkzWSRm; Mon, 4 Jul 2022 10:01:03 -0700 (PDT)
Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAEACC14F741; Mon, 4 Jul 2022 10:01:01 -0700 (PDT)
Received: from [192.168.217.118] (p5089ad4f.dip0.t-ipconnect.de [80.137.173.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4LcBs70BqLzDCcr; Mon, 4 Jul 2022 19:00:59 +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: <AS1PR07MB8616FC72CCA68AAC9F0A979898BE9@AS1PR07MB8616.eurprd07.prod.outlook.com>
Date: Mon, 04 Jul 2022 19:00:58 +0200
Cc: Thomas Fossati <Thomas.Fossati@arm.com>, "core@ietf.org WG" <core@ietf.org>, Applications and Real-Time Area Discussion <art@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "draft-ietf-core-problem-details.all@ietf.org" <draft-ietf-core-problem-details.all@ietf.org>
X-Mao-Original-Outgoing-Id: 678646858.5978-a5f2802a690ba4035cd336751aae1cc3
Content-Transfer-Encoding: quoted-printable
Message-Id: <5D48F562-8F48-40EF-8C5A-E0A3EF2AFF74@tzi.org>
References: <165511479760.19573.12671700576299137749@ietfa.amsl.com> <63D13796-758D-469B-AFA8-3050C9F87819@tzi.org> <AS1PR07MB86169230F0D43E82CB2BCA1698AC9@AS1PR07MB8616.eurprd07.prod.outlook.com> <CAObGJnO7kdhO6tzLx2GZH3FVj2iedCU=fWH-w608OAStMMGeLA@mail.gmail.com> <10B6E8EC0FCAFB668F04845E@PSB> <CAObGJnOqMAmu32stN11NoTAfvNhXvmGSjscpk8cS5AO6iY4k0Q@mail.gmail.com> <B9C8C465-FE6A-49A6-BA36-EB5756F75463@tzi.org> <AS1PR07MB8616E70E8C511B024183638698BA9@AS1PR07MB8616.eurprd07.prod.outlook.com> <DB9PR08MB6524B5E1658A5C75692FD98E9CBD9@DB9PR08MB6524.eurprd08.prod.outlook.com> <AS1PR07MB8616FC72CCA68AAC9F0A979898BE9@AS1PR07MB8616.eurprd07.prod.outlook.com>
To: Francesca Palombini <francesca.palombini=40ericsson.com@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/SrKRs82zJqW1eGOXuh34_aE0gyc>
Subject: Re: [core] [art] [Last-Call] Artart last call review of draft-ietf-core-problem-details-05
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Jul 2022 17:01:05 -0000

Hi Francesca,

On 2022-07-04, at 18:06, Francesca Palombini <francesca.palombini=40ericsson.com@dmarc.ietf.org> wrote:
> 
>  Updates to this document need to be clear about what is being altered,

This is getting into the “brush your teeth” twilight zone.

> and ought not discard this appendix without publishing it as a separate document.

(As I mentioned in the github issue, we actually did this when we updated RFC 7049 to RFC 8949.  Tag 35 remains defined in RFC 7049, which as the CBOR specification is obsoleted by RFC 8949.  This is all transparent via the tag registry, which is why the existing text proposal points to it.  Yes, we discussed this quite a bit as a WG.)  I don’t think this document *can* prevent us from at some point deciding we want to stop updating Tag 38 and address its use cases by something shiny and new — even if this seems a bit far-fetched now.  It certainly shouldn’t try to.

So half of this addition isn’t needed, and the other half isn’t quite the right recommendation about the evolution of this document.

Grüße, Carsten