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

From: [email-masked]
Date: Tue, 12 Jan 2016 16:36:10 -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 Working Group of the IETF.

        Title           : A Generic Autonomic Signaling Protocol (GRASP)
        Authors         : Carsten Bormann
                          Brian Carpenter
                          Bing Liu
	Filename        : draft-ietf-anima-grasp-02.txt
	Pages           : 56
	Date            : 2016-01-12

Abstract:
   This document establishes requirements for a signaling protocol that
   enables autonomic devices and autonomic service agents to dynamically
   discover peers, to synchronize state with them, and to negotiate
   parameter settings mutually with them.  The document then defines a
   general protocol for discovery, synchronization and negotiation,
   while the technical objectives for specific scenarios are to be
   described in separate documents.  An Appendix briefly discusses
   existing protocols with comparable features.

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

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-anima-grasp-02

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

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: Wed, 13 Jan 2016 13:52:47 +1300

Hi,

This update to the GRASP design hopefully addresses the issues raised
in Yokohama. It also reflects experience with a demonstration prototype
implementation of GRASP in Python, which has taken most of the time
since the IETF.

As a result there are a number of changes to the protocol. The biggest
one was splitting the RESPONSE message into three separate messages
(RESPONSE for discovery responses, SYNCHRONIZE for synchronization
responses, and FLOOD for unsolicited flood messages).

We need careful reviews of this version and decisions about the
open issues. After people have had a few days to digest the document,
we will start discussion threads on the open issues.

Change log:
https://tools.ietf.org/html/draft-ietf-anima-grasp-02#section-9

Open and closed issues:
https://tools.ietf.org/html/draft-ietf-anima-grasp-02#section-4

Anyone who has Python 3.4 and IPv6 on their machine, and is feeling
brave, please contact me off list about the demonstration code.

Regards
   Brian

On 13/01/2016 13:36, [email-masked] wrote:
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

---

From: "Liubing (Leo)" <[email-masked]>
Date: Thu, 14 Jan 2016 02:24:53 +0000

Hi Dear all,

> As a result there are a number of changes to the protocol. The biggest one
> was splitting the RESPONSE message into three separate messages
> We need careful reviews of this version and decisions about the open issues.
> After people have had a few days to digest the document, we will start
> discussion threads on the open issues.

[Bing] Please allow me to discuss the following open question firstly:

47.  REQUEST is a dual purpose message (request negotiation or
      request synchronization).  Would it be better to split this into
      two different messages (and adjust various message names
      accordingly)?

For my personal feeling, the issue is not only the overloading for both Negotiation and Synchronization, but also the violation the custom that "Request" is usually coupled with "Response" in other protocols. In GRASP, "Response" is coupled with "Discovery".

So, if we split the REQUEST message, I think might fit more to the split RESPONSE messages (RESPONSE for discovery responses, SYNCHRONIZE for synchronization responses, and FLOOD for unsolicited flood messages), plus, with a bit renaming, the messages could be like this:
- Discovery & Discovery_Res
- Negotiation_Init & Negotiation & Negotiation_End
- Synchronization & Synchronization_Res
- Confirm-waiting
- Flood
Btw, the message name "Flooding message" is a very common/abstract phrase, can we find another more precise name? E.g., "Flooded Synchronization" or "Unsolicited Synchronization". 

These seem more institutive for me. What are your thought?

Best regards,
Bing

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 28 Jan 2016 13:26:33 +1300

Hi everybody,

Since nobody else has responded, here are my comments:

> - Negotiation_Init & Negotiation & Negotiation_End

Confirm-waiting fits here, doesn't it? I don't think we have
that for synchronization, only for negotiation.

> These seem more institutive for me. What are your thought?

In general, I agree. I think we can use full names in the text,
like Discovery and Discovery_Response, and shorter ones in the formal
(CDDL) description, like M_DISCOVER and M_DISC_RESP.

Apart from that the only real change is splitting Request into two
cases, and I think 'request' is fine, so I would suggest that the long
names are Request_Negotiation and Request_Synchronization. The changes
to the CDDL and the prototype code would be quite small.

If there's no disagreement on the list, we'll plan this for the -03 draft.

    Brian

---

From: "Liubing (Leo)" <[email-masked]>
Date: Fri, 29 Jan 2016 09:24:11 +0000

Hi Brian,

Thanks for replying.

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Thursday, January 28, 2016 8:27 AM
> To: Liubing (Leo); Anima WG
> Subject: Re: [Anima] GRASP messages-//RE: I-D Action:
> draft-ietf-anima-grasp-02.txt
> 
> Hi everybody,
> 
> >> As a result there are a number of changes to the protocol. The
> >> biggest one was splitting the RESPONSE message into three separate
> >> messages (RESPONSE for discovery responses, SYNCHRONIZE for
> >> synchronization responses, and FLOOD for unsolicited flood messages).
> >>
> >> After people have had a few days to digest the document, we will
> >> start discussion threads on the open issues.
> >
> > For my personal feeling, the issue is not only the overloading for both
> Negotiation and Synchronization, but also the violation the custom that
> "Request" is usually coupled with "Response" in other protocols. In GRASP,
> "Response" is coupled with "Discovery".
> >
> > So, if we split the REQUEST message, I think might fit more to the split
> RESPONSE messages (RESPONSE for discovery responses, SYNCHRONIZE for
> synchronization responses, and FLOOD for unsolicited flood messages), plus,
> with a bit renaming, the messages could be like this:
> Confirm-waiting fits here, doesn't it? I don't think we have that for
> synchronization, only for negotiation.
[Bing] Yes, I missed it. Thanks for correcting it.

> > Btw, the message name "Flooding message" is a very common/abstract
> phrase, can we find another more precise name? E.g., "Flooded
> Synchronization" or "Unsolicited Synchronization".
> >
> In general, I agree. I think we can use full names in the text, like Discovery
> and Discovery_Response, and shorter ones in the formal
> Apart from that the only real change is splitting Request into two cases, and I
> think 'request' is fine, so I would suggest that the long names are
> Request_Negotiation and Request_Synchronization. The changes to the
> CDDL and the prototype code would be quite small.
> 
[Bing] I think it's good. Thanks.

Best regards,
Bing