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

Erik Kline via Datatracker <noreply@ietf.org> Wed, 02 December 2020 06:01 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: anima@ietf.org
Delivered-To: anima@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D8143A1052; Tue, 1 Dec 2020 22:01:34 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Erik Kline via Datatracker <noreply@ietf.org>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-anima-grasp-api@ietf.org, anima-chairs@ietf.org, anima@ietf.org, Sheng Jiang <jiangsheng@huawei.com>, jiangsheng@huawei.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.23.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Erik Kline <ek.ietf@gmail.com>
Message-ID: <160688889435.15290.1811049640979063443@ietfa.amsl.com>
Date: Tue, 01 Dec 2020 22:01:34 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/t4xFR4DfQGg6oyvdIUVUZ6lRbrg>
Subject: [Anima] Erik Kline's No Objection on draft-ietf-anima-grasp-api-08: (with COMMENT)
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 02 Dec 2020 06:01:35 -0000

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 https://www.ietf.org/iesg/statement/discuss-criteria.html
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?

[ 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?

  I suppose one ASA can deregister other ASAs by cycling through the 32-bit

* For register_objective(), but happens if overlap=False for an objective
  already registered with overlap=True?  And what about the inverse?

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

[ 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.)

* 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)?

[[ nits ]]

[ 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/