IETF Logo Mail Archive

Re: [core] Fwd: New Version Notification for draft-cao-core-delegated-observe-00.txt

Christian Amsüss <c.amsuess@energyharvesting.at> Mon, 14 November 2016 03:09 UTC

Return-Path: <c.amsuess@energyharvesting.at>
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 AB11512979D for <core@ietfa.amsl.com>; Sun, 13 Nov 2016 19:09:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XPHtqBsKbkT4 for <core@ietfa.amsl.com>; Sun, 13 Nov 2016 19:09:10 -0800 (PST)
Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B9451296E9 for <core@ietf.org>; Sun, 13 Nov 2016 19:09:03 -0800 (PST)
Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 06B62404A2; Mon, 14 Nov 2016 04:09:01 +0100 (CET)
Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 0F68A1E0; Mon, 14 Nov 2016 04:09:00 +0100 (CET)
Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [10.13.13.129]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id B9953569; Mon, 14 Nov 2016 04:08:59 +0100 (CET)
Received: (nullmailer pid 30004 invoked by uid 1000); Mon, 14 Nov 2016 03:08:59 -0000
Date: Mon, 14 Nov 2016 04:08:59 +0100
From: Christian Amsüss <c.amsuess@energyharvesting.at>
To: Zhen Cao <zhencao.ietf@gmail.com>
Message-ID: <20161114030859.hx563ikemh3i5m2v@hephaistos.amsuess.com>
References: <147755820733.19004.16975897284050743537.idtracker@ietfa.amsl.com> <CAFxP68z844+ra1ZrHAzPYqOBA0ugqZJKHuhumzfg9NqY=MXQmg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="lx2ai6n6347ziq3b"
Content-Disposition: inline
In-Reply-To: <CAFxP68z844+ra1ZrHAzPYqOBA0ugqZJKHuhumzfg9NqY=MXQmg@mail.gmail.com>
User-Agent: NeoMutt/20161104 (1.7.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/GqZu3jnERNqRUDWFe8zB6hj-Jj4>
Cc: "core@ietf.org WG" <core@ietf.org>
Subject: Re: [core] Fwd: New Version Notification for draft-cao-core-delegated-observe-00.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
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: <https://mailarchive.ietf.org/arch/browse/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: Mon, 14 Nov 2016 03:09:12 -0000

Hello Zhen,

thank you for submitting a draft.

I've read through your delegated-observe draft, and have several
questions / suggestions regarding it:

* Regarding the cloud use case: Using an unspecified protocol to
  negotiate this setup (where for example a token would need to be
  exchanged that the in-home dev would then use) strikes me as
  relatively complex for the given task. Have you considered that the
  in-home dev could simply implement a proxy and open a coap-over-tcp
  connection to the cloud server?

  If the cloud server implements a proxy itself, the dev off-home could
  send the same observe request as it locally would, just to the cloud
  server as a forward proxy (which then again uses a second forward
  proxy), and neither a delegate observation nor an additional
  observation negotiation protocol is needed.

* Multicast: Have you considered the applicability of
  draft-ietf-core-dynlink-01 or draft-ietf-core-coap-pubsub-00?

* Multicast: Some protocol would be required for the bulbs to coordinate
  too, because Bulb_2 and Bulb_3 need to agree on a token to identify
  the incoming observation responses.

* Terminology: I find the "delegate" and "delegated" node terms
  confusing (and if it's only because a search for "delegate" also
  matches "delegated"). Maybe "Initiating node" / "Notified node" or any
  other more distinct term could replace at least one of the
  delegate{,d} names.

* Do I understand the graphs correctly that no response is sent to the
  delegate node unless it is itself in the delegated multicast group?

  If so, how is reliable transmission ensured?

Best regards
Christian

-- 
Christian Amsüss                      | Energy Harvesting Solutions GmbH
founder, system architect             | headquarter:
mailto:c.amsuess@energyharvesting.at  | Arbeitergasse 15, A-4400 Steyr
tel:+43-664-97-90-6-39                | http://www.energyharvesting.at/
                                      | ATU68476614

v2.23.0 | Report a Bug | By Email