Re: [core] AD review of draft-ietf-core-resource-directory-23

Alexey Melnikov <alexey.melnikov@isode.com> Thu, 16 April 2020 12:13 UTC

Return-Path: <alexey.melnikov@isode.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 2C9B93A1599 for <core@ietfa.amsl.com>; Thu, 16 Apr 2020 05:13:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.699
X-Spam-Level:
X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com
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 OIk9EKqUvfu9 for <core@ietfa.amsl.com>; Thu, 16 Apr 2020 05:13:42 -0700 (PDT)
Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id E3D7E3A1598 for <core@ietf.org>; Thu, 16 Apr 2020 05:13:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1587039220; d=isode.com; s=june2016; i=@isode.com; bh=MtTFh8VYtTyTe+2DVg7AwfsWap+hhp6Bl6T2DYsQ+9w=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=tQG8d0XjdCfZS0NffJLw/yglukSEN1bieo8zDv2p/r4S6bqZG4NaYWUVGBmljY829z41SJ grUvdxkzJpLa+wIn+0sd5P2HE9hNedeLkzX/JQDp6KMYxBa7cBY7xh7Rt5SAsS1LUUJ4ud 8W+S873/m6Sv53h5XwFdlpN+S207LaI=;
Received: from [172.27.254.130] (connect.isode.net [172.20.0.72]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id <XphL8ABqwcc0@waldorf.isode.com>; Thu, 16 Apr 2020 13:13:40 +0100
To: Jaime Jiménez <jaime@iki.fi>, "core@ietf.org" <core@ietf.org>
Cc: Barry Leiba <barryleiba@computer.org>, Christian Amsüss <christian@amsuess.com>, Marco Tiloca <marco.tiloca@ri.se>
References: <481f9820-bcea-af6a-d5c4-d713be24d43d@isode.com> <ce656ebd-2175-682e-293f-3b81531d03d3@isode.com> <b9d767f8-341a-4c2a-b592-439b1aca6f36@www.fastmail.com>
From: Alexey Melnikov <alexey.melnikov@isode.com>
Message-ID: <ae660e23-e508-3b8e-9251-2e3b86aab0e0@isode.com>
Date: Thu, 16 Apr 2020 13:13:27 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1
In-Reply-To: <b9d767f8-341a-4c2a-b592-439b1aca6f36@www.fastmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/dcQNTacCakSac3_U1HIGGOWLmFg>
Subject: Re: [core] AD review of draft-ietf-core-resource-directory-23
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: Thu, 16 Apr 2020 12:13:43 -0000

Hi Jaime,

On 16/04/2020 11:35, Jaime Jiménez wrote:
> Dear all,
>
> sorry for the delay on this discussion. We have had a parallel thread and now I realise the discussion was not on the list nor with the ADs on it.
Yes, that didn't help ;-).
> Christian can correct me but the current situation is that the two outstanding issues can be solved:
>
>>>     This section describes how the registering endpoint can maintain the
>>>     registrations that it created.  The registering endpoint can be the
>>>     registrant-ep or the CT.  An endpoint SHOULD NOT use this interface
>>>
>>> Why SHOULD NOT (instead of MUST NOT) and how is this enforced?
> There was a previous reply from Christian on this, which makes me (and I suppose others) to lean towards keeping the SHOULD  NOT.
>
> "This is more expressing the intention than anything enforcable. Frankly,
> it is a bit imprecise: The goal is to discourage any agents enumerating
> registrations from the endpoint lookup and trying to enhance them.
> Endpoints switching addresses (thus technically becoming different
> endpoints) and updating their registration is encouraged.
>
> There are some cases in the middle we probably don't want to rule out
> but caution against, invoking "SHOULD"'s "know what you're doing" which
> we may not want to rule out (but have not discussed).
>
> In the end, enforcement is up to the security policy -- if an agent
> knows a registration URI and has the authorization to act on it, that
> will succeed."

Two comments on this:

1) If this is not supposed to be enforcable, then the document shouldn't 
use RFC 2119 language in this sentence, I think lowercase "should" would 
be much better.

2) This is related to my question (I believe I've asked it earlier) 
about how security policy is going to be implemented in relationship to 
resource directory. What are the current or expected mechanism? The 
document is silent about that and this causes me concerns.

>>>     for registrations that it did not create.  The registrations are
>>>     resources of the RD.
>>    [snip]
>>> At the end of section 9.3:
>>>     It is expected that the registry will receive between 5 and 50
>>> registrations in total over the next years.
>>>
>>> This will not age well! Maybe remove this text from the document and
>>> add it to the spherding write-up?
> Christian will remove the paragraph and I'll update the writeup.

Great.

Best Regards,

Alexey