[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
- [core] core-groupcomm-05 peter van der Stok