Subject: Re: [Anima] I-D Action: draft-carpenter-anima-gdn-protocol-03.txt

From: Brian E Carpenter <[email-masked]>
Date: Tue, 21 Apr 2015 09:03:04 +1200

Hi,

This is updated in several ways:

 Removed intrinsic security, required external security
 Format changes to allow ADNCP co-existence
 Recognized DNS-SD as alternative discovery method
 Editorial improvements

Please read and comment. This is not by any means a final proposal
and we really need feedback from the group.

Regards
   Brian Carpenter

On 21/04/2015 08:57, [email-masked] wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
>         Title           : A Generic Discovery and Negotiation Protocol for Autonomic Networking
>         Authors         : Brian Carpenter
>                           Bing Liu
> 	Filename        : draft-carpenter-anima-gdn-protocol-03.txt
> 	Pages           : 40
> 	Date            : 2015-04-20
> 
> Abstract:
>    This document establishes requirements for a protocol that enables
>    intelligent devices to dynamically discover peer devices, 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-carpenter-anima-gdn-protocol/
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-carpenter-anima-gdn-protocol-03
> 
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-carpenter-anima-gdn-protocol-03
> 
> 
> 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/
> 
> _______________________________________________
> 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: Sheng Jiang <[email-masked]>
Date: Tue, 21 Apr 2015 03:49:43 +0000

Hi, Brian,

A few feedback in lines. I only read the diff.

>-----Original Message-----
>From: Anima [mailto:[email-masked]] On Behalf Of Brian E
>Carpenter
>Sent: Tuesday, April 21, 2015 5:03 AM
>To: Anima WG
>Subject: Re: [Anima] I-D Action: draft-carpenter-anima-gdn-protocol-03.txt
>
>Hi,
>

In principle, this is fine. But the current text of external security are unclear, particularly, on how to bound with TLS or DTLS.

Also, in section 3.3.1, "If this is impossible (to run within ACP), ...". There are two issues in this sentence: a) how to define or detect impossible; b) should it be allowed the AN node choose not to use ACP even when ACP is available. For the second point, I can understand for autonomic purpose, we may not want too much alternative (otherwise, the AN node may depend on configuration to choose). If so, it would be help to clarify the design purpose, here; and it requests a clear behavior specification to detect the availability of ACP.

The new section 3.3.2 is slur. This will certainly introduce confusion for implementors. The way that short messages use USP and longer messages use TCP is not feasible. TCP are sessions for a set of message exchanging. If a session starts from a short message, then one of follow-up message is a long message, I don't think the communication pair can change from UDP to TCP. Vice verse.

By removing Device Identifier and tag, the current document seems open a design hole on how to identify the communication peers. I am not sure IP addresses, which are normally locators, are sufficient and efficient to be the identifier. Although there is a newly added Device Identity Option in new 3.7.6, it is unclear how to use it (besides the definition session, nowhere have mentioned it).

> Recognized DNS-SD as alternative discovery method

I guess the document should emphasis that negotiation are independent from discovery, although the rapid discovery model includes the first step of a negotiation.

Best regards,

Sheng

>Anima mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/anima

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 21 Apr 2015 16:49:27 +1200

Hi Sheng, thanks for the comments.
> In principle, this is fine. But the current text of external security are unclear, particularly, on how to bound with TLS or DTLS.

I agree. This clearly needs to be made more precise as we go forward.

> Also, in section 3.3.1, "If this is impossible (to run within ACP), ...". There are two issues in this sentence: a) how to define or detect impossible; 

Yes, I would like to hear from the ACP authors about that.

> b) should it be allowed the AN node choose not to use ACP even when ACP is available. 

My opinion was no, and a strict interpretation of the RFC 2119 "SHOULD" is needed.
We can make it more clear, of course.

> For the second point, I can understand for autonomic purpose, we may not want too much alternative (otherwise, the AN node may
depend on configuration to choose). If so, it would be help to clarify the design purpose, here; and it requests a clear
behavior specification to detect the availability of ACP.
> The new section 3.3.2 is slur. This will certainly introduce confusion for implementors. The way that short messages use USP and longer messages use TCP is not feasible. TCP are sessions for a set…

We should study how DNS handles this issue. The problem should be the same.

> 
> By removing Device Identifier and tag, the current document seems open a design hole on how to identify the communication peers. I am not sure IP addresses, which are normally locators, are sufficient and efficient to be the identifier. 

I was assuming that ACP or (D)TLS would guarantee identity. Maybe that is naive?

> Although there is a newly added Device Identity Option in new 3.7.6, it is unclear how to use it (besides the definition session, nowhere have mentioned it).

Yes. It is a placeholder for now. If we need it, we have to expand it, but that
is not clear yet and we would like some help from security experts.

> I guess the document should emphasis that negotiation are independent from discovery, although the rapid discovery model includes the first step of a negotiation.

Yes, that could be stated clearly in the High-Level Design Choices.

Regards
    Brian