Subject: [Anima] question about future-proofing of GRASP objectives

From: Michael Richardson <[email-masked]>
Date: Sat, 12 Dec 2020 19:05:12 -0500

GRASP objectives look like:

  objective = [objective-name, objective-flags, loop-count, ?objective-value]
  objective-name = text ;see section "Format of Objective Options"
  objective-flags = uint .bits objective-flag
  loop-count = 0..255

so, ['string', uint, uint, otherstuff]

There can be an array of objectives.
If any of the objectives do not match the above CDDL, what do I do?
Options are:
  1) throw away that objective and move on to the others, which maybe
     look right?
  2) throw away the entire message.

(2) is certainly easier to code.
(1) seems way more future proof.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 13 Dec 2020 15:53:42 +1300

> There can be an array of objectives.

Right, but only in an M_FLOOD message at present. Of course, we could
in theory add other message formats with multiple objectives.

> If any of the objectives do not match the above CDDL, what do I do?

A related question was raised on the API draft by Ben Kaduk: how do we
apply the (new) recommendations on CBOR validation in RFC8949?

>   1) throw away that objective and move on to the others, which maybe

I would say that by the nature of M_FLOOD,  that is the logically
correct approach.

> (2) is certainly easier to code.

Each objective is a self-contained CBOR array, so could
be parsed quite independently of the others.
[pause to glance at my code]
However, I did do it the lazy way, i.e. the parsing loop exits
on the first error. (If you look at my code, that's in the
elif ... M_FLOOD case inside _parse_msg().) 

It would indeed be a little more work to skip the faulty objectives
and process the valid ones. I probably should add that to my
code since it would be useful for debugging.

> (1) seems way more future proof.

It depends on whether you prefer the Postel principle or
draft-iab-use-it-or-lose-it. 

Regards
     Brian