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

Brian E Carpenter <brian.e.carpenter@gmail.com> Tue, 01 December 2020 19:21 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 953093A1471; Tue, 1 Dec 2020 11:21:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
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: 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 KWg2ST1WK8UM; Tue, 1 Dec 2020 11:21:58 -0800 (PST)
Received: from mail-pf1-x431.google.com (mail-pf1-x431.google.com [IPv6:2607:f8b0:4864:20::431]) (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 85FA13A146E; Tue, 1 Dec 2020 11:21:57 -0800 (PST)
Received: by mail-pf1-x431.google.com with SMTP id e13so1720268pfj.3; Tue, 01 Dec 2020 11:21:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=E0aRnw5anUGXQ8XYVQH+cbA9uEUKUryGL3tKumvq+bs=; b=WGCvnyHsMrbzrJ9ihxEZOVWmOjDEkPVMPJSZNckNlrYPCYmFVTzDAuNvr0/W3W8PjP 69dnDBKS+kNPRW9yYnrf4OjvPeCzfdk2HFHoSvNB6DcnfG1nhBsH+Br7TzJvHS2ChDS/ g7tW6nuOPSOOMdsXGgrWwvwWVwBQpsHi1yM7CB1oIVJaxzhCdr7W+FN9wFhwTw2sPs0s bhpJ0cb1c1yHp8hHpzUVlHQmDyvgCWeMAMQ7r+wXJRX6oO+JFzEt5BfpPwXQZXZL+/xk ciR8/xaYcGOuCvtZn/yhoYvaSJDEp/fJlPE9CaFvYGuE0YW7EMSj04YF8XgZjZ9WJDW9 VsmQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; 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=E0aRnw5anUGXQ8XYVQH+cbA9uEUKUryGL3tKumvq+bs=; b=I0XtyRqlniZvgHjKGHWfYRO71LSHv9TK7Z9GXvJKAexKh+oVPNkhBRxl7emeM9yeA7 oiTieUZ1xyksW7bTivkK5taNk356EVDwGWgzXw3cJvGvZ8CG5moYzJhNARpgDW4mZ3zm U+CaxMNlLgEMv3qg0d3hbh0V84ORXkEz2dng+266Svui5sYmRB1FeyoliuCLI9wy1wsZ D89zrSAOZJMpg55Nuzg/AVZ9Cw3MScNLucjGrfwG5ZGBAszSDSINulvc1gw2KoA2vNra KVnPCo1KtAeVppqQH7dAQ28PYGMwUEnjZa+Llw4SQsFRWdTztD2dqcMwztCaiXoWf53S wi/g==
X-Gm-Message-State: AOAM5334mIsOiLrkqVkwiOL8nG6Bb3Su9b98NLl4thgPtyirkWIYdwmi w8/5cfTqDX5xaR1uBDFaL+o=
X-Google-Smtp-Source: ABdhPJzodpU0qTVbhrGQuCnVJOjm11FJBCdUrNFPbS0kMUrKkMuCOTXUA2dzvyw5o7krKba34Jt8Eg==
X-Received: by 2002:a62:6405:0:b029:197:cc73:397b with SMTP id y5-20020a6264050000b0290197cc73397bmr4018396pfb.51.1606850516885; Tue, 01 Dec 2020 11:21:56 -0800 (PST)
Received: from [192.168.178.20] ([151.210.131.28]) by smtp.gmail.com with ESMTPSA id b5sm451717pjg.28.2020.12.01.11.21.53 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Dec 2020 11:21:56 -0800 (PST)
To: Murray Kucherawy <superuser@gmail.com>, 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>
References: <160680219182.19139.7789255823731035283@ietfa.amsl.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <241e1fe2-135b-8a71-cd21-a643d6270433@gmail.com>
Date: Wed, 2 Dec 2020 08:21:53 +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: <160680219182.19139.7789255823731035283@ietfa.amsl.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/22oUWZFDnGgZDVILOY4zfLy7gkY>
Subject: Re: [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
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: Tue, 01 Dec 2020 19:22:00 -0000

Murray,

Yes, in practice there's no such thing as a missing return value. Will clarify.

Thanks
   Brian

On 01-Dec-20 18:56, Murray Kucherawy via Datatracker wrote:
> 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:
> https://datatracker.ietf.org/doc/draft-ietf-anima-grasp-api/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> 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.
> 
> 
> 
>