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

Brian E Carpenter <brian.e.carpenter@gmail.com> Sat, 26 June 2021 23:12 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB233A0930 for <anima@ietfa.amsl.com>; Sat, 26 Jun 2021 16:12:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.436
X-Spam-Level:
X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.338, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zhcidvEiL3Gd for <anima@ietfa.amsl.com>; Sat, 26 Jun 2021 16:12:05 -0700 (PDT)
Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A1C63A092E for <anima@ietf.org>; Sat, 26 Jun 2021 16:12:05 -0700 (PDT)
Received: by mail-pl1-x62e.google.com with SMTP id d1so6048263plg.6 for <anima@ietf.org>; Sat, 26 Jun 2021 16:12:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=wGZVuOXkqKs0vPBLdFV193lZJhCX863QFL8ZWa1Ml9E=; b=NKmO1WXaZK8xHWI6gwMH8TfAm1zlQyUErDjH1WqpS09hpz0vdkk/7xG9roLBUXotz4 Vl1Yk5dZ4VjPU5rxZs6O211kI6yFIRaS4jZzDiDsj0uZs4GH9Npjyp9hD7aJ8yk6sr/x EqI+1aB2PvFbcKobQmAL2cGDSHNCBHuKMAxIq871sRdlF9yCl2n7LoDsgu+MQGUCQBcM ghgWav/ccPkdsCNlQfvS/dz+m2/hKFqzrdVsY3COknztFVTGfSIqyAFK3xe+/AH8dNM6 sMu9b6PRQ5mjqIQnWcunw9+seQ6Us6DXvMdP0qQxHuXTYZN0vIbExPp4i8ZPUdrL+OpU zA6Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=wGZVuOXkqKs0vPBLdFV193lZJhCX863QFL8ZWa1Ml9E=; b=SAJ9VQG8U0Bxrose4gJoVy0vecxyPDJ3Z3Go1C0QTz82uiiG80Yu8AnAAu7Gvko0HF 2MpbJt6PO62eiFenFXSBwxKLao/TP+BUqJujCRY4m2BoOESgW2QEMBWiBSUFf3gdSrsm uGYCRZWWCFpp2/ts/Ezp+kawTA2BtYYA24B8AH/+rg7+Hi8UVdXQ+ItpMX32XjUUp2WA Q/H2YxINpAhDPqBvkpu+tYRnIsL1Y60Xk0QfZVEwyXo+LWiJmKKCNG/zGnykOR/EIu9h 0gBu7RcLlHF8LKFz6157AR7Kn2hNQCAuis8vckDr7DnGbp1PO5tAKteD3+damrQFalVz XLwA==
X-Gm-Message-State: AOAM533R9Cx3R912SQB1vUAKSoItFxKXrop+gjRRWQd8fAUoNg/XY4Ch MsrTjhpUsx3umdNgbsNCOe5jtuRgqFLNkA==
X-Google-Smtp-Source: ABdhPJz0Nw0s5rIVamWSJ6AatWu9Ho1g1WWNX1JRvpDrvkgNqKNV4G4lqXJ0hXcWhz07OkroGMDifg==
X-Received: by 2002:a17:902:d890:b029:11d:83:7702 with SMTP id b16-20020a170902d890b029011d00837702mr15553942plz.14.1624749123973; Sat, 26 Jun 2021 16:12:03 -0700 (PDT)
Received: from ?IPv6:2406:e003:100d:901:80b2:5c79:2266:e431? ([2406:e003:100d:901:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id c2sm2049236pjc.40.2021.06.26.16.12.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 26 Jun 2021 16:12:03 -0700 (PDT)
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>, anima@ietf.org
References: <31729.1607817912@localhost> <2800d166-48af-e081-8356-c6295ba30704@gmail.com>
Message-ID: <32fe250d-0db2-7abc-adae-8df5a6a8a57c@gmail.com>
Date: Sun, 27 Jun 2021 11:12:01 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0
MIME-Version: 1.0
In-Reply-To: <2800d166-48af-e081-8356-c6295ba30704@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/SZNhFbkGvSfkEscP4kDNAYjvqpM>
Subject: Re: [Anima] question about future-proofing of GRASP objectives
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 26 Jun 2021 23:12:11 -0000

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
>