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: esko.d...@iotconsultancy.nl
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
