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

peter van der Stok <stokcons@xs4all.nl> Thu, 10 May 2018 07:28 UTC

Return-Path: <stokcons@xs4all.nl>
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 11BF112785F for <core@ietfa.amsl.com>; Thu, 10 May 2018 00:28:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 1M3XSJ620tjl for <core@ietfa.amsl.com>; Thu, 10 May 2018 00:28:21 -0700 (PDT)
Received: from lb3-smtp-cloud8.xs4all.net (lb3-smtp-cloud8.xs4all.net [194.109.24.29]) (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 8BDB212E91F for <core@ietf.org>; Thu, 10 May 2018 00:28:20 -0700 (PDT)
Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:216]) by smtp-cloud8.xs4all.net with ESMTPA id GfzofIgGSJwIgGfzofABQc; Thu, 10 May 2018 09:28:19 +0200
Received: from AMontpellier-654-1-136-226.w90-0.abo.wanadoo.fr ([90.0.95.226]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 10 May 2018 09:28:12 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Content-Transfer-Encoding: 7bit
Date: Thu, 10 May 2018 09:28:12 +0200
From: peter van der Stok <stokcons@xs4all.nl>
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
Cc: consultancy@vanderstok.org, "Kovatsch, Matthias" <matthias.kovatsch@siemens.com>, Mohit Sethi <mohit.m.sethi@ericsson.com>, core@ietf.org
Organization: vanderstok consultancy
Reply-To: consultancy@vanderstok.org
Mail-Reply-To: consultancy@vanderstok.org
In-Reply-To: <VI1PR0801MB211246EF59BEBB14D0953029FA990@VI1PR0801MB2112.eurprd08.prod.outlook.com>
References: <VI1PR0801MB2112B9A4410DA3EDE39183BEFA9B0@VI1PR0801MB2112.eurprd08.prod.outlook.com> <bd85e420-c6ce-3e87-406a-4cd5a4fafaa6@ericsson.com> <VI1PR0801MB21121FAE34CE76841CF6DBE1FA9B0@VI1PR0801MB2112.eurprd08.prod.outlook.com> <4EBB3DDD0FBF694CA2A87838DF129B3C01F36340@DEFTHW99EL4MSX.ww902.siemens.net> <f046a8bc9f54328a4c29f9b2426d761e@xs4all.nl> <VI1PR0801MB21120759DA3370D6B44E11E0FA9A0@VI1PR0801MB2112.eurprd08.prod.outlook.com> <6d8a9b8a6c67f7f7022ace8bd9c8d374@xs4all.nl> <VI1PR0801MB211246EF59BEBB14D0953029FA990@VI1PR0801MB2112.eurprd08.prod.outlook.com>
Message-ID: <936152edef2aad1f5258eeb5fb47f64c@xs4all.nl>
X-Sender: stokcons@xs4all.nl
User-Agent: XS4ALL Webmail
X-CMAE-Envelope: MS4wfOsAroj+Bl3c1Ln6c6ltPgsJ2Jx1HD6Q3vvgV2tXWa/opYokGwGe1s3OE9cspnJjOyH/UKpr4sDpMjkpt2QA7PdVb8SKX2VAVcuDjMUYkiQuD6pitqKb 3+p5aqNPkvrMhI6Bjk/lN42QEJ1mI7SbrIYEwhzlLfw1pr3EamFvUX9q9Ey8gc2pEzle6iqg/55AzmgmgJ5mgivbsOyhGb8bu3eDD2ZIISARTUsMwcdtA0Me Bg1aNb7Z5iAOb5yag2dTJrhMy7ecRpZMAl8efNx0ukfjnMjuRDzvjs+nsnc+mJy0
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/c0VQjS8MDlfwoJ3GsGCPJjVVIl0>
Subject: Re: [core] Conclusion -- 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: Thu, 10 May 2018 07:28:24 -0000

Hannes Tschofenig schreef op 2018-05-09 10:20:
> Hi Peter,
> 
> I have not even looked at the con parameter but I wonder how well it
> can work in practice given firewalls and NATs...
> 
Hi Hannes,

some more background.
Resource Directory was originally foreseen to handle unicast resource 
discovery within a Lowpan.
Building installations foresee that the resources and the RD are all 
located within the same administration domain
(e.g. no NATs, or Firewalls between RD and interested endpoints.)
When services administered by the RD are accessed from outside the 
administration domain, the use of DNS is recommended.
For that reason we prepare the RD-DNS-SD draft.
When the Commissioning Tool is outside the administration domain (you 
never know), access from CT to the RD also should pass via DNS IMO.
Independent of the network location of the CT, the CT can for example 
fill link-local addresses into the RD, when RD and endpoints are all on 
the same link.

I think that the best way forward is indeed an additional secure RD 
draft.
I don't know what my co-authors or Matthias think.

Cheerio,

Peter