[core] Opsdir last call review of draft-ietf-core-problem-details-04

Joel Jaeggli via Datatracker <noreply@ietf.org> Mon, 06 June 2022 17:44 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: core@ietf.org
Delivered-To: core@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 976CDC159492; Mon, 6 Jun 2022 10:44:30 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Joel Jaeggli via Datatracker <noreply@ietf.org>
To: ops-dir@ietf.org
Cc: core@ietf.org, draft-ietf-core-problem-details.all@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 8.3.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <165453747061.47535.7157443765667404463@ietfa.amsl.com>
Reply-To: Joel Jaeggli <joelja@bogus.com>
Date: Mon, 06 Jun 2022 10:44:30 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/TzprnEuqq2iQvOHRGsDp0kFBbOo>
Subject: [core] Opsdir last call review of draft-ietf-core-problem-details-04
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.39
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, 06 Jun 2022 17:44:30 -0000

Reviewer: Joel Jaeggli
Review result: Ready

I reviewed draft-ietf-core-problem-details on behalf of the  ops directorate. I
nsummar y this draft is largely ready. I have one perhaps clarifying question.

in the regards to the following statement:

   Consumers of a Concise Problem Details data item MUST ignore any
   Custom Problem Detail entries, or keys inside the Custom Problem
   Detail entries, that they do not recognize; this allows Custom
   Problem Detail entries to evolve and include additional information
   in the future.  The assumption is that this is done in a backward and
   forward compatible way.

This seems like less of a gesture at compatibility as opposed to simply
ignoring conditions that would otherwise produce errors by the receiving
parties. it would see likely that coap problem detail collectors may collect
such data for processing by other systems since the whole collection pipline
may not move in lock step or doesn't it?