Subject: Re: [Anima] GRASP messages-//RE: I-D Action: draft-ietf-anima-grasp-02.txt

From: Brian E Carpenter <[email-masked]>
Date: Thu, 4 Feb 2016 13:33:51 +1300

OK, the authors will assume consensus for this change, and we'll close issue 47 in the next draft.

Regards
   Brian

On 29/01/2016 22:24, Liubing (Leo) wrote:
> 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,
>>
>> Since nobody else has responded, here are my comments:
>>
>> On 14/01/2016 15:24, Liubing (Leo) wrote:
>>> 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 (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.
>>>
>>> [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
>>
>> 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.
> 
>>> - 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?
>>
>> 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.
> [Bing] I think it's good. Thanks.
> 
> Best regards,
> Bing
> 
>>     Brian