Re: [core] Murray Kucherawy's Discuss on draft-ietf-core-problem-details-05: (with DISCUSS and COMMENT)

Carsten Bormann <cabo@tzi.org> Thu, 16 June 2022 10:39 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 9368EC14F742; Thu, 16 Jun 2022 03:39:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.897
X-Spam-Level:
X-Spam-Status: No, score=-6.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_HELO_TEMPERROR=0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] 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 xa337V9HwpoE; Thu, 16 Jun 2022 03:39:25 -0700 (PDT)
Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [134.102.50.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 2CF57C14F726; Thu, 16 Jun 2022 03:39:21 -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 4LNzF24dcpzDCcF; Thu, 16 Jun 2022 12:39:18 +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: <165537014581.60875.8099783525339418032@ietfa.amsl.com>
Date: Thu, 16 Jun 2022 12:39:18 +0200
Cc: The IESG <iesg@ietf.org>, draft-ietf-core-problem-details@ietf.org, core-chairs@ietf.org, core@ietf.org, jaime@iki.fi
X-Mao-Original-Outgoing-Id: 677068758.000333-d0ac86c1a5b1699bd26153f105330b1e
Content-Transfer-Encoding: quoted-printable
Message-Id: <18C25B95-DA36-466F-8EAB-6E4194B15DE8@tzi.org>
References: <165537014581.60875.8099783525339418032@ietfa.amsl.com>
To: Murray Kucherawy <superuser@gmail.com>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/wI0T2V__1MXi5Utr6i6O0XP59fQ>
Subject: Re: [core] Murray Kucherawy's Discuss on draft-ietf-core-problem-details-05: (with DISCUSS and COMMENT)
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: Thu, 16 Jun 2022 10:39:29 -0000

Hi Murray,

thank you for examining the IANA considerations of this document closely.
We already have reacted to the comment from IANA that pointed out they cannot perform the checks they would need to do with the “first-come first-serve” policy for 5.2.  So we had been making a few changes to the IANA considerations section, which we continue with this response.

Detailed responses (and further changes) below.
The most recent changes based on your feedback are collected in:

https://github.com/core-wg/core-problem-details/pull/39

Probably the whole thing is easier to read in the consolidated editor’s copy at

https://core-wg.github.io/core-problem-details/draft-ietf-core-problem-details.html#name-iana-considerations

> On 2022-06-16, at 11:02, Murray Kucherawy via Datatracker <noreply@ietf.org> wrote:
> 
> Murray Kucherawy has entered the following ballot position for
> draft-ietf-core-problem-details-05: Discuss
> 
> […]
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-core-problem-details/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> This should be quick to clear up, but the IANA Considerations section has a few
> issues:
> 
> Section 5.1 declares a new registry with a Specification Required policy.  RFC
> 8126 explains what this means in its Section 4.6, and notes that this will
> result in a Designated Expert being appointed, and further stipulates that
> "clear guidance to the designated expert should be provided when defining the
> registry".  However, none is evident here.  Was this an oversight?

We had added some expert review guidance already in the most recent version, prompted by the IANA comments.

We now added some more text in Section 5.1 (now 6.1), which should now be a more complete set of instructions.

> Section 5.2 declares a new registry with a First Come First Served policy.  RFC
> 8126, Section 4.4, covers this, and says in pertinent part, "... in addition to
> the contact person field or reference, the registry should contain a field for
> change controller."  That's absent here, so please add one.

(While this is “expert review” now, the same consideration applies.)

We are just wondering why Section 4.6 of RFC 8126 does not have that requirement.  Anyway, we added Change Controller to both 5.1 (now 6.1) and 5.2 (now 6.2).

> In Section 5.3, the "Required Parameters" and "Optional Parameters" need to be
> "N/A", not "None".  See RFC 6838, Section 5.6.

Fixed.

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> With respect to the comment at the end of Section 5.4, is some other document
> altering the names of those registry columns?

I’m afraid not at this time.  https://datatracker.ietf.org/doc/draft-bormann-core-corr-clar/ was meant to collect corrections and clarifications to the base specification, but so far we didn’t see a need to push this through all the way to RFC (we didn’t even do working group adoption yet, and much of the discussion in the issues still needs to be processed).

Maybe it’s time to put some more energy into this draft.
I updated https://github.com/core-wg/corrclar/issues/8 for this issue.

Grüße, Carsten