IETF Logo Mail Archive

Re: [core] Endpoint Client Name / Endpoint Name in RD draft

Carsten Bormann <cabo@tzi.org> Mon, 09 April 2018 08:15 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 4E6041200C5 for <core@ietfa.amsl.com>; Mon, 9 Apr 2018 01:15:03 -0700 (PDT)
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 8jJDaECAV363 for <core@ietfa.amsl.com>; Mon, 9 Apr 2018 01:15:00 -0700 (PDT)
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 A458612420B for <core@ietf.org>; Mon, 9 Apr 2018 01:14:59 -0700 (PDT)
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 w398EttT028379; Mon, 9 Apr 2018 10:14:55 +0200 (CEST)
Received: from [192.168.217.114] (p5DC7FA72.dip0.t-ipconnect.de [93.199.250.114]) (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 40KNQ72KBQzDg31; Mon, 9 Apr 2018 10:14:55 +0200 (CEST)
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: <ca2b6038e911d93e15e57763836a1d09@xs4all.nl>
Date: Mon, 09 Apr 2018 10:14:54 +0200
Cc: Hannes Tschofenig <Hannes.Tschofenig@arm.com>, core@ietf.org
X-Mao-Original-Outgoing-Id: 544954493.176299-008c74f805fb43d103d028f68a52dc75
Content-Transfer-Encoding: quoted-printable
Message-Id: <CB28DFEA-5F9E-4C35-BD86-A37AC5C122C9@tzi.org>
References: <VI1PR0801MB2112B52094B182F5D44C4F64FAA40@VI1PR0801MB2112.eurprd08.prod.outlook.com> <A484D917-677C-4B29-BBAD-DDDE34B50303@ericsson.com> <VI1PR0801MB21128EA2B70DEEE7C5775A62FAA40@VI1PR0801MB2112.eurprd08.prod.outlook.com> <070801d3cc3f$8d59e0c0$a80da240$@augustcellars.com> <VI1PR0801MB2112FB25797DCB8F546C148DFAA40@VI1PR0801MB2112.eurprd08.prod.outlook.com> <7BA9B091-F489-4ED4-B6EC-5AD7D971D6F7@ericsson.com> <VI1PR0801MB2112A692CB307D213A89DFC8FABB0@VI1PR0801MB2112.eurprd08.prod.outlook.com> <ca2b6038e911d93e15e57763836a1d09@xs4all.nl>
To: peter van der Stok <consultancy@vanderstok.org>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/Si1etoZJi2unvtClf4M7u-SPnVk>
Subject: Re: [core] Endpoint Client Name / Endpoint Name in RD draft
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: Mon, 09 Apr 2018 08:15:03 -0000

On Apr 9, 2018, at 10:04, peter van der Stok <stokcons@xs4all.nl> wrote:
> 
> Removing ep identifier will force you to find another identifier for a registration.........

I read Hannes’ proposal as “server [RD] always selects the endpoint name” (as opposed to what is in section 5.3, where the client provides an endpoint name).

The argument seems to be that if a client holds an authorization to register at an RD, that authorization may imply a specific endpoint name.  (I’m not sure that is always true, as the authorization may be based on a claim that does not happen to provide an obvious candidate for that.)

To discuss this further, we’ll need to discuss authorization models for RD access.  Maybe high time in any case…

Grüße, Carsten

v2.23.0 | Report a Bug | By Email