IETF Logo Mail Archive

Re: [Ace] ace-coap-est: unclear definition of /.well-known/est URI

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 20 September 2018 14:51 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82970130EAE for <ace@ietfa.amsl.com>; Thu, 20 Sep 2018 07:51:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 zJiC2GFcrtoM for <ace@ietfa.amsl.com>; Thu, 20 Sep 2018 07:51:10 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4232130F39 for <ace@ietf.org>; Thu, 20 Sep 2018 07:51:10 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id DDBCF20496; Thu, 20 Sep 2018 11:10:33 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id 28CB616A5; Thu, 20 Sep 2018 10:51:09 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 23B35169F; Thu, 20 Sep 2018 10:51:09 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Esko Dijk <esko.dijk@iotconsultancy.nl>
cc: "Panos Kampanakis (pkampana)" <pkampana@cisco.com>, "ace@ietf.org" <ace@ietf.org>
In-Reply-To: <DB6P190MB005441A30B3C3414EFF55D5EFD1D0@DB6P190MB0054.EURP190.PROD.OUTLOOK.COM>
References: <DB6P190MB005479015E3F02D4028541A9FD1B0@DB6P190MB0054.EURP190.PROD.OUTLOOK.COM> <39ff6ec1903c4c3a9d333c41a38a1ad9@XCH-ALN-010.cisco.com> <DB6P190MB00548845B38C0B0DF2380CD1FD180@DB6P190MB0054.EURP190.PROD.OUTLOOK.COM> <fc396115e9a54f80babfe9a9f5ae9e74@XCH-ALN-010.cisco.com> <DB6P190MB005441A30B3C3414EFF55D5EFD1D0@DB6P190MB0054.EURP190.PROD.OUTLOOK.COM>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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-sha256"; protocol="application/pgp-signature"
Date: Thu, 20 Sep 2018 10:51:09 -0400
Message-ID: <26476.1537455069@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/0gTYgCcqzQFsorQnDHgvcGWwZOM>
Subject: Re: [Ace] ace-coap-est: unclear definition of /.well-known/est URI
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Sep 2018 14:51:12 -0000

Esko Dijk <esko.dijk@iotconsultancy.nl> wrote:
    > To be fully complete the URIs that can be discovered should also
    > include a port number, as they could be hosted at 5684 or any available
    > UDP port - other than 5683.

    >    coaps://www.example.com:<port>/<est-root-resource>/<short-est>
    >    coaps://www.example.com:<port>/<est-root-resource>/ArbitraryLabel/<short-est>

I didn't think that CoAP resource discovery supports port numbers, does it?

There are some issues with this, specifically because it interacts poorly
with the join proxy mechanism.  (The proxy always forwards to a single port,
and only listens on a single port)

I supppose that's okay, for that usage can be banned for the zero-touch join
mechanisms that use a join proxy.

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

v2.23.0 | Report a Bug | By Email