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

Murray Kucherawy via Datatracker <noreply@ietf.org> Tue, 01 December 2020 05:56 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 484BB3A05AA; Mon, 30 Nov 2020 21:56:32 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Murray Kucherawy 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>
X-Test-IDTracker: no
X-IETF-IDTracker: 7.23.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Murray Kucherawy <superuser@gmail.com>
Message-ID: <160680219182.19139.7789255823731035283@ietfa.amsl.com>
Date: Mon, 30 Nov 2020 21:56:32 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/5liG0zkkUv5RokPSsLvh4fhtIfU>
Subject: [Anima] Murray Kucherawy'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: Tue, 01 Dec 2020 05:56:32 -0000

Murray Kucherawy 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:


This might be an implementation detail, but I feel like bringing attention to
it to clarify:

Looking at this as a guide to API implementers, I'm confused by one aspect to
this document.  There are portions of the API specification where some of the
returned items are conditional.  For example, in Section 2.3.3, the response to
"register_asa()" always contains an "errorcode" but it will also contain an
"asa_nonce" if registration was successful.  What does it mean for a response
to be sometimes missing a piece of information?  I'm thinking, for instance,
about python where your response might be a single value or a tuple of values
depending on success or failure, and I as the consumer will have to handle each
case separately.   Wouldn't it be simpler for "asa_nonce" to have a possible
sentinel value for use in failures?  (Maybe 0, maybe -1, maybe MAXINT; the use
of "integer" in the document generally doesn't specify whether it's signed or
unsigned or what limits might exist.  Or maybe "None".) That way, responses
always have the same number of elements and possibly types irrespective of the
function's outcome.

For a more extreme example, the response to "request_negotiate()" could have
anywhere between one and four elements in it too, and of varying types.

It's possible this doesn't matter though; you're doing the API implementation,
you get to decide and document it and then deal with user response.  But as
someone who produces and documents APIs a lot, this stuck out to me.