Re: [Anima] Adoption call for draft-liu-anima-grasp-api-06, ends Dec. 12, 2017

Carsten Bormann <cabo@tzi.org> Sat, 09 December 2017 16:58 UTC

Return-Path: <cabo@tzi.org>
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 71F49126CE8; Sat, 9 Dec 2017 08:58:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 T2J5wJTwdhnt; Sat, 9 Dec 2017 08:58:04 -0800 (PST)
Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 270D71200B9; Sat, 9 Dec 2017 08:58:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id vB9Gvngn015339; Sat, 9 Dec 2017 17:57:51 +0100 (CET)
Received: from [192.168.217.119] (p5DC7E827.dip0.t-ipconnect.de [93.199.232.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3yvFlK0zzPzDWMq; Sat, 9 Dec 2017 17:57:49 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B92817B499B@NKGEML515-MBX.china.huawei.com>
Date: Sat, 09 Dec 2017 17:57:48 +0100
Cc: "anima@ietf.org" <anima@ietf.org>, "anima-chairs@ietf.org" <anima-chairs@ietf.org>
X-Mao-Original-Outgoing-Id: 534531468.154607-e3f054116e6b1fcd2901861a3ac4be85
Content-Transfer-Encoding: quoted-printable
Message-Id: <A8FC6247-021A-463B-A7FC-25712D2725EA@tzi.org>
References: <5D36713D8A4E7348A7E10DF7437A4B92817B499B@NKGEML515-MBX.china.huawei.com>
To: Sheng Jiang <jiangsheng@huawei.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/J7128VKIz2TNOSxzi9qZjY_Et50>
Subject: Re: [Anima] Adoption call for draft-liu-anima-grasp-api-06, ends Dec. 12, 2017
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.22
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, 09 Dec 2017 16:58:06 -0000

On Nov 29, 2017, at 12:35, Sheng Jiang <jiangsheng@huawei.com> wrote:
> 
> During the IETF100, there was a consensus that draft-liu-anima-grasp-api is fully consistent with the current ANIMA charter, under the condition it intends to be an Informational document. After the meeting, the authors have updated the document. The current intended status is Informational. There was an adoption call on this document as a ANIMA working group document in the ANIMA session, IETF100. There were supports and no objection as far as chairs heard. As an official procedure, we now confirm the adoption in the ANIMA mailing list. 

I wasn’t in the room when this was discussed.

I believe it is a good thing that the IETF is not in the habit of automatically creating an API for each protocol that it defines (“IETF doesn’t do APIs”).  However, there are specific situations when creating APIs is useful:

— adoption of a new technology may benefit from a common API being available.  E.g., RFC 2292/3542 has helped IPv6 adoption a lot by making applications possible that would have had to use IPv4 otherwise.  Similar, RFC 6458 for SCTP.
— the API may clarify the “northbound interface” of the protocol implementation.  Sometimes it is not clear from a protocol what the actual meaning of running the protocol is supposed to be.  While we probably don’t want to automatically define a “service interface” like in the OSI model for each protocol, a more innovative protocol may be hard to understand without the image of such an API in the mind of the reader.

I believe both of these effects can be had here, so it is good that the authors have written up the API.

I also agree that there should be an intent of finishing this quickly to aid adoption, and of revisiting the API again after a few years of getting experience — after all, this is not intended as a “Standard".  This probably does not justify going for “Experimental”: First, this isn’t really a protocol, and second, there is no formal experiment being run here that will be done at some point: This API is supposed to last unless we learn that it can be improved.

So I completely agree with (what I understand was) the in-room consensus at IETF 100 and the sentiments that were expressed here.

Grüße, Carsten