Re: [core] I-D Action: draft-ietf-core-resource-directory-25.txt

Christian Amsüss <christian@amsuess.com> Mon, 13 July 2020 14:17 UTC

Return-Path: <christian@amsuess.com>
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 3F7F83A0901; Mon, 13 Jul 2020 07:17:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nAC3XhNniZrq; Mon, 13 Jul 2020 07:17:20 -0700 (PDT)
Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF4A33A08AA; Mon, 13 Jul 2020 07:17:18 -0700 (PDT)
Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id A25F44000F; Mon, 13 Jul 2020 16:17:16 +0200 (CEST)
Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 72BE4AB; Mon, 13 Jul 2020 16:17:15 +0200 (CEST)
Received: from hephaistos.amsuess.com (unknown [91.112.68.252]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 8F58A64; Mon, 13 Jul 2020 16:17:14 +0200 (CEST)
Received: (nullmailer pid 1127291 invoked by uid 1000); Mon, 13 Jul 2020 14:17:12 -0000
Date: Mon, 13 Jul 2020 16:17:12 +0200
From: Christian Amsüss <christian@amsuess.com>
To: core@ietf.org, Russ Housley <housley@vigilsec.com>, gen-art@ietf.org, Adam Montville <adam.montville.sdo@gmail.com>, secdir@ietf.org
Message-ID: <20200713141712.GA1046809@hephaistos.amsuess.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="LQksG6bCIzRHxTLp"
Content-Disposition: inline
In-Reply-To: <159464772903.29720.7632652711292591125@ietfa.amsl.com> <158421744571.9687.8780686538979770105@ietfa.amsl.com>
Refrences: <158421744571.9687.8780686538979770105@ietfa.amsl.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/_fnOFhGkwetB3GO1eKNzxlJhqGg>
Subject: Re: [core] I-D Action: draft-ietf-core-resource-directory-25.txt
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, 13 Jul 2020 14:17:22 -0000

Hello Russ and Adam,

On Mon, Jul 13, 2020 at 06:42:09AM -0700, internet-drafts@ietf.org wrote:
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-core-resource-directory/

the newly submitted -25 was uploaded to address the points you've
brought up in your respective reviews.

Most noteworthy -- especially because it may affect the secdir review --
are the changes to the security policies section that caught Major
Concerns around the use of concrete security mechanisms.  Discussion
during the April interim meeting[1] has shown that the text had caught a
drift towards giving concrete and detailled (and in some details wrong)
measures without consideration for the bigger picture, which encompasses
a variety of applications with a wild variety of assurances they may or
may not need from an RD.

Consequently, that section that previously stated which parts of the RD
are protected now describes aspects that an application should consider
when deciding on a particular security model to employ.

The remaining changes should be sufficiently described in the changelog
and copied below for completeness.

Thanks again for your reviews
Christian


[1]: https://datatracker.ietf.org/doc/minutes-interim-2020-core-02-202004161500/


Remaining change log:

*  Add concrete suggestions (twice as long as registrant number with
   retries, or UUIDs without) for random endpoint names

*  Point out that simple registration can have faked origins,
   RECOMMEND mitigation when applicable and suggest the Echo mechanism
   to implement it.

*  Reference existing and upcoming specifications for DDOS mitigation
   in CoAP.

*  Explain the provenance of the example's multicast address.

*  Make "SHOULD" of not manipulating foreign registrations a "should"
   and explain how it is enforced

*  Clarify application of RFC6570 to search parameters

*  Syntactic fixes in examples

*  IANA:

   -  Don't announce expected number of registrations (goes to write-
      up)

   -  Include syntax as part of a field's validity in entry
      requirements

*  Editorial changes

   -  Align wording between abstract and introduction

   -  Abbreviation normalization: "ER model", "RD"

   -  RFC8174 boilerplate update

   -  Minor clarity fixes

   -  Markup and layouting

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom