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

From: David Farmer <[email-masked]>
Date: Mon, 6 Mar 2017 12:06:31 -0600

A few more tweaks, corrections and other changes some based on feed back;

1. IPv6 unicast routing is 128 bits in length [BCP198]/[RFC7608], AKA not
classful!
2. SLAAC is commonly used to generate unicast addresses, therefore subnet
prefixes and IIDs are 64 bits for most address.
3. Explicitly allow subnet prefix lengths other than 64 bits for manually
config and DHCPv6 while still recommending 64 bits (most code does this now
and has since the beginning)
4. IIDs of 64 bit are REQUIRED for SLAAC, except when overridden by an
IPv6-over-foo doc  (we really can't change 64 bit IIDs for SLAAC, it would
break running code, at least not right now, maybe in the future)
5. Sites should get more than a single /64 [BCP157]/[RFC6177], and sites
include mobile
6. Avoid other explicit exceptions or recommendations for longer prefixes,
like RFC6164
7. include references to [BCP204]/[RFC7934] and [RFC6052] in the right
places

In the current draft, remove the 2nd paragraph of 2.4, then add the
following sentence to the end of the first paragraph of 2.4;

   Furthermore, IPv6 unicast routing is based on prefixes of any length up
to 128 bits
   [BCP198].

Then add the following two paragraphs at the end of section 2.4;

   Stateless Address Autoconfiguration(SLAAC)[RFC4862] is commonly used
   to automatically create unicast addresses, therefore most unicast
   addresses have 64-bit subnet prefixes and 64-bit interface IDs. The
   rationale for the 64-bit boundary in IPv6 addresses can be found in
   [RFC7421].

   Nevertheless, unicast addresses may also be provided from a node's
   internal configuration (AKA manual or static configuration) or via
   Dynamic Host Configuration Protocol version 6(DHCPv6)[RFC3315]. Such
   addresses are assumed to be opaque 128-bit strings without any
   internal structure. These addresses may be associated with subnet
   prefixes of any length, while 64-bit subnet prefixes are recommended.

Then replace the 4th paragraph of 2.4.1 with;

   When unicast addresses are automatically created from a subnet prefix
   and a interface ID (e.g. Stateless Address Autoconfiguration(SLAAC)
   [RFC4862]), a 64-bit interface ID length is required. An "IPv6 over
   <link>" specification may modify this requirement for a specific link
   type. The rationale for the 64-bit boundary in IPv6 addresses can be
   found in [RFC7421].

And replace 2.4.4 with;

   The general format for IPv6 Global Unicast addresses is as follows:

   |         n bits         |   m bits  |       128-n-m bits         |
   +------------------------+-----------+----------------------------+
   | global routing prefix  | subnet ID |       interface ID         |
   +------------------------+-----------+----------------------------+

   where the global routing prefix is a (typically hierarchically-
   structured) value assigned to a site (a cluster of subnets/links in
   a location or mobile), the subnet ID is an identifier of a link
   within the site, and the interface ID is as defined in Section 2.4.1.

   As noted in Section 2.4, most unicast addresses, including Global
   Unicast addresses, have 64-bit interface IDs (i.e., n + m = 64).

   As discussed in [BCP 157], "it should be easy for an end site to
   obtain address space to number multiple subnets (i.e., a block larger
   than a single /64)" or in other words the subnet ID length should be
   greater than or equal to 1 (i.e., m >= 1). Subnet ID lengths of 4, 8,
   12, and 16 bits, and therefore global routing prefix lengths of 60,
   56, 52, and 48 bits respectively, are in common use and recommended.

   Dynamic Host Configuration Protocol version 6 - Prefix Delegation
   (DHCPv6-PD)[RFC3633] is commonly used to automate the distribution of
   global routing prefixes to sites.

   Global Unicast addresses, and their format, are discussed further in
   [RFC3587].

A couple other quickies;

Insert new paragraph at the end of 2.1

   [BCP 204] recommends that networks provide general-purpose nodes with
   multiple global IPv6 addresses per interface when they attach to a
   link, it also describes the benefits of and the options for doing so.

Insert new sentence at the end of 2.4.5

   Additional IPv6 address that carry an IPv4 address are defined in IPv6
   Addressing of IPv4/IPv6 Translators [RFC6052].

Thanks

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815 <(612)%20626-0815>
Minneapolis, MN 55414-3029   Cell: 612-812-9952 <(612)%20812-9952>
===============================================

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 7 Mar 2017 03:46:01 +0900

Wow. That's a lot of for what started off as a reclassification. I don't
think it's a good idea to attempt to wordsmith RFC4291 hoping that one of
the formulations we end up with will somehow reach consensus. Instead, I
would suggest another approach: see what the problems with 4291 are, *write
them down*, and only then write a document explaining what should be
changed and why.

In other words: start with a problem statement.

As for the suggestions themselves: I think allowing non-/64 prefix lengths
on any network that provides service to general purpose hosts is a bad
idea, regardless of whether it uses SLAAC, DHCPv6, or any other address
assignment protocol (no objection to manual configuration). I think it will
lead to some networks will shooting themselves in the foot, or, worse,
impairing their users' connectivity by creating subnets that are too small.

Before everyone rushes to tell me "nobody will do something that silly",
"it's not the IETF's place to prevent people from doing something stupid",
or even "I will recommend that to my competitors" - please think a little
bit bigger. The reality is that there are lots of networks out there, and
lots of administrators that have never read an RFC and will just copy over
whatever configuration they have from IPv4.  (I have a /24 today? Ok, so I
need to use a /120. I have DHCPv4, so I should use DHCPv6 and everything
will work. Easy!) There are also lots of host developers who are similarly
uninformed, and will just try stuff until it works, or just port whatever
code they have in IPv4 to IPv6. If we allow the boundary to change, there
is a near certainty that too-small subnets *will* be configured in some
places, and over time, host software will adapt to the lowest common
denominator. There is a very real risk end up with solutions that "mostly
work most of the time" - things like NAT traversal, and NAT keepalives -
over more robust solutions that rely on strong guarantees from the network
layer. The risk is that the IPv6 Internet will be constrained by IPv4
address scarcity even after IPv4 is gone.

It's up to us to avoid that risk. I continue to be amazed by the people on
this thread who are advocating that we run it.

On Tue, Mar 7, 2017 at 3:06 AM, David Farmer <[email-masked]> wrote:

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
>

---

From: Job Snijders <[email-masked]>
Date: Mon, 6 Mar 2017 19:51:17 +0100

Hi,

On Mon, Mar 6, 2017 at 7:46 PM, Lorenzo Colitti <[email-masked]> wrote:
> them down*, and only then write a document explaining what should be changed
> and why.
>

I suggest to first wait for feedback from the IESG and finish that
process. The last call period ended 5 days ago.

Regards,

Job

---

From: David Farmer <[email-masked]>
Date: Mon, 6 Mar 2017 13:05:45 -0600

On Mon, Mar 6, 2017 at 12:46 PM, Lorenzo Colitti <[email-masked]> wrote:

> the formulations we end up with will somehow reach consensus.
>

There seems to be a fairly strong consensus that RFC4291bis shouldn't go
forward without additional wordsmithing. But that is obviously the IESGs
call.

> Instead, I would suggest another approach: see what the problems with 4291
> are, *write them down*, and only then write a document explaining what
> should be changed and why.
>

The list of 7 points are the problems that many see with 4291bis, maybe
overly summarized, but they are there.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 7 Mar 2017 08:38:14 +1300

> process. The last call period ended 5 days ago.

+many

For a promotion to IS we should be minimising changes to the text.
If we want to change the world, that comes afterwards.

   Brian

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 6 Mar 2017 21:47:00 +0100

agreed with some of the things that I cut but I have one question.

Le 06/03/2017 à 19:46, Lorenzo Colitti a écrit :
> If we allow the boundary to change, there is a near certainty that
> too-small subnets *will* be configured in some places,

and is IETF a place to make recommendations of making big or small
subnets?  Isnt it for the RIRs to make such recommendations?

I mean RIRs decide what to allocate, when there is shortage or not.

But with 64 you seem to be wanting to keep a limit there in order to be
able to unlimit later, or something like that, right?

Alex

> and over time, host software will adapt to the lowest common
> denominator. There is a very real risk end up with solutions that
> "mostly work most of the time" - things like NAT traversal, and NAT
> keepalives - over more robust solutions that rely on strong
> guarantees from the network layer. The risk is that the IPv6 Internet
> will be constrained by IPv4 address scarcity even after IPv4 is
> gone.
>
> It's up to us to avoid that risk. I continue to be amazed by the
> people on this thread who are advocating that we run it.
>
> On Tue, Mar 7, 2017 at 3:06 AM, David Farmer <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> 1. IPv6 unicast routing is 128 bits in length [BCP198]/[RFC7608],
> AKA not classful! 2. SLAAC is commonly used to generate unicast
> addresses, therefore subnet prefixes and IIDs are 64 bits for most
> address. 3. Explicitly allow subnet prefix lengths other than 64
> bits for manually config and DHCPv6 while still recommending 64 bits
> (most code does this now and has since the beginning) 4. IIDs of 64
> bit are REQUIRED for SLAAC, except when overridden by an
> IPv6-over-foo doc  (we really can't change 64 bit IIDs for SLAAC, it
> would break running code, at least not right now, maybe in the
> future) 5. Sites should get more than a single /64
> [BCP157]/[RFC6177], and sites include mobile 6. Avoid other explicit
> exceptions or recommendations for longer prefixes, like RFC6164 7.
> include references to [BCP204]/[RFC7934] and [RFC6052] in the right
> places
>
> Furthermore, IPv6 unicast routing is based on prefixes of any length
> up to 128 bits [BCP198].
>
> Additional IPv6 address that carry an IPv4 address are defined in
> IPv6 Addressing of IPv4/IPv6 Translators [RFC6052].
>
> Thanks
>
> -- =============================================== David Farmer
> Email:[email-masked] <mailto:[email-masked]> Networking &
> Telecommunication Services Office of Information Technology
> University of Minnesota 2218 University Ave SE        Phone:
> 612-626-0815 <tel:(612)%20626-0815> Minneapolis, MN 55414-3029 Cell:
> 612-812-9952 <tel:(612)%20812-9952>
>  IETF IPv6 working group mailing list [email-masked]
> <mailto:[email-masked]> Administrative Requests:
> https://www.ietf.org/mailman/listinfo/ipv6
> <https://www.ietf.org/mailman/listinfo/ipv6>
>  IETF IPv6 working group mailing list [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 7 Mar 2017 12:18:41 +0900

> overly summarized, but they are there.

Well, but what you provided is an alternative solution, not a problem
statement. Example of a problem statement would be, "RFC 4291 does not
allow non-64-bit IID lengths. However, assigning smaller prefix lengths is
necessary because [...]".

I can't help fill in the [...] because I personally don't see what you can
do with a /113 that you can't do with a /64 (other than conserve addresses,
which has always been a non-goal), but there seem to be several
participants who do see a problem. What I'm saying is that if we want to
change the standard, the people who see a problem with it should articulate
that problem in a way that it's possible to find a solution using informed
and documented engineering trade-offs rather than opinions.

---

From: Fred Baker <[email-masked]>
Date: Mon, 6 Mar 2017 19:35:38 -0800

On Mar 6, 2017, at 7:18 PM, Lorenzo Colitti <[email-masked]> wrote:
> I can't help fill in the [...] because I personally don't see what you can do with a /113 that you can't do with a /64 (other than conserve addresses, which has always been a non-goal), but there seem to be several participants who do see a problem. What I'm saying is that if we want to change the standard, the people who see a problem with it should articulate that problem in a way that it's possible to find a solution using informed and documented engineering trade-offs rather than opinions.

</hat>

As you know, I'm not in favor of a standard IID or prefix length. If a given algorithm, SLAAC, requires it, so be it where it is in use (not that this this is a statement of probability, it's a statement of network addressing policy). Of a network chooses to do something different in the absence of that limitation, I understand the Internet Architecture to give it that latitude and the authority to impose an address allocation mechanism and policy.

That said, ...

The argument I have heard for serial lines is that, with high probability, if there are more than 2^1 addresses on a link, selecting a random address for one's peer has a high confidence of selecting an address the peer isn't using, resulting in an ICMP error instead of a response. That, assuming I understand it, is the fundamental argument behind /127. Reduced to simpler terms - if the environment makes assumptions, the addressing should make the same assumptions. 

RFCs in context:

https://tools.ietf.org/html/rfc3627
3627 Use of /127 Prefix Length Between Routers Considered Harmful. P.
     Savola. September 2003. (Format: TXT=12436 bytes) (Obsoleted by
     RFC6547) (Status: HISTORIC) (DOI: 10.17487/RFC3627)

https://tools.ietf.org/html/rfc6164
6164 Using 127-Bit IPv6 Prefixes on Inter-Router Links. M. Kohno, B.
     Nitzan, R. Bush, Y. Matsuzaki, L. Colitti, T. Narten. April 2011.
     (Format: TXT=16057 bytes) (Updated by RFC6547) (Status: PROPOSED
     STANDARD) (DOI: 10.17487/RFC6164)

https://tools.ietf.org/html/rfc6547
6547 RFC 3627 to Historic Status. W. George. February 2012. (Format:
     TXT=4917 bytes) (Obsoletes RFC3627) (Updates RFC6164) (Status:
     INFORMATIONAL) (DOI: 10.17487/RFC6547)

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 7 Mar 2017 12:47:14 +0900

On Tue, Mar 7, 2017 at 12:35 PM, Fred Baker <[email-masked]>
wrote:

> Of a network chooses to do something different in the absence of that
> limitation, I understand the Internet Architecture to give it that latitude
> and the authority to impose an address allocation mechanism and policy.
>

The architecture currently does not give it that latitude, because RFC4291
makes a blanket statement that ("most") IIDs are 64 bits long.

> The argument I have heard for serial lines is that, with high probability,
> if there are more than 2^1 addresses on a link, selecting a random address
> for one's peer has a high confidence of selecting an address the peer isn't
> using, resulting in an ICMP error instead of a response.

I'm not sure I understand this problem statement. Are you saying that for a
link that only has two peers on it, it is convenient to use a subnet that
is /127, because you don't have to know the peer address? That's true, but
it only applies to /127 and not any other prefix size, right?

> That, assuming I understand it, is the fundamental argument behind /127.
> Reduced to simpler terms - if the environment makes assumptions, the
> addressing should make the same assumptions.
>

Isn't that still a philosophical argument that applies to the current
solution, though?

---

From: David Farmer <[email-masked]>
Date: Mon, 6 Mar 2017 22:56:20 -0600

On Mon, Mar 6, 2017 at 9:18 PM, Lorenzo Colitti <[email-masked]> wrote:

>> Instead, I would suggest another approach: see what the problems with
>>> 4291 are, *write them down*, and only then write a document explaining what

To be clear no where in the text I provided does it say that an IID other
than 64 is allow.  It say 128 bit quantities from manual configuration and
DHCPv6 can be associated with with subnet prefixes of any length.  That is
a fine distinction, but no finer that you claiming that requiring that
64-bit IIDs, and you implying 64-bit subnet prefixes too, doesn't make IPv6
classful. Are you saying that every implementation of IPv6 that allows
manual config of subnet prefixes other that /64 have it wrong?
Furthermore, if subnet prefixes other than /64 aren't allowed then how do
we have RFC6164

I contend that the whole concept of an IID is optional, please note that
RFC4291 and it's predecessor say: "At a minimum, a node may consider that
unicast addresses (including its own) have no internal structure", So I
contend that RFC4291 merely says that if you use an IID it must be 64 bits.
It doesn't directly say that 128bit IPv6 addresses can't be associated with
subnet prefixes other than /64.  In fact it also says, "IPv6 unicast
addresses are aggregatable with prefixes of arbitrary bit-length, similar
to IPv4 addresses under Classless Inter-Domain Routing."  Which to me
implies that subnets other than /64 have to be valid.  Furthermore, RAs are
allowed to be any length, especially if they don't set the "A" flag, why is
this if not to allow subnet prefixes of any length?

> and documented engineering trade-offs rather than opinions.

Just because you can't see it doesn't mean that other can't and don't have
valid uses.  I'm not convince it's actually making any change, SLAAC still
has 64-bit IIDs.  It is only making explicit that, manual config and DHCPv6
address can be associated with subnets of any length, and it's clear that
at least some implementors think it says that already, and I think your in
the minority of people that think's it doesn't.

Thanks.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 7 Mar 2017 15:03:56 +0900

> this if not to allow subnet prefixes of any length?

Sure. Now let's write all that down in a document so that these subtle (and
likely controversial) issues can be fully explained and debated. Because:

   1. If these issues are subtle even for us, how can we hope that non-IETF
   participants (or even just non-WG participants) will understand them?
   2. If we don't write them down and just make a change to RFC 4291, how
   can we know that any decision we make is properly justified.
   3. If we don't write them down and just make a change to RFC 4291, how
   will future IETF participants and network administrators and host
   implementers know how to interpret the text we write? I don't think asking
   them to make sense of the 6man archives is reasonable.

> valid uses.

Absolutely agreed. Let's write those uses down, and use them to inform our
decision as to how (and whether) we should change the standard.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 7 Mar 2017 15:15:09 +0900

On Tue, Mar 7, 2017 at 1:56 PM, David Farmer <[email-masked]> wrote:

> It is only making explicit that, manual config and DHCPv6 address can be
> associated with subnets of any length, and it's clear that at least some
> implementors think it says that already, and I think your in the minority
> of people that think's it doesn't.
>

If you're talking about the current state of the standards, It doesn't
matter whether I am in the minority or not because the standard is pretty
clear about how things work. The current state is that (for unicast
addresses not starting with 0b000):

   - IIDs are 64 bits in length, because of RFC 4291 §2.5.1
   - Subnet Prefixes are 64 bits in length, because of RFC 4291 §2.5.0
   and 128-64 = 64
   - IIDs are required to be unique in a subnet prefix, because of RFC
   4291 §2.5.1
   - On-link determination is separate from the Subnet Prefix, because of
   RFC 5942 (partly motivated by RFC 4903 §4.2, which the current discussion
   seems to completely ignore)
   - On-link determination is determined by PIOs with L=1, because of RFC
   5942.
   - When L=1 is not specified the on-link prefix length of any given
   address is undefined, and the IAB recommends that implementations treat the
   prefix length as undefined, or treat it as /128.

So, if by "subnet" you mean Subnet Prefix as defined in RFC 4291, then it's
clear that the subnet is 64 bits long. If by "subnet" you mean "on-link
prefix", then a DHCPv6-assigned address is not associated with *any*
on-link prefix length, because on-link prefix lengths are configured
completely separately.

Manual configuration is not specified in the standards so it's not clearly
defined anywhere what the /64 in "2001:db8::1/64" means. We may have
opinions, and observe the behaviour of implementations, but those remain
opinions and observations.

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 7 Mar 2017 20:06:54 +0100

DAvid,

I think we talk past each other.  But I will duly continue to complain
about this :-)

Le 06/03/2017 à 19:06, David Farmer a écrit :
> address.

This is a wrong assumption.  Because of this assumption there are very
bad consequences in the 3GPP networks.

> 3. Explicitly allow subnet prefix lengths other than 64 bits for
> manually config and DHCPv6 while still recommending 64 bits (most
> code does this now and has since the beginning)

Also allow them explicitely for SLAAC as well.

Allow it for LL prefixes as well.

> 4. IIDs of 64 bit are REQUIRED for SLAAC, except when overridden by
> an IPv6-over-foo doc

Really vice-versa: they are variable by default when considered by SLAAC.

I think you dont want to accept it, but it's in the RFC.

> (we really can't change 64 bit IIDs for SLAAC, it would break running
> code, at least not right now, maybe in the future)

That is what you think.

Sending a RA /65 wont break an existing linux kernel, and new kernels
may use 48bit IIDs out of 48bit MAC addresses, pad some 0s, and make a
128 address.

I dont undersrtand what you mean by "changing 64bit IIDs for SLAAC would
break running code."

The person complaining about non-64bit IIDs, as I understand it,
complains about non-64bit IIDs *for 464xlat*, not for SLAAC.

> 5. Sites should get more than a single /64 [BCP157]/[RFC6177], and
> sites include mobile

Yes, that is a requirement.  Mobile entities including 3GPP UEs MUST get
more than a single /64.  And that conflicts headfront with some 3GPP
spec.  That conflict should be solved, not attenuated.

Until then we are not in a good position to safely assume that nodes get 
more than a single /64 per node.

> 6. Avoid other explicit exceptions or recommendations for longer
> prefixes, like RFC6164 7. include references to [BCP204]/[RFC7934]
> and [RFC6052] in the right places
>
> When unicast addresses are automatically created from a subnet
> prefix and a interface ID (e.g. Stateless Address
> Autoconfiguration(SLAAC) [RFC4862]), a 64-bit interface ID length is
> required.

This is wrong, again.

SLAAC does not require 64bit IIDs.  It is Ethernet who does.

SLAAC works with 48bit IIDs.

> An "IPv6 over <link>" specification may modify this requirement for a
> specific link type.

This is a good requirement.

But, most IPv6-over-foo documents _immitate_ Ethernet.  I.e. 64+64. 
Continue this way and no IP-over-foo will ever dare to not immitate 
Ethernet.

> +------------------------+-----------+----------------------------+ |
> global routing prefix  | subnet ID |       interface ID         |
> structured) value assigned to a site (a cluster of subnets/links in a
> location or mobile), the subnet ID is an identifier of a link within
> the site, and the interface ID is as defined in Section 2.4.1.
>

This is so wrong, please remove it.
There are many GUAs there that dont have 64bit IIDs.  Sometimes the IID 
is just 1.

> As discussed in [BCP 157], "it should be easy for an end site to

And how about a mobile?

Actually it is not that easy, as you can see.  As such dont make the 
assumption.

> obtain address space to number multiple subnets (i.e., a block
> larger than a single /64)" or in other words the subnet ID length
> should be greater than or equal to 1 (i.e., m >= 1). Subnet ID
> lengths of 4, 8, 12, and 16 bits, and therefore global routing prefix
> lengths of 60, 56, 52, and 48 bits respectively, are in common use
> and recommended.

Because your assumption for sites does not hold true for mobiles these 
latter find themselves in the impossibility to actually exist.

Were it easy for mobiles to obtain multiple /64s then I would agree with 
you to continue with this 64.  But it is not.

> (DHCPv6-PD)[RFC3633] is commonly used to automate the distribution
> of global routing prefixes to sites.

So one would expect that to Mobiles as well, but no.

Alex

> [BCP 204] recommends that networks provide general-purpose nodes
> with multiple global IPv6 addresses per interface when they attach to
> a link, it also describes the benefits of and the options for doing
> so.
>
> 612-626-0815 <tel:(612)%20626-0815> Minneapolis, MN 55414-3029
> Cell: 612-812-9952 <tel:(612)%20812-9952>

---

From: Mark Smith <[email-masked]>
Date: Wed, 8 Mar 2017 23:13:19 +1100

On 7 Mar. 2017 7:47 am, "Alexandre Petrescu"
<[email-masked]> wrote:

> subnets?  Isnt it for the RIRs to make such recommendations?

Protocol designers have to make addressing design decisions, such as
the structure of addresses and special address value semantics. If
they didn't, then it would only be possible to have a single
forwarding method and no other semantics embedded in addresses for the
entire address space.

For example, if the entire address space is chosen to be destination
based unicast addresses, because only a single choice can be made,
there will be no possibility of any multicast forwarding, or a special
purpose loopback address or prefix.

It is also useful if they choose general defaults, so that things can
work without significant or ideally any configuration.

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.

Regards,
Mark.

---

From: David Farmer <[email-masked]>
Date: Wed, 8 Mar 2017 10:41:58 -0600

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

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.

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: Mark Smith <[email-masked]>
Date: Sat, 11 Mar 2017 14:24:28 +1100

Hi David,

><snip>

> Following that analogy, I'd agree that most cars have default parameters and
> they should, but almost all car actually have parameters, sometime thos
> (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.

> parameters, at least none that are exposed on the dashboard.  And I have to

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.