[core] coap discovery

Peter van der Stok <stokcons@bbhmail.nl> Fri, 13 August 2021 07:24 UTC

Return-Path: <stokcons@bbhmail.nl>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 34B1A3A1027 for <core@ietfa.amsl.com>; Fri, 13 Aug 2021 00:24:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.093
X-Spam-Status: No, score=-2.093 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=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=bbhmail.nl
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 8S20iCos7DHU for <core@ietfa.amsl.com>; Fri, 13 Aug 2021 00:24:39 -0700 (PDT)
Received: from smtprelay.hostedemail.com (smtprelay0071.hostedemail.com []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 655A53A1022 for <core@ietf.org>; Fri, 13 Aug 2021 00:24:38 -0700 (PDT)
Received: from omf12.hostedemail.com (clb03-v110.bra.tucows.net []) by smtprelay07.hostedemail.com (Postfix) with ESMTP id 93562181D2FC2 for <core@ietf.org>; Fri, 13 Aug 2021 07:24:35 +0000 (UTC)
Received: from [HIDDEN] (Authenticated sender: stokcons@bbhmail.nl) by omf12.hostedemail.com (Postfix) with ESMTPA id 65DE624023B for <core@ietf.org>; Fri, 13 Aug 2021 07:24:35 +0000 (UTC)
MIME-Version: 1.0
Date: Fri, 13 Aug 2021 09:24:34 +0200
From: Peter van der Stok <stokcons@bbhmail.nl>
To: core@ietf.org
Reply-To: stokcons@bbhmail.nl
User-Agent: Roundcube Webmail/1.4.11
Message-ID: <4795365b6cd768eb1b9500e0e96736b4@bbhmail.nl>
X-Sender: stokcons@bbhmail.nl
Organization: vanderstok consultancy
Content-Type: multipart/alternative; boundary="=_00fce87b88e9080bb31035000bc0256a"
X-Rspamd-Server: rspamout01
X-Rspamd-Queue-Id: 65DE624023B
X-Stat-Signature: 6jx74xorekf4n7scfizum7ropaam96rd
X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C
X-Session-ID: U2FsdGVkX1+i2yEVVZZD1sVgv02asBPSyVa8JqlJ550=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bbhmail.nl; h=mime-version:date:from:to:subject:reply-to:message-id:content-type; s=key; bh=rWVjYW5qupq6zaqs4P5KKHdezuaF6coQ233ov+23rXk=; b=PekCdVa28RO2gxbYD0l2qQnv8MqHqmztS+O/mA1e0E0xZrnt1xhgX1qNIblHJeBHyAp0MRnSQ5M2UuvMvOxV3cpxAl4RK66clMRA+1ZodJ5L7ZhV+7Tv+OsaK/gAgufg1MPm0jeNoq9586/sNju1pxe6/gF8xpyxqhssJCYDM/E=
X-HE-Tag: 1628839475-805874
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/JS-x67JcoJZ5efBJXheiyucCiJc>
Subject: [core] coap discovery
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 13 Aug 2021 07:24:45 -0000


We met a problem with the specification of "join-proxy" used for the 
BRSKI protocol in ANIMA,

The join-proxy provides the connection between a new device (called 
pledge) and the registrar that authorizes the access to the network
for the pledge.
The join-proxy is an authorized node that can route messages to the 
The join-proxy also provides coap services on the network.
The pledge has only link-local acccess to a neighbour join-proxy

The pledge sends a link-local DTLS coap request to a resource on the 
join-proxy accessable via a non-coap port on the join-proxy.
The join-proxy copies the messages received on that port and sends them 
on to a non-standard discoverable port of the Registrar.
The join-proxy resources on the join-proxy are discoverable with  rt= 

The pledge discovers the join-proxy resources and their non-standard 
port with coap discovery.

The protocol between join-proxy and Registrar is not coaps but an UDP 
protocol that forwards the coaps messages to the Registrar.
However, the join-proxy discovers the Registrar port by discovering a 
related coap resource and its port on the Registrar with rt = brski-yyy

Is this a legitimate use of coap discovery to discover the non-standard 
ports on join proxy and Registrar?

thanks for comments, or suggestions,

Peter van der Stok
vanderstok consultancy
mailto: stokcons@bbhmail.nl
tel NL: +31(0)492474673     F: +33(0)468839947