Re: A 3rd try at a proposal for draft-ietf-6man-rfc4291bis-07

Mark Smith <> Sat, 11 March 2017 03:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E2EF012944B for <>; Fri, 10 Mar 2017 19:25:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.499
X-Spam-Status: No, score=-0.499 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, HK_RANDOM_FROM=0.999, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9trNTWUUfk56 for <>; Fri, 10 Mar 2017 19:24:59 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400c:c08::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B3B7E126BF7 for <>; Fri, 10 Mar 2017 19:24:59 -0800 (PST)
Received: by with SMTP id u30so132370493uau.0 for <>; Fri, 10 Mar 2017 19:24:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=f+brqecB75pAqwn0K856u1jLDXKqNPsIYuwz37/Eqj4=; b=hFwWxsgujxiDbbOgFSybXrFsa14xNEY+vNVFoWBd0D9YhHaoQCwyw70m5WXwgVIWV/ 9yPB6w+UdYBlShGbXyzmZ8oAszd8JYWv49mdL0qM0KgpfQyaXUX+SzJOi7l+pkhzE5iI z3pgHmrw7CR70bpr2KNB4fHm8LcAKtMWtrnjDB+RgvrpASjRP+rOwx1WhEFQzawU0gtf rsV9yqXzJV6DXqyi0KGnBKDJnwGRF/CkWrkoaTLjvLHq4u3cddmkYAVxhtMra1b9U+N7 pW6wH2lQp9HkusCWcBPSsHcLS9UbMFEARZFuMnMOEFISrp7uNpJ/b5nI1j+HdxeOtd7n 34gA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=f+brqecB75pAqwn0K856u1jLDXKqNPsIYuwz37/Eqj4=; b=CpWozojyGu4uUOoD1auCOKUFdhv/y8O3zsx2hI0DbRx0aPD8YwgWW+faBOr2lixYEG EL5dVueGskZRASryX6cGjCgaLQgQmwK3QKysY8Ffx1sjgeTq/XZAtjuT2V6ldffTWO3u XdFD0xyEo8/u6Z8i+tnp/EcvaFO3xWooiZTDBVTHSE8YXWtwtCk3We88McQxvCcjkpUe 7CjiYVbxn+HDDJHTwEL9gG+BGcWMHlmWVmlD/sYykz2yeOhGkrPXvU2EQrRKcPaQSYhn cz/WUICJYGl0NgUW3Oy+vx3ilVRt+kQckdLealtlHrYtN0Z6yIK3ADcFFKCwIrJA7Any 6cAQ==
X-Gm-Message-State: AMke39mRX2TjYORzC+BKKvGQyqO2c6X7NFA6vmn0y4IAruiBe6C1S5mpLklozZW9vUgsxzcyHG5WeqfkyXf5iw==
X-Received: by with SMTP id 81mr11494316uai.97.1489202698763; Fri, 10 Mar 2017 19:24:58 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Fri, 10 Mar 2017 19:24:28 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <>
From: Mark Smith <>
Date: Sat, 11 Mar 2017 14:24:28 +1100
Message-ID: <>
Subject: Re: A 3rd try at a proposal for draft-ietf-6man-rfc4291bis-07
To: David Farmer <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc: Alexandre Petrescu <>, 6man WG <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 11 Mar 2017 03:25:01 -0000

Hi David,

On 9 March 2017 at 03:41, David Farmer <> wrote:
> On Wed, Mar 8, 2017 at 6:13 AM, Mark Smith <> wrote:
>> On 7 Mar. 2017 7:47 am, "Alexandre Petrescu"
>> <> wrote:


>> Imagine the situation of buying a car, and not being able to drive it,
>> because none of its tunable parameters had been set to reasonable
>> defaults. Mechanics wouldn't have a problem, and may enjoy the
>> experience of setting all the parameters to make the car work. The
>> rest of wouldn't find buying a car an easy experience at all.
>> Mechanics would lobby against making cars (literally) turn-key,
>> because they would be making money from setting all the parameters.
> Following that analogy, I'd agree that most cars have default parameters and
> they should, but almost all car actually have parameters, sometime thos
> parameters are exposed to the most naive users, not just expert users.
> (e.g. many cars have a Sport/Econo button on the dashboard, and then almost
> all cars have tunable parameters under the hood).

In my analogy, I'm describing a car that literally will not work
(i.e., not start) because none of the parameters have been set to
default reasonable values, they've all been left as zero by the
factory. So after you've paid the car dealer, the first thing you then
have to pay is a car mechanic to then come and set the parameters so
that you can drive the car e.g., the mechanic would have to be engaged
to set the spark plug timing and the fuel injector sequence because
the ECU would not have working defaults for those and many other
similar parameters.

It seemed that the argument Alex was making (by suggesting the RIRs
should pick) and I think others are making against 64 bit IIDS is that
"some people don't agree with that value, so the IETF shouldn't be
providing a default value." By that argument, there are also many
other IETF parameters that shouldn't have default values e.g., OSPF
hello intervals, TCP timeouts etc. There would probably be close to
100 that need to be set to a working set of hosts talking across a
working network.

The sport/economy car parameter you used as an example is overriding a
default, and it is entirely optional to change it. Making it mandatory
to set, every time you started the car, because there was no default,
would not be very car user friendly.

I think the only parameters that should be exposed to end-users of
computers are ones that take very little and ideally no technical
expertise to understand, and are entirely optional to change. Even
then it is good to hide them away if possible to reduce UI complexity
and confusion.

I like the Arthur C. Clarke quote - "Any sufficiently advanced
technology is indistinguishable from magic." We should be trying to
make our technology magic as possible, and reasonable, power-on
defaults is a very good way to do that.

> Lorenzo seems to be arguing that all cars must not have any tunable
> parameters, at least none that are exposed on the dashboard.  And I have to
> disagree.

I think it is a good goal, as it means that the user of the device
doesn't have to make decisions about the operation of the device and
therefore learn enough to make those decisions.

I do think there can be exceptions though - I commonly run my Android
phone down to 15%,when battery saver mode kicks in. Usually I'm not
far away from being able to charge it, and want to be able to continue
to use it at full speed, so I override the battery saver mode. Similar
to your sport/economy example, it's an optional override, and doesn't
require much technical understanding to make the correct choice.