Dear all,
Given that one of my students is about to start a project that will
model BRSKI and Constrained BRSKI, I am all in favor of "simplify and
streamline".
Bill
On 6/22/2023 10:57 AM, Esko Dijk wrote:
Attention This email originates from outside the concordia.ca domain. //
Ce courriel provient de l'extérieur du domaine de concordia.ca
Hi all,
Based on our writing and implementation experience so far for
draft-ietf-anima-constrained-voucher, I see some opportunity to simplify
and streamline the main procedure and its description.
The idea is to have one main flow description that relies a lot on
sensible defaults, and move any “alternatives” or “extras”, or “special
cases” to separate sections in the end of the document.
That should make it more comprehensible for those wanting to implement
the basic constrained BRSKI method and also improve interoperability.
For example quite some CoAP resource discovery things are explained but
my implementation doesn’t use it; and it doesn’t seem to add value for
the “default” case.
See https://github.com/anima-wg/constrained-voucher/issues/269
<https://github.com/anima-wg/constrained-voucher/issues/269 for Github issue created for this.
I could create a PR to show how it may look like.
Any opinions on this?
Regards
Esko
*IoTconsultancy.nl* | Email/Teams: [email protected]
<mailto:[email protected]> | +31 6 2385 8339
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
--
Dr. J.W. Atwood, Eng. tel: +1 (514) 848-2424 x3046
Distinguished Professor Emeritus fax: +1 (514) 848-2830
Department of Computer Science
and Software Engineering
Concordia University ER 1234 email:[email protected]
1455 de Maisonneuve Blvd. West http://users.encs.concordia.ca/~bill
Montreal, Quebec Canada H3G 1M8
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima