[Anima] AD review of draft-ietf-anima-grasp-api-06
"Rob Wilton (rwilton)" <rwilton@cisco.com> Mon, 28 September 2020 15:19 UTC
Return-Path: <rwilton@cisco.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 DEEE73A1257; Mon, 28 Sep 2020 08:19:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.601
X-Spam-Level:
X-Spam-Status: No, score=-9.601 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=ICw0cyb1; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=FWFkhyBY
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 GEP8op4dNNWF; Mon, 28 Sep 2020 08:19:30 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDA383A0FC1; Mon, 28 Sep 2020 08:19:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28825; q=dns/txt; s=iport; t=1601306369; x=1602515969; h=from:to:cc:subject:date:message-id:mime-version; bh=IlmaU+KWBwugwNEdg0haObpquO6eGGnBboup2yOji0E=; b=ICw0cyb1e9OvIT+CsWmIJ22wQizfTFmIIni0c72hit3tN7jnZuz22IRA aKJFJ3aqXHB5yOPfzPGET4Lp4MW7KMDTp+P/vYrVKmLAlCp1T7sC5DRZz xF5RrTTpjn2YqglB/ms9wz1s0dlzhUxpfuqh+ngvD/SmfmhvdvUuV2YMN g=;
X-Files: draft-ietf-anima-grasp-api-06-ad-review.txt : 11701
IronPort-PHdr: 9a23:/lznGRT6mSlwcUhZCHV+kb7CRNpsv++ubAcI9poqja5Pea2//pPkeVbS/uhpkESQBN+J6v9YhazRqa+zEWAD4JPUtncEfdQMUhIekswZkkQmB9LNEkz0KvPmLklYVMRPXVNo5Te3ZE5SHsutZlDOrDu19zFBUhn6PBB+c+LyHIOahs+r1ue0rpvUZQgAhDe0bb5oahusqgCEvcgNiowkIaE0mRY=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AAEQC7/nFf/40NJK1gHQEBPAEFBQECAQkBFYFRgVApKAdwWS8sCod5A45+l3SBQoERA1UEBwEBAQ0BASMKAgQBAYRLAoIxAiU4EwIDAQELAQEFAQEBAgEGBG2FXAELhXUWCA0ZAQE3AREBUDAmAQQODQYUgjlMgksDLgEDC6lsAoE5iGF0gQEzgwEBAQWFAhiCCQcDBoE4AYJxijwbgUE/gRFDghiDTwKBIQgODhyDSIItkAUIiiwmgSaBWZlnCoJnhEiEM5F+gw2JfoU7jk2TCYh9gWyVIwIEAgQFAg4BAQWBayMqgS1wFTuCaVAXAg2PRAECgkmFFIVBAXQ3AgYKAQEDCXyLNIE0AYEQAQE
X-IronPort-AV: E=Sophos;i="5.77,313,1596499200"; d="txt'?scan'208";a="549593180"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 28 Sep 2020 15:19:07 +0000
Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 08SFJ6XX028869 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 28 Sep 2020 15:19:07 GMT
Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 28 Sep 2020 10:19:06 -0500
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 28 Sep 2020 10:19:06 -0500
Received: from NAM11-CO1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 28 Sep 2020 10:19:06 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AcwxtY5oWghR5GY70DD7gnFq0PEel+fjWDX4V3Y6MRSOtaAHlSuxhtIAfMJTg0cc2M7onM/UTBYtAdwmyzPGUExCXe1YUaZvI+1fWEWuRIj11v6kLtM04wU2D+/J9q5Tsy0B68ziPLPwlA6LVC40+lAwVc3fuB75GExISrFuSeolkKmmKQ/f/Cs8AAXJ0G6ktgin846XuPa9i6seLNF7AYBTKofjX9bBQ1/mGVCHXuXdmf+tFwxu5FFMkr5PcXw1t+OseLWiG6pJK6WDrCUvCj7E30zkO/IR4v8hnG+qkG8rlrQEh/K2WDuRUa6Ol5IE0/cC1dAmVTrkbIp6MNc8iw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1twCqGUsYcaD04FaOm4jelCSss1ILZdcPxSXuu9eemo=; b=C6wa4zQVGkBfXHemvw/3ECgqBvw2eO+ffJm1YJyf2m/ZfCRFNTKxWd3Kv9ekTqibeVNzNtv4+z4rzfAmHgBolA0oMl1nWKWP+iAEliGywo1W0AEZNcx36aOxE23doJIkseh9dyCD0reicGGrAN4EW2iIWJyXVrb0P81514yn2iloVCwohYyH+vSbTtMH33KhZtBYaWsw6zgUxD6GChtIhU4ujXkQjo+3K/UdfB/dRLY6Xt74GhYXIYd7J+aVW9YsaosNt7ElOvP8ZOOekcBoulLAMwqR6JqVYPF24FifVRYabkSMfI51z0tzF+4vykZ69ZzxwsMKKAPIg5nIDh84TA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1twCqGUsYcaD04FaOm4jelCSss1ILZdcPxSXuu9eemo=; b=FWFkhyBYf77YxLgYgqNyWzuUHC+SDU76ev0/Cp+pqJi1nX/5HN9kwulC7mmcxaEXTcOQModOcJp24895pjI3aIhAqcEm/VGZ0PsfaY9mEQkVnvODkseIgDpzH1JLqTQW+MhOXuJuSzNXa1CNspPyyQUjQt815r1lRfXrsrmo+2c=
Received: from MN2PR11MB4366.namprd11.prod.outlook.com (2603:10b6:208:190::17) by MN2PR11MB4661.namprd11.prod.outlook.com (2603:10b6:208:26b::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.21; Mon, 28 Sep 2020 15:19:05 +0000
Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::d84a:115:9ce0:8241]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::d84a:115:9ce0:8241%4]) with mapi id 15.20.3391.026; Mon, 28 Sep 2020 15:19:05 +0000
From: "Rob Wilton (rwilton)" <rwilton@cisco.com>
To: "draft-ietf-anima-grasp-api@ietf.org" <draft-ietf-anima-grasp-api@ietf.org>
CC: "anima@ietf.org" <anima@ietf.org>, Sheng Jiang <jiangsheng@huawei.com>
Thread-Topic: AD review of draft-ietf-anima-grasp-api-06
Thread-Index: AdaVqYdACp127x0gSqKPFepZQxnBww==
Date: Mon, 28 Sep 2020 15:19:05 +0000
Message-ID: <MN2PR11MB4366FCFF358BBABBF64CB27CB5350@MN2PR11MB4366.namprd11.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [82.12.233.180]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: aa8727b8-4ce7-4ddc-c3a9-08d863c1d67f
x-ms-traffictypediagnostic: MN2PR11MB4661:
x-microsoft-antispam-prvs: <MN2PR11MB46619567871F77D21C0B84A2B5350@MN2PR11MB4661.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: AwEdOeelmT9Jy4xkAbhGG08U5Gb/Rrqn9wL0SHsQU/bcArWRWSMXwRWd4lWaGPPW9WfdZAa70EjD3PR0liHdTG+ZG/SU63o+XQV6cYmKBAk+2cJPv70G5ZsLgfUdlhF2hjnL0hs1WVWnCtzEtUMZV1G3VXllLbfuJuFiYwireBirz1MNeUCkX0ZdVU+Narjzplzcybji3sf/bTxi14+o1yAEO+6wFazSmRwanRu07M10UIRTjgDfJyD4TrnDJ8Xz1jnR+0fCVJpsRyRf0BN//IQbArVILw//BPcOTg5nTrfyYclGgKjyZWqW8rfj5tGbGFQ8gBxlorrty9p72Bbilq61aiCcEVw2zUgtF657SruyKoOREwUBoMt1ARtOBG7klnTUuFWkv2Z3rPWEvx7kS0y8vYbI+Nlb9CKGCzfipqLfoeIP3a27HDTGexUYdD1G/bQYsIC2oH3if66Frmzp5Q==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4366.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(39860400002)(376002)(136003)(346002)(366004)(8676002)(66946007)(64756008)(66476007)(66446008)(8936002)(76116006)(52536014)(66556008)(66616009)(5660300002)(30864003)(33656002)(71200400001)(186003)(54906003)(26005)(55016002)(2906002)(4326008)(7696005)(6506007)(9686003)(6916009)(86362001)(966005)(478600001)(316002)(83380400001)(99936003); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: GdqDHfA6oON3bH5Ae/siEsQfmRxV+mkdM+nwuLcw0KODCNI299ms8iPPESTsTuM6JWufEMRf/PjT3BMuxK24pJ+T4W81DUmt5HUclSjdXAN9hR9x50oMj6R+CkB5TN2N+EH81KJAKR6zBn43ptUF63Cuq441QJlkftsnROi+zm3no+Z9sXE+YaWLgeYLT3ZWeUvarDQk86OFs6hAZZEGHTWp73LG2SQZCo4LQ2pyszSMFv1Vwd3a2KP4JJJpBRn51TFx7GUNeCpn/JIO03+TZZLsANBuGP/IsYKJor8iL40ziUmet9B0D/iwKLYPW8yIU1ncPq3NZfp8MRDA6vHypyFiyqDDxUl2AdY/xMG5Mqn/HIN+yrKqqRuopg3Z5IbO3LQECgMQnX6BxMj1Ah/z1jfnQ/mxPNWhZedXnOVpl5sBRqMHGIvkQg86VKsaLHmvCkFtC5I9Cyd3whVGoSIzHUMBshtf7wlpSJG/aoYLgmSdZQ4NEowrfzQ+dqXh19Idy9HtUPtuTKbP/SdmxJqnhN52/rTiLEzF56Hkv17TNXFxn6rHwrXtOOLSJVtmLB7u+tk0D/bGlq9WhxOvdOXMzfsty4xi/itDEoiYkfJvAhKbRGbvYlpod8RJ03ST3Fum4ViGMTkYPNX9odzMVKM6dQ==
x-ms-exchange-transport-forked: True
Content-Type: multipart/mixed; boundary="_002_MN2PR11MB4366FCFF358BBABBF64CB27CB5350MN2PR11MB4366namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR11MB4366.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: aa8727b8-4ce7-4ddc-c3a9-08d863c1d67f
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Sep 2020 15:19:05.0601 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: /Rzi3bJihxCzPEJxUTShkG6y606sDOJIz/9bhNzT3DxG8ChUzAGf4owpI3DX+ebxZOVlnzedqFbYpxgDzQguzg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4661
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com
X-Outbound-Node: alln-core-8.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/x1aRO5zBwg_ZJIqjViBCZXZ8UX0>
Subject: [Anima] AD review of draft-ietf-anima-grasp-api-06
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: Mon, 28 Sep 2020 15:19:33 -0000
Hi, Apologies for the delay for this review. Please see comments below. I've also attached them in case they get truncated (which has happened on other reviews). Thank you for this document. Overall, it is very well written, easy to read and easy to understand. Comments: 1. Introduction As the following figure shows, a GRASP implementation could contain two major sub-layers. The bottom is the GRASP base protocol module, which is only responsible for sending and receiving GRASP messages and maintaining shared data structures. The upper layer contains I found the text, relative to the diagram, to be somewhat confusing, although the subsequent paragraphs make its intent clearer. I think that the top sub-layer is meant to be "GRASP Extended Function Modules", and the "Grasp Modules" is the bottom sub-layer. However, the diagram seems to have a sub-layer split in "GRASP Modules", and doesn't necessarily equate to "GRASP base protocol module". 1. Introduction It is desirable that ASAs can be designed as portable user-space programs using a system-independent API. In many implementations, the GRASP module will therefore be split into two layers. The top layer is a library that provides the API and communicates directly with ASAs. The lower layer is a daemon, or a set of sub-services, providing GRASP core functions that are independent of specific ASAs, such as multicast handling and relaying, and common data structures such as the discovery cache. The GRASP API library would need to communicate with the GRASP core via an inter-process communication (IPC) mechanism. The details of this are system-dependent. I also find this text confusing relative to the diagram. More naturally, I would assume that the boxes represent different processes and hence you would have IPC between ASA and say the "GRASP API Library". If I was to draw this, then I would probably have put the GRASP API library co-located with the ASA boxes. 1. Introduction Note that a simple autonomic node might contain very few ASAs in addition to the autonomic infrastructure components described in [I-D.ietf-anima-bootstrapping-keyinfra] and [I-D.ietf-anima-autonomic-control-plane]. Such a node might directly integrate GRASP in its code and therefore not require this API to be installed. However, the programmer would then need a deeper understanding of the GRASP protocol than is needed to use the API. Perhaps change "integrate GRASP in its code" to something like "integrate the full GRASP implementation in its code"? 2.2.1. Alternative Asynchronous Mechanisms Thus, some ASAs need to support asynchronous operations, and therefore the GRASP core must do so. Depending on both the operating system and the programming language in use, there are three main techniques for such parallel operations: multi-threading, an event loop structure using polling, and an event loop structure using callback functions. Rather than "there are three main techniques for such parallel operations", perhaps just "three common techniques are considered for parallel operations". Reasoning, there are other approaches for effectively handling concurrent operations, e.g., actors, futures, cooperative threads backed by a OS thread pool ... Possibly, change "simple function calls" in the multi-threading paragraph to be "simple synchronous function calls" to emphasize the synchronous nature. 2.2.2. Multiple Negotiation Scenario In the callback model, for the scenario just described, the ASAs "A" and "B" will each provide two instances of negotiate_step_received(), one for each session. For this reason, each ASA must be able to distinguish the two sessions, and the peer's IP address is not sufficient for this. It is also not safe to rely on transport port numbers for this, since future variants of GRASP might use shared ports rather than a separate port per session. This is why the GRASP design includes a session identifier. Thus, when necessary, a 'session_nonce' parameter is used in the API to distinguish simultaneous GRASP sessions from each other, so that any number of sessions may proceed asynchronously in parallel. It wasn't obvious to me why both ASAs "A" and "B" both provide callbacks, I presume that this is because there are multiple asynchronous steps involved. If so, would it be helpful to clarify this point? Also in this paragraph suggest "Hence, " rather than "This is wht" 2.2.3. Overlapping Sessions and Operations In calls where it is used, the 'session_nonce' is an opaque read/ write parameter. On the first call, it is set to a null value, and the API returns a non-null 'session_nonce' value based on the GRASP session identifier. This value must be used in all subsequent calls for the same session, and will be provided as a parameter in the callback functions. By this mechanism, multiple overlapping sessions can be distinguished, both in the ASA and in the GRASP core. The value of the 'session_nonce" is opaque to the ASA. Query the use of a null value, and whether that is too restrictive. 2.3. API definition Possibly this API would benefit from a short section (or even pseudo code) explaining the flow or flows of how the APIs are expected to work together. This could also be in an appendix. Perhaps the GRASP specification makes this obvious, in which case references back to the GRASP spec would be sufficient. 2.3.1.3. Objective * name (UTF-8 string) - the objective's name Should there be a limit on the length of the name? This question equivalently applies to the other strings/variable sized types. * value - a specific data structure expressing the value of the objective. The format is language dependent, with the constraint that it can be validly represented in CBOR (default integer = 0). I didn't understand the "default integer = 0" part. If this is a byte string then I would thought that the default might be an empty length bytestring, or perhaps a CBOR Null. An essential requirement for all language mappings and all implementations is that, regardless of what other options exist for a language-specific represenation of the value, there is always an option to use a CBOR byte string as the value. The API will then wrap this byte string in CBOR Tag 24 for transmission via GRASP, and unwrap it after reception. It was unclear whether you just meant an opaque CBOR byte string here (CBOR major type 2), or a CBOR byte string that itself contains CBOR encoded data (i.e. CBOR Tag 24). Is there any limit on the length of the CBOR byte string that is allowed? 2.3.2. Registration Some APIs list "Asynchronous Mechanisms:" and others don't. It might be helpful to clarify that those APIs that don't list asynchronous mechanisms are implicitly synchronous in their behaviour. * deregister_asa() - Note - the ASA name is strictly speaking redundant in this call, but is present for clarity. Presumably it also makes it significantly harder for a rogue client to try and deregister all ASAs by looping through all asa_nonces. 2.3.4. Negotiation 2. The 'session_nonce' parameter is not null. In this case negotiation must continue. The returned 'proffered_objective' contains the first value proffered by the negotiation peer. Note that this instance of the objective must be used in the subsequent negotiation call because it also contains the current loop count. The 'session_nonce' must be presented in all subsequent negotiation steps. Presumably the loop count in the proffered_objective must be one greater than the loop count in the objective structure? Would it be helpful to mention this? I also wasn't sure whether it must be "this instance of the objective must be used", or just that the loop counter must be copied across. E.g., functional languages would encourage these structures to be immutable. - Asynchronous Mechanisms: o Event loop implementation: The 'session_nonce' parameter is used in read/write mode. It is unclear to me, exactly what you mean by this, particularly because this is a return parameter. Perhaps this could be further explained in the text, or refer back the previous text. 2.3.4. Negotiation * listen_negotiate() I was surprised that the listen_negotate didn't include any timeout, e.g. to allow it to be used in polling fashion. Same comment applies to listen_synchronize(). 2.3.4. Negotiation * negotiate_wait() It wasn't clear to me why you would want to do this, although that may be apparent in the GRASP draft. Perhaps a cross reference might be helpful? 2.3.4. Negotiation * end_negotiate() Possibly "successful" might be a better parameter name than "reply". I think that you reply both if the negotiation is successful and also if it failed. 2.3.5. Synchronization and Flooding * synchronize() - If the objective was already flooded, the flooded value is returned immediately in the 'result' parameter. In this case, the 'source' and 'timeout' are ignored. Should source be quoted here? It is unclear what it is referring to. - Otherwise, synchronization with a discovered ASA is performed. The 'peer' parameter is an 'ASA_locator' as returned by discover(). If 'peer' is null, GRASP discovery is performed first. How does the GRASP discovery work in this scenario? Does this require use of the discovery APIs? This may require further explanation. 3. Implementation Status [RFC Editor: please remove] A prototype open source Python implementation of GRASP, including an API similar to this document, has been used to verify the concepts for the threaded model. It may be found at https://github.com/becarpenter/graspy with associated documentation and demonstration ASAs. This section will be removed anyway, but I thought that the GIL (global interpreter lock) effectively prevented Python threads from running concurrently. Nits: I've noted that you have chosen not to use RFC2119 language. No issues with this, but this may come up in IESG review ... Use of the term "nonce". Note in UK English this word sometimes takes an alternative meaning, depending on who you ask and which dictionary you look at: https://dictionary.cambridge.org/dictionary/english/nonce You may wish to consider an alternative term, but please note that this is up to the authors. I'm not objecting to this term, just making you aware, if you weren't already. Abstract: Maybe languages => programming languages. 1. Introduction As the following figure shows, Given that the figure is a few paragraphs away (and on the next page in the txt version), perhaps give the figure a name and reference it by name. 2.3.1.3. Objective. For me, I would outdent the "} objective" in the C struct example. represenation -> representation Thanks, Rob
- [Anima] AD review of draft-ietf-anima-grasp-api-06 Rob Wilton (rwilton)
- Re: [Anima] AD review of draft-ietf-anima-grasp-a… Brian E Carpenter
- Re: [Anima] AD review of draft-ietf-anima-grasp-a… Brian E Carpenter
- Re: [Anima] AD review of draft-ietf-anima-grasp-a… Brian E Carpenter
- Re: [Anima] AD review of draft-ietf-anima-grasp-a… Rob Wilton (rwilton)
- Re: [Anima] AD review of draft-ietf-anima-grasp-a… Brian E Carpenter