Re: [Anima] constrained handling of endpoint path names (from BRSKI-AE discussion today)

Esko Dijk <esko.dijk@iotconsultancy.nl> Mon, 21 September 2020 09:08 UTC

Return-Path: <esko.dijk@iotconsultancy.nl>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E84933A0AFE for <anima@ietfa.amsl.com>; Mon, 21 Sep 2020 02:08:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-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=iotconsultancy.nl
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 PGuIvsTjcf2s for <anima@ietfa.amsl.com>; Mon, 21 Sep 2020 02:08:09 -0700 (PDT)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140120.outbound.protection.outlook.com [40.107.14.120]) (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 4A1453A0AF6 for <anima@ietf.org>; Mon, 21 Sep 2020 02:08:08 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ybbn4FI9W76j9e16QoYtoYsaWAyqg4L0LTWwxqE3/tLkLf2v83y2CX6vOwgcoasouF4zMXJBnmpPn5TU0DAwrk9sFWtisHg1rUQrQE0eCn2o/7rJUEdm/xVdmh8BuzKLTyc2Id/JqtkZdh7yETI5cEifhjw4p4AWO67d0leVBbFFU5B0K+0AxGZQmRBpBFcNrqSc5snjE2xlxOBkWUqDir+4MJ6a9o7VcPxHEbxZpgVoMH8HVfONrF3ICH9ZtY1VW9kDK9PKva2esIWHeh54IQ+3v31UnTvZcfJu5fYNi7poXouds5p1/Em3krGaZI8nsYEnXA/F/rtecpadMjzb1Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=uwWVFqkAwYb3gtXgOhXZIsFDelbNqSJhNnyWpc9iyS0=; b=mGIH2t8GsdKrrRdEyLFCvrQE/mmbV3o3VDk/RUAMDs3/FZzMrO7Vko8s4IMQPuunkZXAlLDE4zprdAlJgN4oGLsFz5vCc0OKGRlpld/mPM4c6wFNivT7/15VcNgHt9f5JfWyOECHzELSb3PaxUkkM4VFWp9kyvo2jFljCUO3toZxoq8yXXr+0yg/nRhR+eC7VMaNBL0wSot7cuB164zkB30fHbnBesWLndaVKkUMaDqcOnkN/gGYBKrGgpg7goTt/10FKxApe2En0BS45RpLL/88WvTsz0xE1RfrPInT5lsccokwOJnbyMpBNo+A9QgRV5T3C+dHwWyGVqw3WwBUeA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=iotconsultancy.nl; dmarc=pass action=none header.from=iotconsultancy.nl; dkim=pass header.d=iotconsultancy.nl; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iotconsultancy.nl; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=uwWVFqkAwYb3gtXgOhXZIsFDelbNqSJhNnyWpc9iyS0=; b=Y5eNq2d5m+jk6VfIrm/3iXOJv015su4f/zl5/Dqr0g2dX7jCAotL3jp0oEYHXsS3xoU6r7hf2F0CRaxas7xnUomHO++/494jXIyOlW5oE2Q9bpDxYhy0zyZ8sEUbWkhl6dxlMIYN9kYJWBMQOWetwzrY8F20uhd7UgYT8jrr4o0=
Received: from AM8P190MB0979.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:1d3::8) by AM8P190MB0881.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:1da::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3391.14; Mon, 21 Sep 2020 09:08:05 +0000
Received: from AM8P190MB0979.EURP190.PROD.OUTLOOK.COM ([fe80::fcd5:1600:7331:bb3a]) by AM8P190MB0979.EURP190.PROD.OUTLOOK.COM ([fe80::fcd5:1600:7331:bb3a%6]) with mapi id 15.20.3391.011; Mon, 21 Sep 2020 09:08:05 +0000
From: Esko Dijk <esko.dijk@iotconsultancy.nl>
To: Michael Richardson <mcr+ietf@sandelman.ca>, "Werner, Thomas" <thomas-werner@siemens.com>, "anima@ietf.org" <anima@ietf.org>, "steffen.fries@siemens.com" <steffen.fries@siemens.com>
Thread-Topic: constrained handling of endpoint path names (from BRSKI-AE discussion today)
Thread-Index: AQHWjfZJL0lmPelW+EGuE9/wrAlJhqlyzcmA
Date: Mon, 21 Sep 2020 09:08:05 +0000
Message-ID: <AM8P190MB0979217662D5E18D8693A694FD3A0@AM8P190MB0979.EURP190.PROD.OUTLOOK.COM>
References: <3f2d1790efb44ac39405a23dc592dd89@siemens.com> <20200730161142.GB62130@faui48f.informatik.uni-erlangen.de> <12431.1596541563@dooku> <2c4323c817134845ae7c36b41fd239c1@siemens.com> <11029.1596647559@localhost> <eee14f13f5cf4183bf69e999c5fcea04@siemens.com> <6058.1597841627@localhost> <f3981ca4bde844dbb27213ae96185967@siemens.com> <AM0PR10MB195606BD9019E5E94244175DE7540@AM0PR10MB1956.EURPRD10.PROD.OUTLOOK.COM> <AM8P190MB0979CE69D3BB9F5C302CFCB8FD3F0@AM8P190MB0979.EURP190.PROD.OUTLOOK.COM> <102939.1600459193@dooku>
In-Reply-To: <102939.1600459193@dooku>
Accept-Language: en-US, nl-NL
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: sandelman.ca; dkim=none (message not signed) header.d=none;sandelman.ca; dmarc=none action=none header.from=iotconsultancy.nl;
x-originating-ip: [85.147.167.236]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 603d03cf-fe38-420f-3539-08d85e0dd9ac
x-ms-traffictypediagnostic: AM8P190MB0881:
x-microsoft-antispam-prvs: <AM8P190MB088183C3D03B1E91E06AB1A1FD3A0@AM8P190MB0881.EURP190.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: oqeJRqJaQN3KTnhdW8nJOuwosohRpmiHiYPWyJ7BDQWHVjrG/8Yuh1ykHSlBT6CnnOSXdC0wMKo3l6OgMr0dxvvtQWFMMDldbjheOjS/v9JxuQ7Mz7P5T+5ENst1LDDeimyn+9Vx8Unsh29X5IYSZjAsnPJF9XEz7KJUdy6tVsaKczHSH6ARg7Uwa2tAdkOCmdYuopnHcGl7SbgEIW/0Wqkvz1Ue8ojI+IgKd2CLAEWcfdeZSy3fi6ij2PDxRzzKu+o8EGaBeHMM5ueXJXdJqreIEGYgWchN3JO1Y3nAm8LHA0/RFwBdJMIltUXBbNsgUSeRryAf9CbBVDXTiMFRAtYMnekyxTolThyjzrQTCrhOZW6721/P8JnfEm1pwuyy4eWvAUrvyHoKhmpGS2vvRXb73nxBsxvtTzcXv45mnu7pibvfn+6vpJPiU8Zu5mJzbdaIrsKU+dTcPBtjh4nqNw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM8P190MB0979.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(376002)(346002)(366004)(136003)(396003)(39830400003)(71200400001)(8936002)(44832011)(83380400001)(8676002)(86362001)(26005)(316002)(186003)(478600001)(7696005)(9686003)(55016002)(110136005)(33656002)(5660300002)(66476007)(2906002)(66556008)(66946007)(66446008)(64756008)(53546011)(6506007)(76116006)(52536014)(966005)(166863002); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: SVDg1ipfp3KFRUAMV3zPnqCLVrqS4kPr5gAiM3hmySc4GLoVBfkU6289zAXEjoekYfy8liHrxlSCpXE9XcajcrI6xo0Q0Wdeaxqy0V0JYasYPUIRslAzvW3Ilw3B5OOneQV6T1pc918V4c9c0pQ4I2gdoG3MkPGF0+dOd/4+iuDXnUB5WtG5huER892LtGfgj0DLAcu7XRc7u1KEoMbou4ZaLFfyBp9lYatc42eC51fA66xg+Zwl4LutoOHqud40ZLb2J/eX+lDV8+r1+8N/hu3+ZKW4lmAbb5DEhVKJI8Dlva1+z0zkiyS9jn4PtIcjTe0YbISJQxZDzruDZcHrxUX6x45aLOPZAIdrdX+t7A3eLFCa4TNsi+pJ4ZsDoadOIka7o8gwTpDgpOsYOvWgyiOy7ffkh6tIsARwunPb9kK3tWVmnPh0wNdlJFqLR41ur35sopKDD3+iDN/D3UPnFeeo+x653i4tYxagtrg4PJ6Y0Ehdx4W2UilUBGiA7PuAR00aPdOjn8n9cxqww8/nV7umRWPvWAMqUIwznLFbFifz1Y6CNFkpdChDnJVvWI97skHLkqumRqnpBkzd9fjsHZl6EL8uDn98mvQOFX007mPmjNDuo8L89hsrWCV2jOHvZwBsFwOMU8T5gNMfEMWLlw==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: iotconsultancy.nl
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM8P190MB0979.EURP190.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 603d03cf-fe38-420f-3539-08d85e0dd9ac
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Sep 2020 09:08:05.1676 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 58bbf628-15d2-46bc-820b-863b6774d44b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: x/yxyHNhWTJbvFR1WLE3Q5J/GIF6CsvYNHn+yJ+2ULZxUHmlkLgv0Th93z+NA9YKskrbmJodZDYURnhGL4lubEbxS3ucUd4/OqFXaUjyutM=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8P190MB0881
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/bqGSzFT39xxkZgqkIamQvLbsylk>
Subject: Re: [Anima] constrained handling of endpoint path names (from BRSKI-AE discussion today)
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Sep 2020 09:08:12 -0000

I added some comments on below questions on Github https://github.com/anima-wg/constrained-voucher/issues/51 .

In summary, you can ask for both resources of type ace.est and ace.brski by doing a wildcard query:
GET /.well-known/core?rt=ace.*

However this not only returns the two (intended?) resources ace.est and ace.brski, but also all the subtypes of these which is: 
ace.est.rv, ace.est.vs, ace.est.es, ace.est.ra

Note that the '/' in the rt name is not permitted by RFC 6690, it should be a '.' to indicate the hierarchy here. Created issues #54 for this.

Alternatively one can discover two times:
GET /.well-known/core?rt=ace.est
GET /.well-known/core?rt=ace.brski

This gets exactly the main resources but not the sub-resources below it separately. From the main resources the sub-resources are automatically inferred (i.e. the standard names 'rv', 'vs', 'es', and 'ra'.)
Doing this will reduce the amount of data transferred over the constrained network but adds an extra message roundtrip.

Section 9.1 needs to be extended to a proper IANA registration, and it should include these types:
ace.est
ace.est.rv
ace.est.vs
ace.est.es
ace.est.ra
(or the equivalent types 'ace.brski.*' in case we decide to change namespace est to brski  . Or maybe consider 'anima.brski.*'  or just 'brski.*' as the root rt namespace because BRSKI originated not in ACE WG scope but in ANIMA WG! )

Note that in my opinion all this discovery adds unnecessary complexity and overhead in the constrained node/network, so I created a proposal to also allow the .well-known resources that BRSKI is already using.  Why make something less efficient than the unconstrained protocol and force clients to use it ... ?
See issue #53  https://github.com/anima-wg/constrained-voucher/issues/53 
Note that ACE-coap-EST also supports the .well-known resources.

Esko

-----Original Message-----
From: Michael Richardson <mcr+ietf@sandelman.ca> 
Sent: Friday, September 18, 2020 22:00
To: Esko Dijk <esko.dijk@iotconsultancy.nl>nl>; Werner, Thomas <thomas-werner@siemens.com>om>; anima@ietf.org; steffen.fries@siemens.com
Subject: constrained handling of endpoint path names (from BRSKI-AE discussion today)


Esko Dijk <esko.dijk@iotconsultancy.nl> wrote:
    > I created a Github issue for constrained-voucher to capture the outcome
    > of this discussion:
    > https://github.com/anima-wg/constrained-voucher/issues/51

Thank you.

    > (Reminder: There are also a couple of more open issues. I can work on
    > these too and have already contacted Peter about these.)

I think that we can finally start digging these items out of the ditch
created by ACP and BRSKI stalling up the process.

In constrained-voucher/brski, there is a CoAP RD call:

     REQ: GET /.well-known/core?rt=ace.est*

     RES: 2.05 Content
     </est>; rt="ace.est"
     </est/rv>; rt="ace.est/rv";ct=TBD2 TBD3
     </est/vs>; rt="ace.est/vs";ct=50 60
     </est/es>; rt="ace.est/es";ct=50 60
     </est/ra>; rt="ace.est/ra";ct=TBD2 TBD3

I don't really know how to ask for multiple things.
  Clearly, we should be asking for "ace.brski" now?
  Do we have to change our allocation somewhere?
  I don't see any IANA activity around rt=ace.est/rv, unless it's section 9.1?
  which regisgters things, but I don't understand why it asks for ranges,
  because I have no idea where those *numbers* would go.
  I probably just don't know enough about this stuff.

I think that RFC6690 should probably be a normative reference.

I guess that we would have gotten all of the end points associated with
draft-ietf-ace-coaps-est when we above asked for ace.est.

RFC6690, section 4.1 [
   https://www.rfc-editor.org/rfc/rfc6690.html#section-4.1 ]

does not seem to permit two or three things to be returned, just wildcards.
What would happen if, when asked for rt=anima.brski, that it returned the
entries for ace.est and/or blah.cmp?

Is it late enough that we could just switch to CoRAL?
Do I even understand what means.

-- 
Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-