[Anima] Discovering new BRSKI features / options using CoAP discovery

[Esko Dijk <[e-mail]>]

Hi Toerless, all,

Yesterday in the design team call we discussed that a BRSKI Registrar that offers some "new feature" like BRSKI-PRM must be discoverable as such. For example a Registrar-Agent may want to discover specifically all Registrars that support BRSKI-PRM, or discover all Registrars and be able to see whether they support PRM or not.
For DNS-SD discovery, we now have a proposal to use a Boolean flag in the TXT record keys to signal a "new feature" like PRM.

Now for CoAP (CoRE Link Format) discovery, ideally we want similar "flags" to signal new features, in case needed for the future. (For PRM it doesn't seem needed: the Registrar-Agent could use regular DNS-SD discovery plus HTTPS to talk to the Registrar. CoAP only comes in when talking to the IoT devices. And besides there is no CoAP version of PRM currently defined.)

First to start with the default case of discovering a BRSKI Registrar using a query for 'rt=brski*' one or more responses containing the below resource can be expected. The full list of resources is not shown in the following examples for brevity.

    </b/rv>;rt=brski.rv,

Now to this a new feature could be added. If the "new feature" consists of a new media type for the Voucher, that the Registrar can support, then using the 'ct' attribute can be used to signal that. E.g. to signal additional support of a type 837, besides the type 836 that is defined as 'standard MUST support' for resource type brski.rv , we can have:

    </b/rv>;rt=brski.rv;ct="836 837",

If the "new feature" does not change the Voucher media type or encoding, but has a distinct procedure that is not fully backwards compatible with standard BRSKI then a new resource for it is needed with its distinct resource type (rt) , e.g. :

    </b/rv>;rt=brski.rv,
    </b/rv2>;rt=brski.rvx,

This signals that standard BRSKI is supported at /b/rv while the new feature with new type 'brski.rvx' here is supported at resource /b/rv2.  The 'x' in 'rvx' is just a letter picked for the new feature; it could be any letter or string.

If the "new feature" can be hosted interoperably at the same resource - for example because the data for the new feature is exchanged within the Voucher Request and/or Voucher itself - then the same resource could host the standard BRSKI and the new feature. This can be signaled using 'rt' as follows:

    </b/rv>;rt="brski.rv brski.rvx",

However the Registrar implementer still has the option to not do this but use again 2 separate resources in such case, which may be easier for some implementation/debugging reasons.

If a Registrar implements some combination of multiple new features then the methods of the examples above can be combined.

And yet another option is to define new attributes just like the Boolean flags in DNS-SD. CoRE WG aims to set up a IANA registry for this, see https://datatracker.ietf.org/doc/html/draft-ietf-core-target-attr-04#name-initial-entries for context.
A new Boolean attribute "brski.featname" could for example be registered, to denote support of the "new feature". Then the discovery example becomes:

    </b/rv>;rt=brski.rv;brski.featname,

So that concludes the overview. All in all there's plenty of flexibility to express a particular new feature in the CoAP discovery.

Regards
Esko


IoTconsultancy.nl  |  Email/Teams: [e-mail]