[prev in list] [next in list] [prev in thread] [next in thread]
List: ipng
Subject: Re: Link-local [was Re: draft-ietf-6man-slaac-renum: Processing of PIO Lifetimes at Hosts]
From: Mark Smith <markzzzsmith () gmail ! com>
Date: 2020-09-12 3:23:27
Message-ID: CAO42Z2w6pC1iOWcSY6jXkBCmW4=xhnigRDOvUJQH0KZioSzYbA () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Thu, 10 Sep 2020, 18:19 Nick Hilliard, <nick@foobar.org> wrote:
> on the one hand:
>
> Mark Smith wrote on 09/09/2020 23:13:
> > We should be aim for 1980s IPX and AppleTalk ease of use and operation -
> > and those protocols are where most of IPv6's new features have come from
> > or been inspired by.
>
> and on the other:
>
> > Learn how to troubleshoot IPv6.
>
> > Learn how to operate IPv6.
>
> > Learn how to program IPv6.
>
> > Learn IPv6.
>
> Apart from the mind-boggling disparity between the two positions you're
> suggesting here,
Please don't take my statements and selectively quote them, delete context
and change their order to suit your position and the criticisms you want to
make.
For many things, ease of use usually comes at a cost of complexity. A car
made in 2020 is much easier to use than a car made in 1920. A 2020 car is
also much more complex and requires much more expertise to fix when it
fails. The complexity also means that it fails less often in common
possible failure situations.
The idea and deployment of a "link local" or "this network" network address
is not new at all. It has existed in IPv4 since 1989 (see RFC1122, 3.2.1.3),
in Novell's IPX, likely Xerox XNS as IPX is based on that, and in Apple's
Appletalk.
Nothing in IPv6 is new, IPv6 versions are just generalised or more
efficient versions of what has been done and been done widely before.
I'm pretty disturbed by Philip's email because of two
> things: firstly how inherently complicated ipv6 is,
and secondly this is
> ietf 6man and like Philip, I'll bet that most people in this WG wouldn't
> be able to answer all 4 questions correctly. I know I couldn't.
This poses the question: is 6man an appropriate working group to be
> entrusted with the maintenance of the ivp6 protocol?
>
Nick
>
[Attachment #5 (text/html)]
<div dir="ltr"><div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" \
class="gmail_attr">On Thu, 10 Sep 2020, 18:19 Nick Hilliard, <<a \
href="mailto:nick@foobar.org" rel="noreferrer noreferrer" \
target="_blank">nick@foobar.org</a>> wrote:<br></div><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">on the one hand:<br> <br>
Mark Smith wrote on 09/09/2020 23:13:<br>
> We should be aim for 1980s IPX and AppleTalk ease of use and operation - <br>
> and those protocols are where most of IPv6's new features have come from \
<br> > or been inspired by.<br>
<br>
and on the other:<br>
<br>
> Learn how to troubleshoot IPv6.<br>
<br>
> Learn how to operate IPv6.<br>
<br>
> Learn how to program IPv6.<br>
<br>
> Learn IPv6.<br>
<br>
Apart from the mind-boggling disparity between the two positions you're <br>
suggesting here,</blockquote></div></div><div dir="auto"></div><div \
dir="auto"><br></div><div>Please don't take my statements and selectively quote \
them, delete context and change their order to suit your position and the criticisms \
you want to make.</div><div><br></div><div>For many things, ease of use usually comes \
at a cost of complexity. A car made in 2020 is much easier to use than a car made in \
1920. A 2020 car is also much more complex and requires much more expertise to fix \
when it fails. The complexity also means that it fails less often in common possible \
failure situations.</div><div><br></div><div>The idea and deployment of a "link \
local" or "this network" network address is not new at all. It has \
existed in IPv4 since 1989 (see RFC1122, <span \
style="color:rgb(0,0,0);font-size:13.3333px">3.2.1.3</span>), in Novell's IPX, \
likely Xerox XNS as IPX is based on that, and in Apple's \
Appletalk.</div><div><br></div><div></div><div></div><div>Nothing in IPv6 is new, \
IPv6 versions are just generalised or more efficient versions of what has been done \
and been done widely before.</div><div><br></div><div><br></div><div><br></div><div \
dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 \
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> I'm pretty disturbed by \
Philip's email because of two <br>
things: firstly how inherently complicated ipv6 is, </blockquote></div></div><div \
dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 \
0 .8ex;border-left:1px #ccc solid;padding-left:1ex">and secondly this is <br> ietf \
6man and like Philip, I'll bet that most people in this WG wouldn't <br> be \
able to answer all 4 questions correctly. I know I \
couldn't.</blockquote></div></div><div dir="auto"><div \
class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex">This poses the question: is 6man an \
appropriate working group to be <br> entrusted with the maintenance of the ivp6 \
protocol?<br></blockquote><div><br></div></div></div><div dir="auto"><div \
class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex">Nick<br> \
</blockquote></div></div></div> </div>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic