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

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

Michael,

There's a little tweak in the ASA guidelines update for (part of) your issue. Read points 7, 8 and 9 together at:

https://www.ietf.org/archive/id/draft-ietf-anima-asa-guidelines-01.html#section-10-2.7


Regards
   Brian Carpenter
On 13-Dec-20 15:53, Brian E Carpenter wrote:
> 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
>