Re: [Lwip] Spencer Dawkins' Yes on draft-ietf-lwig-cellular-05: (with COMMENT)

Jari Arkko <jari.arkko@piuha.net> Thu, 17 September 2015 13:50 UTC

Return-Path: <jari.arkko@piuha.net>
X-Original-To: lwip@ietfa.amsl.com
Delivered-To: lwip@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB681B301D; Thu, 17 Sep 2015 06:50:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 aqZ_UNLVtZ3e; Thu, 17 Sep 2015 06:50:46 -0700 (PDT)
Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 4847D1B301B; Thu, 17 Sep 2015 06:50:46 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id D94E82CD02; Thu, 17 Sep 2015 16:50:44 +0300 (EEST) (envelope-from jari.arkko@piuha.net)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5XZWagqK0hqM; Thu, 17 Sep 2015 16:50:44 +0300 (EEST)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 202A02CC5C; Thu, 17 Sep 2015 16:50:42 +0300 (EEST) (envelope-from jari.arkko@piuha.net)
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Content-Type: multipart/signed; boundary="Apple-Mail=_32A08F69-25E4-4920-A384-61E4C2B6871D"; protocol="application/pgp-signature"; micalg="pgp-sha512"
X-Pgp-Agent: GPGMail 2.5.1
From: Jari Arkko <jari.arkko@piuha.net>
In-Reply-To: <20150916183154.4711.69709.idtracker@ietfa.amsl.com>
Date: Thu, 17 Sep 2015 06:50:41 -0700
Message-Id: <524F037B-D5F4-4192-9FE1-3A09BFFABFC1@piuha.net>
References: <20150916183154.4711.69709.idtracker@ietfa.amsl.com>
To: Spencer Dawkins <spencerdawkins.ietf@gmail.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/lwip/n8PH4JvZcPvn1CAP_zmW57fHgSE>
Cc: The IESG <iesg@ietf.org>, lwip@ietf.org
Subject: Re: [Lwip] Spencer Dawkins' Yes on draft-ietf-lwig-cellular-05: (with COMMENT)
X-BeenThere: lwip@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Lightweight IP stack <lwip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lwip>, <mailto:lwip-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lwip/>
List-Post: <mailto:lwip@ietf.org>
List-Help: <mailto:lwip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lwip>, <mailto:lwip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Sep 2015 13:50:48 -0000

Thank you Spencer.

> You mention the difficulty of acting as a server behind a NAT. I wonder
> if you might also mention the power drain that's often required to
> maintain port bindings on NATs when a device is not actively
> transmitting. That may not be a problem for sleepy devices, but might be
> for real-time reachable devices.

Right. We could do that.

> Manufacturer Server
> 
>      The DNS name of the directory or proxy is hardwired to the
>      software by the manufacturer, and the directory or proxy is
>      actually run by the manufacturer.  This approach is suitable in
>      many consumer usage scenarios, where it would be unreasonable to
>      assume that the consumer runs any specific network services.  The
>      manufacturer's web interface and the directory/proxy servers can
>      co-operate to provide the desired functionality to the end user.
>      For instance, the end user can register a device identity in the
>      manufacturer's web interface and ask specific actions to be taken
>      when the device does something.
> 
>   Delegating Manufacturer Server
> 
>      The DNS name of the directory or proxy is hardwired to the
>      software by the manufacturer, but this directory or proxy merely
>      redirects the request to a directory or proxy run by the whoever
>      bought the device.  This approach is suitable in many enterprise
>      environments, as it allows the enterprise to be in charge of
>      actual data collection and device registries; only the initial
>      bootstrap goes through the manufacturer.  In many cases there are
>      even legal requirements (such as EU privacy laws) that prevent
>      providing unnecessary information to third parties.
> 
> The reference to legal requirements under "Delegating Manufacturer
> Server" made me think this was only appliable to "Delegating Manufacturer
> Server", but not to "Manufacturer Server". Is that the case? Or is it
> applicable whether the Manufacturer Server is delegating or not?

We could try to make it clearer. There are situations where the legal
requirements are relevant, e.g., healthcare. In those situations the
manufacturer server approach might be inappropriate.

Jari