Fwd: Re: US patent on an IPv6 geolocation header extension

Mark Smith <markzzzsmith@gmail.com> Thu, 18 January 2018 20:17 UTC

Return-Path: <markzzzsmith@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEB7C12D835 for <ipv6@ietfa.amsl.com>; Thu, 18 Jan 2018 12:17:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.198
X-Spam-Level:
X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 0g1NBZaBlQsC for <ipv6@ietfa.amsl.com>; Thu, 18 Jan 2018 12:17:31 -0800 (PST)
Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43C7C1201F2 for <ipv6@ietf.org>; Thu, 18 Jan 2018 12:17:31 -0800 (PST)
Received: by mail-vk0-x22d.google.com with SMTP id q62so11526335vkb.11 for <ipv6@ietf.org>; Thu, 18 Jan 2018 12:17:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=AGONR3HGRLUJHC/FlM1cJb2IVvBWg+JCQSTMWbHU6EE=; b=XIOntJQtnL3364UFP3JzPZhEdrZ4FdKGsN2niLRnNpohtIQJ9Cta/tOEkWoF2a+rMI ULQ2O760b9ZZdSOu8GycZ0g6DZuTm3fhOgF6brFuHcWtyF93yEX/V/seOVoarkvaDisj +jWISz4/9xBGoON7GSRdfX/1wSp7OtCGVDi0uyL5tsA+ftqU9LlYFyTaEw31ZIFT00s1 jKbIa5EbHHILPz8nSeZbQFPKuGzLtMpv8KRsAAy+Etak+gJngOjfIzEFK5NNrGblDTqq COdWIWNzDCXr8o0HoRnrWYBMdqUMzEBELuz/0p4ca2oPSRocbJ+0ilaGRBrXDNz5d7h+ 8tFA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=AGONR3HGRLUJHC/FlM1cJb2IVvBWg+JCQSTMWbHU6EE=; b=WOTV40Jc1MX6+5IkSxl7uw0w3lm/Lu7gnuk0UteV4rQvzzWCz4DSi+wxHId113TVG8 j40oVCFu/YV4Roea0Trv0e+iIQ361J5RW2K+QoPiSnBfWZDZFFcK4oNgCBZmJmPeCk9W x5PSDlmpdSYHPeAD6ui3f6em0aGaiWApnFSOm+p1pkrOuMBftrCWFiIMEU7d0zT/trBh TYJ1hUTxk+5GV7LbulCQMoV2IL8kHcsARMUxKE731oBhEH/anT9zmDfJZtuvyoRW/+2S dUJUkeZHLbYgEbaTm78231k9cg7C863lnfHU8T+GP6VognoH5Yb4cMqIIDyGy9byvFP0 u81g==
X-Gm-Message-State: AKwxyteQwlcv+Stkdp538Vp8p3XIrf8ImcK/TWq2rdOD8X6h7IY0I1+J lMuOzviNozQkZjEKEVWmckdgxF4088RI7V6GU8A=
X-Google-Smtp-Source: ACJfBos2OcVOyGEQ70JCD+g90kSzqB7BQ9v+e6byjzOPcOTV7CJccjXT8Wt8yi8VMu9iVaZ5iJtOvHfsHGnhlD7Nnj4=
X-Received: by 10.31.130.212 with SMTP id e203mr1465305vkd.34.1516306649834; Thu, 18 Jan 2018 12:17:29 -0800 (PST)
MIME-Version: 1.0
Received: by 10.159.53.99 with HTTP; Thu, 18 Jan 2018 12:17:29 -0800 (PST)
Received: by 10.159.53.99 with HTTP; Thu, 18 Jan 2018 12:17:29 -0800 (PST)
In-Reply-To: <CAO42Z2wO-SLOSo6T36EEydTsn7oPBb3Wx9Vx21Ox_CuGxkhP=A@mail.gmail.com>
References: <alpine.OSX.2.21.1801151335550.1660@ary.qy> <CAO42Z2wvamS0yNpVa9+7jvr+XszQ=1fDW3JNAz-9O=PihhbowQ@mail.gmail.com> <c166dc83c586411993edc382aed8b920@XCH15-01-07.nw.nos.boeing.com> <d7e43251-2c44-b235-bc4c-baadf659f370@bogus.com> <CAO42Z2wO-SLOSo6T36EEydTsn7oPBb3Wx9Vx21Ox_CuGxkhP=A@mail.gmail.com>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Fri, 19 Jan 2018 07:17:29 +1100
Message-ID: <CAO42Z2w-79xA7_pmyKo1hpiLyrWj4PzZ2AmYt5FMea+Gf8kb2A@mail.gmail.com>
Subject: Fwd: Re: US patent on an IPv6 geolocation header extension
To: 6man WG <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="001a114112ce3bf056056312a7eb"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/8-jlgHk382LioK5FcAFin_F391g>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Jan 2018 20:17:33 -0000

---------- Forwarded message ----------
From: "Mark Smith" <markzzzsmith@gmail.com>
Date: 19 Jan. 2018 07:14
Subject: Re: US patent on an IPv6 geolocation header extension
To: "joel jaeggli" <joelja@bogus.com>
Cc:



On 19 Jan. 2018 06:52, "joel jaeggli" <joelja@bogus.com> wrote:



On 1/18/18 11:04 AM, Manfredi, Albert E wrote:
> -----Original Message-----
> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Mark Smith
>
>> Here's some prior art from 2013.
>>
>> "Enhancing Location Based IP Services"
>> https://tools.ietf.org/html/draft-add-location-to-ipv6-header-01
> I thought that rang a bell (reminded me of something). Wasn't there some
who disliked the idea intensely, just because it disclosed geo location
without the use being aware as the user might be, if that feature was in an
app? I seem to remember some acrimony involved.
If you add this sort of thing at an intermediate hop, you have all of
the attendant problems of unstated or lack of consent that go along with
adding host identifiers of any kind (we largely have IETF consensus not
to work on host-identiers). If you add it only on the endpoint, consent
can be achieved in various ways. Protecting that information from
mid-point observers is an important consideration that would tend to
preclude embedding it for use by the network or transport layers.

Applications have no problems reporting to each other where they are
without recourse to lower-layer signaling.


+1

I think it does raise the question of whether i this information is better
in an application rather than the network layer.

If conveyed within non-specific applications is not reliable or universal
enough, than a specific geolocation conveying application would be the
alternative that doesn't require a new EH. Whether to run the app or not is
expressing the geolocation privacy choice.

Devices that are required to run it, e.g. corporate devices, will have that
enforced by the device administrators preventing device end-users from
disabling it.

Regards,
Mark.


> Bert
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>