Re: [Anima] Erik Kline's No Objection on draft-ietf-anima-grasp-api-08: (with COMMENT)

Brian E Carpenter <> Thu, 03 December 2020 01:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A08423A03F4; Wed, 2 Dec 2020 17:02:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 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.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ikgpJQRg_ll0; Wed, 2 Dec 2020 17:02:32 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::102a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D85263A03F1; Wed, 2 Dec 2020 17:02:32 -0800 (PST)
Received: by with SMTP id v1so161026pjr.2; Wed, 02 Dec 2020 17:02:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=f6n2Fruxpp4k1NGPoY1H7kNwyNwPVMZ18mW2mmwOmv8=; b=cejUw206B89byj5hzL30/oDF6p/lP/vkr4gfcvrR0au4skeTBDfCe0ZPcM8pZUlH9r S3uEHFjX/daY4T32v3R8Y/1hKQbLPR6U70t+7X6vGvRijnpSffGXUYYd2oxsWpSsx6UZ O7g9IRGAQVordNHyK/prtHHihyK8W4DdyENKdpdopKyH0C5miJqWse/cZ7uiQ9n040nu HjcsefHmCM1h03WYFNVrTVEP81fe0wvhOYhn3UIWQW3thwcVwZI5QMG+bRksh6Rhv7xs z66h7KUACqoyTxMM5BxgWFtwxzGc6ZeQHfGCO3b2PqdfUWKd7U7rdVIE1VZZ7GbV6FAC 8Kcg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=f6n2Fruxpp4k1NGPoY1H7kNwyNwPVMZ18mW2mmwOmv8=; b=NKgHE8yrF3erz/AcsFV9MPNCjUzC7g/YWmxSZJb5JaGCue7POELA5M0kT6eyjenpRH o71jhUdk0cQyUvzAcgMx/lKAiv6nFwL2gTCCIGX/3sQ0KO/SVnYD+ZazdTFUh749v2Fu DLkGTMGfdABRXYtWgAG2yuYSRdxaFkH5aGaXEcBwCh3927B+S6pHTQBl4PIM1EvZYDht U7RPM5lOZccLbi4iFuXI2JOztf+C7eXNIKHeFuUXJpFnc3auuJZnw7akvMzH279A6B44 B4y1PLASCYvbsg4mH7SRPp8QF2Ao1080EnBYChqxMgMRra+wKc8WZ8idYszKQE4d2jky 3W/g==
X-Gm-Message-State: AOAM533VsK9QZjpTCp38+QI63VxZkJcXeTbUhZRvkP3bBT5kFiVCq9rI PBIe16O5CIfxrzvo01srRRU=
X-Google-Smtp-Source: ABdhPJxk6/TH1KSLSdmey57xoM1Ub+IrbVuBP/gN47rz33TvIJuD723crWmEbbWjm9VKbAGMQnKXYA==
X-Received: by 2002:a17:90a:e005:: with SMTP id u5mr628234pjy.64.1606957352072; Wed, 02 Dec 2020 17:02:32 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id d4sm247318pfo.127.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Dec 2020 17:02:31 -0800 (PST)
To: Erik Kline <>, The IESG <>
Cc:,,, Sheng Jiang <>
References: <>
From: Brian E Carpenter <>
Message-ID: <>
Date: Thu, 3 Dec 2020 14:02:26 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [Anima] Erik Kline's No Objection on draft-ietf-anima-grasp-api-08: (with COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 03 Dec 2020 01:02:35 -0000

Hi Erik,

Thanks for the review. A few replies below...

On 02-Dec-20 19:01, Erik Kline via Datatracker wrote:
> Erik Kline has entered the following ballot position for
> draft-ietf-anima-grasp-api-08: No Objection
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> Please refer to
> for more information about IESG DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> [[ questions ]]
> [ section ]
> * It looks like the URI may contain an IP address or FQDN as well as a
>   port number?  If so, is there a validation requirement about the presence
>   or value of the port field in the ASA_locator in relation to the port
>   number in the URI?

Short answer: no. As noted in the text, ASAs "are presumed to provide correct
locators". Longer answer: the usage of both FQDNs and URIs as locators is
specified in GRASP for completeness, but we've never worked out the details.
In particular, you will notice that there is no transport type for HTTP
defined. The underlying text in the GRASP spec is at:

> [ section 2.3.3. ]
> * For deregister_asa(), if the ASA name is redundant, does that mean that
>   a call like deregister_asa(asa_nonce=valid_nonce, name="") should succeed?

Good question. [Pause to look at code.] I see that I coded it to fail
if the name doesn't match, which protects against mistakes, but also...
>   I suppose one ASA can deregister other ASAs by cycling through the 32-bit
>   numberspace?

...protects against this attack. We should probably tweak the wording.
> * For register_objective(), but happens if overlap=False for an objective
>   already registered with overlap=True?  And what about the inverse?

Good question. I think the correct answer should be that all registrations
should be the same for a given objective; nothing else makes sense to me.

>   I guess, what is the trust model of multiple ASAs sharing a GRASP core
>   (i.e. on the same node)?

Part of the general trust model: if a node can join the ACP it is trusted,
so all ASAs in that node are trusted. As noted elsewhere, ASA authorization
is left for future work.

> [ section 2.3.4 ]
> * For objectives that other ASAs on the same node might be trying to
>   discover(), is the cache kept separate per-ASA or shared?
>   If shared, it seems like the TTL<minTTL entries should be ignored and not
>   deleted, maybe? (I haven't read any text describing cache implementation
>   requirements or guidance yet.)

That's arguable. If one ASA decides it needs a fresh discovery, all other
ASAs will benefit. Flushing the cache won't affect sessions already under

> * For asynchronous mechanisms, is the callback (if used) called multiple
>   times, as locators are discovered or are they accumulated until the timeout
>   is reached and returned in one callback invocation?
>   If the former, is there one final callback with, if necessary, an empty list
>   to indicate the timeout was reached (as a convenience)?

Hmm. I think that depends very much on the exact callback system in use,
and there seems to be quite a choice. 

> [[ nits ]]

Noted, thanks.

> [ abstract ]
> * "adapted to the support for" -> "adapted to add support for", perhaps
> [ section ]
> * Perhaps replace "ifi...probably no use to a normal ASA" with something like
>   "probably only of use to an ASA on a node with multiple active interfaces"?
> [ section 2.3.6 ]
> * s/caches all flooded objectives that it receive/... that it receives/