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

[Mark Smith <[e-mail]>]

Hi David,

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

><snip>

>>
>> 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.

Regards,
Mark.