[core] Review of draft-fossati-core-coap-problem-02

Jim Schaad <ietf@augustcellars.com> Mon, 30 March 2020 21:31 UTC

Return-Path: <ietf@augustcellars.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 99C8C3A137B; Mon, 30 Mar 2020 14:31:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id MnulWgVLukBY; Mon, 30 Mar 2020 14:31:42 -0700 (PDT)
Received: from mail2.augustcellars.com (augustcellars.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4090F3A137E; Mon, 30 Mar 2020 14:31:42 -0700 (PDT)
Received: from Jude ( by mail2.augustcellars.com ( with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 30 Mar 2020 14:31:36 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: draft-fossati-core-coap-problem@ietf.org
CC: core@ietf.org
Date: Mon, 30 Mar 2020 14:31:34 -0700
Message-ID: <00cd01d606da$9815a1c0$c840e540$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdYGycO1MeWT5q/ZR2SRe86TscydwA==
Content-Language: en-us
X-Originating-IP: []
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/JDZziihTnaGWeyya9B50yOSIxok>
Subject: [core] Review of draft-fossati-core-coap-problem-02
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
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, 30 Mar 2020 21:31:44 -0000

I have been wondering for some a draft addressing this problem was going to
show up.   I must have missed it last year when it was first published.

*  The abstract should also point to RFC 7807 so that people who understand
that problem set will also be able to find this one.

*  Give that currently RFC 7252 currently says that a server can return
information for diagnostic purposes, I think that there should be a field
defined for that purpose as part of this document as well.  This would not
be the same as what goes into "detail" as this is more debug info than would
be placed that field.  As an example, I might return an error along with a
debug stack when running in specific modes.  I don't want to lose that

*  There seem to be three different points of extensibility.  You are not
documenting the namespace extension point.  I I started reading section 3.1
as if it were namespaces and was running into problems because of that.

*  Are additional attributes defined based on the namespace or on the
problem type?  While I can see both as being true, defining them based on
namespace might be easier to understand.  You might otherwise end up with an
attribute with the same id for different problem types but that mean either
the same thing, almost the same thing or completely different things.

* Are we making any statements about language for the title?

* If negative values are used for private details for a public namespace in
section 5.2.1 - How I am to understand which the different private
registrations are being referred to?  Or are these all expected to be

* Insert into table 4 a row for -2^64 to -L as Private Use.  This makes life
easier on IANA

* Insert in section B.1 that the namespace is not needed because ....  Note
that CoRAL appears to think that additional attributes are based on the
namespace and not on the type.  This would lead to some potential problems
going forward.