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

[Toerless Eckert <[e-mail]>]

Thanks Joe, for reconfirming

Couldn't find any of those service names you listed to point to an RFC, so
i gave up trying to find documentation of the exact formatting.

If a single service instance (IP-addr/port) can support let's say more
than one protocol (variation), then i guess we have to come up with
our own encoding proposal, as there is no standard ?!

  eg: proto=variation1,variation2,...

  (catenate protocols with ",").

I guess this could happen when we come up with different
protocols all running on top of coap (given how the service instance
port number is only bound to the coap layer).

Cheers
    Toerless

On Mon, May 02, 2022 at 07:40:25PM -0700, [e-mail] wrote:
> 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 <[e-mail]> 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dnssd
> 

-- 
---
[e-mail]