Subject: [Anima] I-D Action: draft-ietf-anima-grasp-api-09.txt

From: [email-masked]
Date: Sat, 19 Dec 2020 12:06:39 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Autonomic Networking Integrated Model and Approach WG of the IETF.

        Title           : Generic Autonomic Signaling Protocol Application Program Interface (GRASP API)
        Authors         : Brian Carpenter
                          Bing Liu
                          Wendong Wang
                          Xiangyang Gong
	Filename        : draft-ietf-anima-grasp-api-09.txt
	Pages           : 40
	Date            : 2020-12-19

Abstract:
   This document is a conceptual outline of an application programming
   interface (API) for the Generic Autonomic Signaling Protocol (GRASP).
   Such an API is needed for Autonomic Service Agents (ASA) calling the
   GRASP protocol module to exchange autonomic network messages with
   other ASAs.  Since GRASP is designed to support asynchronous
   operations, the API will need to be adapted according to the support
   for asynchronicity in various programming languages and operating
   systems.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-anima-grasp-api/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-anima-grasp-api-09.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-grasp-api-09

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 20 Dec 2020 09:36:32 +1300

Hi,

This draft was approved recently by the IESG, but with many thoughtful comments on the -08 version. The -09 version deals with most of them, but since there are a lot of clarifications and two open issues, IMHO the WG needs to take another look. The summary of changes is:

*  Added short discussions of CBOR usage and verification.		 		
*  Added section on session termination.	 		
*  Clarified that integers are uint32 or uint8.	
*  Minor technical correction to timeout specification.	
*  Clarified sequencing of negotiation messages.	
*  Minor technical addition to request_negotiate() and synchronize() in event loop model.		
*  Expanded several points in Security Considerations, including precautions against resource exhaustion.	
*  Other clarifications and minor reorganizations; removed some duplicated text.	 		
*  Updated references.

The two open issues:

1) A couple of people dislike the use of "nonce" in "asa_nonce" and "session_nonce", because these are not nonces in the security sense, just unique handles. Should we rename them as "asa_handle" and "session_handle"?

2) The second one is more subtle. In the discover() there is an option to delete stale entries from the discovery cache, via the minimum_TTL parameter. Two reviewers noted that this will affect all ASAs interested in the same objective, not just the ASA using minimum_TTL. Is that OK? If not, we'd reword it such that discover() ignores stale entries rather than deleting them. Should we make this change?

We'll wait until after the holidays for answers to these questions and any other comments.

Regards
   Brian Carpenter

On 20-Dec-20 09:06, [email-masked] wrote:
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima
>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 31 Dec 2020 16:55:36 +1300

Well, nobody has commented on the open issues below. I have inserted proposed resolutions below. If nobody objects in the next few days, we'll make those minor changes, and make one more minor fix to the references.

Regards
   Brian Carpenter

> 1) A couple of people dislike the use of "nonce" in "asa_nonce" and "session_nonce", because these are not nonces in the security sense, just unique handles. Should we rename them as "asa_handle" a…

Proposed resolution: make this change. The word "nonce" might give a false impression of security.
 
> 2) The second one is more subtle. In the discover() there is an option to delete stale entries from the discovery cache, via the minimum_TTL parameter. Two reviewers noted that this will affect all…

Proposed resolution: no change. If one ASA believes that a discovered locator is stale, it seems reasonable to make it stale for all other ASAs too.

Best wishes for the New Year to everyone.

   Brian