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

Michael Richardson <mcr+ietf@sandelman.ca> Mon, 21 September 2020 15:11 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 182E23A0A97 for <anima@ietfa.amsl.com>; Mon, 21 Sep 2020 08:11:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 1-Mhiwvsa4hk for <anima@ietfa.amsl.com>; Mon, 21 Sep 2020 08:11:07 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A77793A0A9C for <anima@ietf.org>; Mon, 21 Sep 2020 08:10:43 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 1AEA4389BA for <anima@ietf.org>; Mon, 21 Sep 2020 10:49:21 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id tMhnbj9Q7tR5 for <anima@ietf.org>; Mon, 21 Sep 2020 10:49:17 -0400 (EDT)
Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:103c:9eff:fecb:2eac]) by tuna.sandelman.ca (Postfix) with ESMTP id 460283899C for <anima@ietf.org>; Mon, 21 Sep 2020 10:49:17 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 6722E721 for <anima@ietf.org>; Mon, 21 Sep 2020 11:10:38 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "anima@ietf.org" <anima@ietf.org>
In-Reply-To: <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> <AM8P190MB0979217662D5E18D8693A694FD3A0@AM8P190MB0979.EURP190.PROD.OUTLOOK.COM>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Mon, 21 Sep 2020 11:10:38 -0400
Message-ID: <3231.1600701038@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/tGaXLdl7uBAQpC-PxV0cQAJK7ks>
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 15:11:16 -0000

Esko Dijk <esko.dijk@iotconsultancy.nl> wrote:
    > 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.*

Right.

    > 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

I think that we'd want them all anyway, but if course, we'd get anything else
under ace. (other than est and brski).

    > 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.

Understood, thank you for the fix.

    > 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.

Yes, exactly.

    > 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 ... ?

I also agree.
In my opinion the only reason to do this discovery is to enable multicast RD,
such as I think that brski-ae really wants to do.

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide