Re: [v6ops] Apple and IPv6, a few clarifications - ND proxy for bridging hotspots

Mark ZZZ Smith <> Fri, 26 June 2015 06:48 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 6016C1B2FC7 for <>; Thu, 25 Jun 2015 23:48:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 3.202
X-Spam-Level: ***
X-Spam-Status: No, score=3.202 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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, HK_RANDOM_FROM=1, HK_RANDOM_REPLYTO=0.999, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id F-1I_gy2fNnx for <>; Thu, 25 Jun 2015 23:48:03 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 98F7F1B2FC6 for <>; Thu, 25 Jun 2015 23:48:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s2048; t=1435301282; bh=ZpYby8N6G4HjKh+jeSwVyYe4xA+29fa68i1r5h+5p8A=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=a3p5cBNhw+b7F2Ko7aFoulAP3k1QnyZkE6usILfGxZKJOsAS1HCsExO+xC/pUNCQ+y1Bke0/70bizUiYt228ljJOvDNGZgrkys9WD/VXDX/q42t5czyogJYPFu3B7tFtxtoVuck/kocgiWFXxFjI3YeLYlJMnk3UzrzglJFXAAurStpyXcJaEuPZ7B+wCAEH5KDp2vnOEjMXkJZKTZVCTYotQR+b60LTt4uR7fPiNVUqPgnpZxlMDB0SKICrlkOqBKiRWstmbaCCu6aNdbsIKRSYbiAK0nAS5F1mfVaqAoh5yabHPEZfMXy2/FoYG7To9VSHcMa0rxCgUyKIOiaK7g==
Received: from [] by with NNFMP; 26 Jun 2015 06:48:02 -0000
Received: from [] by with NNFMP; 26 Jun 2015 06:48:02 -0000
Received: from [] by with NNFMP; 26 Jun 2015 06:48:02 -0000
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: BkP2R0gVM1kC3oMqndnD9pfWS4VgV3sbahNUUNm6MOjQ80mEdU7YCM6Zae9CnjP fstj8vvL3ssT.diSNZCEQnz69pEum4ZD_Ax0O9LmmRNdFjlAdMKld8ZfzDRSaIO1VGXqyRVsHTBc DPEaaa7eVQxJNymyQxvwu5N4CbvHyLvjDC5.C5B.sDFZSCiymbIAH8XTpOJP7d.pRzN.OCJA9Aaf ejAbfcTTPKbk_jOisKmMQDPSpyUxSh2p9dY8psbAJuQxEor6Zfa.EsacAOJghhfvJMR36Ld_LRrL PlBZqiZX0h1c1SMVOylFST652DoReXlEYpm49RPH41YnFHJ2jK4SI2at8bX7pgfwY7BbYFtgM7gs CVTkEdPXimgV8LkC7VOwg1GXa8kypsm97.bWfgSckgY7SzAqkRe6.4AzmMHNYFk7Wtg0jlZM4e2a WibIc1nBRjgfuJpWc57d679RXhVmKhPa70fkXkFC.7TyKhrsALUqtqnnV8G7t1YuJhSog8jntnkN PYSCDteM2bwrcf7qlb1TlZQxgOw1WxtGiWkz797IpQqXcVI7gmw--
Received: by; Fri, 26 Jun 2015 06:48:02 +0000
Date: Fri, 26 Jun 2015 06:48:01 +0000 (UTC)
From: Mark ZZZ Smith <>
To: Owen DeLong <>, Gert Doering <>
Message-ID: <>
In-Reply-To: <>
References: <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_175398_289016600.1435301281821"
Archived-At: <>
Cc: "" <>
Subject: Re: [v6ops] Apple and IPv6, a few clarifications - ND proxy for bridging hotspots
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Mark ZZZ Smith <>
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 26 Jun 2015 06:48:07 -0000

      From: Owen DeLong <>
 To: Gert Doering <> 
 Sent: Friday, 26 June 2015, 5:24
 Subject: Re: [v6ops] Apple and IPv6, a few clarifications - ND proxy for bridging hotspots

> For the typical driver who is already challenged pairing his mobile via
> BT with his car's handsfree?  No go.  Do one thing, do it well, and NEVER
> ask a car owner (or any normal Internet user) about technical decisions.

We can agree to disagree. IMHO, this should be as simple as two settings.

One on the phone: Provide Internet Access to Car: ON/OFF

One in the car: Get internet access from: CAR <-> PHONE

As to the typical driver being challenged pairing his mobile, frankly, I’m challenged
with that on many occasions, not because I don’t know how to do it and not because
I don’t understand what is involved or can’t follow directions, but because BlueTooth
pairing implementation on most cars and most devices is a steaming pile of poorly
written and even less well tested code that is fragile, buggy, and unreliable.

Assuming that the underlying connectivity code works, the above two settings
should not be difficult to implement correctly. They are far less complex than

/ I think another thing to remember is that "enablement" can imply a default. For example, if my car comes with a SIM slot, and I choose to put one on in it, then I've implicitly chosen that the car should by default use the connectivity provided by its own 3/4G connectivity. I'm also have likely to have chosen the particular SIM and its associated usage plan based on my expected usage of the Internet by and possibly in the car. If the car also has a Wifi hotspot in it, I'll likely associate my phone with it once, so that from then on my phone will automatically use the car's connectivity every time I get in it, without any intervention on my part at all. That would be much more convenient than having to switch on and off hotspot support on my phone each and every time I get in the car - and it is likely people will sometimes forget, and then try to do that while they're driving, which will be as or more dangerous than sending text messages while driving.
/ Having choice can be good, but you want to try to minimise both the amount of choices and how often people have to make them - too much choice can lead to paralysis, such that making no choice becomes the safest "choice".  I think when it comes to usability, predictable and expected defaults, and matching peoples' existing conceptual and mental models are much better. The book "The Design of Every Day Things" is an excellent book on making things easier to use.
/ Regards,/ Mark.


v6ops mailing list