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
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
