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

[Brian E Carpenter <[e-mail]>]

On 13-Dec-20 13:05, Michael Richardson wrote:
> 
> 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.

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?

> Options are:
>   1) throw away that objective and move on to the others, which maybe
>      look right?

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

>   2) throw away the entire message.
> 
> (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