[core] core-groupcomm-05

peter van der Stok <stokcons@xs4all.nl> Tue, 12 February 2013 10:12 UTC

Return-Path: <stokcons@xs4all.nl>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 224C221F8727 for <core@ietfa.amsl.com>; Tue, 12 Feb 2013 02:12:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.154
X-Spam-Level:
X-Spam-Status: No, score=-0.154 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LHv3gKaG1KkE for <core@ietfa.amsl.com>; Tue, 12 Feb 2013 02:12:45 -0800 (PST)
Received: from smtp-vbr19.xs4all.nl (smtp-vbr19.xs4all.nl [194.109.24.39]) by ietfa.amsl.com (Postfix) with ESMTP id EE08021F8635 for <core@ietf.org>; Tue, 12 Feb 2013 02:12:44 -0800 (PST)
Received: from roundcube.xs4all.nl (roundcube10.xs4all.net [194.109.20.208]) by smtp-vbr19.xs4all.nl (8.13.8/8.13.8) with ESMTP id r1CACd3x089242; Tue, 12 Feb 2013 11:12:40 +0100 (CET) (envelope-from stokcons@xs4all.nl)
Received: from AMontpellier-654-1-221-34.w109-210.abo.wanadoo.fr ([109.210.220.34]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 12 Feb 2013 11:12:39 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Date: Tue, 12 Feb 2013 11:12:39 +0100
From: peter van der Stok <stokcons@xs4all.nl>
To: akbar rahman <akbar.rahman@interdigital.com>, esko dijk <esko.dijk@philips.com>, Core <core@ietf.org>
Organization: vanderstok consultancy
Mail-Reply-To: <consultancy@vanderstok.org>
Message-ID: <4c523fcc97cb76088432f6ef8b8a979a@xs4all.nl>
X-Sender: stokcons@xs4all.nl (KMQgAAhuM4gD4sdIDjyMglOclhAVUj66)
User-Agent: XS4ALL Webmail
X-Virus-Scanned: by XS4ALL Virus Scanner
Subject: [core] core-groupcomm-05
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: consultancy@vanderstok.org
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/core>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Feb 2013 10:12:46 -0000

Hi Akbar and Esko,

many thanks for the 5th version of the group comm draft.
I do have a few remarks, where the text is not clear to me.

section 3.3 second alinea group communication will not work if there is 
diversity....
I assume that you mean "multicast based" group communication. The 
alternative based on unicast wil work perfectly with diversity

section 3.5 point 2. It took me 3 readings before I mastered its 
meaning.

section 3.6
Here I do not understand. I thought that multicast message are 
recommended to be non-confirmable. Why do you need to suppress 4.xx, 
2.05 , etc responses?
When a response is wanted the multicast receiver sends a message with 
some delay, or possibly a RST when not multicast aware.
Consequently, for me the relation of the text of 3.6 with coap-13 is 
unclear.
Secondly, the concept of "IP stack interface" is rather vague. I would 
expect more concrete text.

section 3.9 Does the text say that MPL cannot be used when RPL is set 
to "non-storing mode"?

section 4
I should like to suggest a different approach with two network 
technologies (A) and (B).

(A) mesh based
Keep the two mesh subnets and assume the RTR-1 and RTR-2 are on the 
same ethernet link.
(1) Assume Rtr-1 and RTr-2 are MPL enabled. In that case there is a 
single multicast domain and then all group members are reached with one 
multicast invocation.
(2) Assume that Rtr-1 and RTr-2 are not part of one MPL domain. In that 
case I would suggest to use two MCast invocations, one for subnet-1 and 
one for subnet-2.
Within a subnet MPL is used, non-encapsulated when source is in same 
subnet, and encapsulated when source is in different subnet.

(B) ethernet based
Assuming that the subnets are 802.11 or ethernet based, it may be 
useful to look at how UPnP uses IP Mcast for eventing. It has the 
advantage of being used in the field.

I hope this helps,


Peter

-- 
Peter van der Stok
mailto: consultancy@vanderstok.org
www: www.vanderstok.org
tel NL: +31(0)492474673     F: +33(0)966015248