Re: [dnssd] DNS-SD TXT question (for ANIMA use).

"touch@strayalpha.com" <touch@strayalpha.com> Tue, 03 May 2022 02:40 UTC

Return-Path: <touch@strayalpha.com>
X-Original-To: dnssd@ietfa.amsl.com
Delivered-To: dnssd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A605C14F733; Mon, 2 May 2022 19:40:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.317
X-Spam-Level:
X-Spam-Status: No, score=-1.317 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_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yA7ReIn4yS70; Mon, 2 May 2022 19:40:37 -0700 (PDT)
Received: from server217-1.web-hosting.com (server217-1.web-hosting.com [198.54.114.226]) (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 07650C14F72F; Mon, 2 May 2022 19:40:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=7LzyiMcT8oy4W7bJdRxn1dAIly/nSbMaUqaCkNPL29c=; b=WhYn5EcVaZtJMRVRzgWvhUNO5k vx/64EYi9hEz3h5kKewDtjfRReRL295r6qizKuOqSyHnxvpDItIJWkIYfxBjw+/8qofONWUp+M3GU LlLyEv7+1j3n9cAhdHXxh7IM5t6DPA8Tkd4oxfqQeWcphAMybqNyOAGmq4RICulL7pTdWGyNDf5X4 PMLtkGKchCIo11gC+qcT2zaTL83sL08Lj/uRdlJtmSpo91i7EINSogf3GdHqqPjOFKvkHlb2RmbWL 91KbNjTaE2komf0Pp8ewySejEQz9vavI4u8LVzvIeyHwPnTPms2gtIttkSFyHBqPrgkOyPAMzrf4I TPvuKgxw==;
Received: from cpe-172-114-237-88.socal.res.rr.com ([172.114.237.88]:64076 helo=smtpclient.apple) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from <touch@strayalpha.com>) id 1nliSj-006G3e-TW; Mon, 02 May 2022 22:40:34 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_AD9028B6-AFB2-4DB6-889B-AAE8303C0084"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.80.82.1.1\))
From: "touch@strayalpha.com" <touch@strayalpha.com>
In-Reply-To: <Ym6j/8qhEzvqNw2V@faui48e.informatik.uni-erlangen.de>
Date: Mon, 02 May 2022 19:40:25 -0700
Cc: dnssd@ietf.org, anima@ietf.org, cheshire@apple.com
Message-Id: <BECA0397-5B8B-4DAB-8706-D5727F86F73A@strayalpha.com>
References: <Ym6j/8qhEzvqNw2V@faui48e.informatik.uni-erlangen.de>
To: Toerless Eckert <tte@cs.fau.de>
X-Mailer: Apple Mail (2.3696.80.82.1.1)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/_r_PX2Ti8ERWqGua8_9Oq6lIO-U>
Subject: Re: [dnssd] DNS-SD TXT question (for ANIMA use).
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 May 2022 02:40:41 -0000

Hi, Toerless,

A bunch of port assignments use TXT records to indicate protocol version or security algorithm,. Those are all arguably similar to being able to support multiple protocols.
buddycloud-api, bluevertise, obf, railduino, sparql, spearcat, spearcat, tbricks, tivo-remote, and tivo-videos all appear to use TXT records to indicate “protocol” or something similar.
If the service is typically discovered by DNS-SD, I would think using TXT records this way would be a good solution. It would also allow discovery to occur more quickly than polling for multiple service names if the user can support multiples but needs to know what the server supports.

Joe

—
Dr. Joe Touch, temporal epistemologist
www.strayalpha.com

> On May 1, 2022, at 8:15 AM, Toerless Eckert <tte@cs.fau.de> wrote:
> 
> In ANIMA, we do have a bootstrp service (RFC8995), which has two service
> points, registrar and proxy. We primarily use GRASP and not DNS-SD
> for its "original" instance (with RFC8994), but we also defined service
> names brski-proxy / brski-registrar.
> 
> Now we're working on variations of this service, where the overall idea
> of the service is the same, but the protocol run across the service points
> gets new options. Originally it is EST (RFC7030) over TLS, now we added
> two new protocol options: EST over COAP over DTLS (stateful), and EST over COAP over
> DTLS with our own new shim header (stateless). Note that in these new
> versions actual use of DNS-SD instead of GRASP is more likely, so the
> question how to do this for DNS-SD is more interesting now.
> 
> So, now comes the question of how to do service discovery for the different
> options. And likely this may not be the latest options, there may also be
> something likee CMP over COAP over DTLS or whatever else the industry wants.
> 
> Right now, the proposal of the draft (draft-ietf-anima-constrained-join-proxy)
> is to allocate new service-names: brski-jp / brski-rjp. If we do this,
> it would i think lead us down the road of creating a new set of 2 service
> names for every protocol variation we run across the service points.
> For example with just brski-jp / brski-rjp, we would not be able to
> distinguish the stateful /stateless variations.
> 
> Instead, i was wondering if it would not be better to stick to just the two
> service name and simply distinguish the protocol variations through a TXT
> parameter:
> 
>      service-name: brski-registrar, TXT key: proto=EST-COAP-DTLS      # cBRSKI stateful
>      service-name: brski-registrar, TXT key: proto=EST-COAP-DTLS-SL   # cBRSKI stateless
>      service-name: brski-registrar, TXT key: proto=EST-TLS            # BRSKI
> 
>      service-name: brski-proxy,     TXT key: proto=EST-COAP-DTLS      # cBRSKI stateful
>      service-name: brski-proxy,     TXT key: proto=EST-COAP-DTLS-SL   # cBRSKI stateless
>      service-name: brski-proxy,     TXT key: proto=EST-TLS            # BRSKI
> 
> Thoughts ?
> 
> The way i see it, this should be better ? True ?
> 
> Are there pre-existing examples of selecting services based on TXT keys, e.g.:
> where multiple service point instances differ by a TXT key value and the client
> selects based on that ? Printer protocol ? ;-) (printers being classical example).
> 
> Downsides ?
> 
> Registration wise, we could introduce into the IANA BRSKI registry the TXT key values
> as a new table to track the values/RFCs given how the service-name registry does
> not really do this (TXT key only in notes colum, but without values).
> 
> Cheers
>    Toerless
> 
> _______________________________________________
> dnssd mailing list
> dnssd@ietf.org
> https://www.ietf.org/mailman/listinfo/dnssd