Re: [core] AD review of draft-ietf-core-object-security-08

Carsten Bormann <cabo@tzi.org> Sun, 25 February 2018 17:47 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 46623126D05; Sun, 25 Feb 2018 09:47:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 3RsaQx3-bgm9; Sun, 25 Feb 2018 09:47:01 -0800 (PST)
Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49942126C83; Sun, 25 Feb 2018 09:47:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w1PHkvnY003589; Sun, 25 Feb 2018 18:46:57 +0100 (CET)
Received: from [192.168.217.114] (p5DC7EAF5.dip0.t-ipconnect.de [93.199.234.245]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3zqC814LVZzDXrm; Sun, 25 Feb 2018 18:46:57 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <5A8849F5.6070703@isode.com>
Date: Sun, 25 Feb 2018 18:46:56 +0100
Cc: draft-ietf-core-object-security.authors@ietf.org, "core@ietf.org WG" <core@ietf.org>
X-Mao-Original-Outgoing-Id: 541273615.212896-f1ad5ee8898984905f11a4ed05331acc
Content-Transfer-Encoding: quoted-printable
Message-Id: <043B8327-B717-44A0-9266-A6531FD3A8C7@tzi.org>
References: <5A8849F5.6070703@isode.com>
To: Alexey Melnikov <alexey.melnikov@isode.com>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/yLGC6quPw7SmOmmkjz3L1pIDNJ4>
Subject: Re: [core] AD review of draft-ietf-core-object-security-08
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.22
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: Sun, 25 Feb 2018 17:47:03 -0000

On Feb 17, 2018, at 16:27, Alexey Melnikov <alexey.melnikov@isode.com> wrote:
> 
> 3) In Section 9: Does "osc" target attribute need to be registered with
> IANA?

Some more details about this one:

RFC 5988 decided not to create a registry for link target attributes, and its replacement, RFC 8288, sustained this decision.

RFC 6690 went ahead and defined two sub-registries for *values* of the link target attributes “rt” and “if”.  Still, the target attribute names themselves are registered nowhere.

A 6690bis effort may very well want to create a registry here, now that RFC 8288 says about Target Attributes (Section 2.2):

   They can be defined both by individual link relation types and by
   link serialisations.

   This specification does not attempt to coordinate the name of target
   attributes, their cardinality, or use.  Those creating and
   maintaining serialisations SHOULD coordinate their target attributes
   to avoid conflicts in semantics or syntax and MAY define their own
   registries of target attributes.

So, in addition to individual link relation types, RFC6690 or a successor specification, as a serialization of Web Links, is the place where such a registry could be defined.

Until that happens, OSCORE is exactly right in proceeding in the same way RFC 7641 (Observe) did for “obs”.

Grüße, Carsten