RE: One size fits all !?! (was: Re: So where have all these new 6man WG people come from?)

["Templin (US), Fred L" <[e-mail]>]

Sounds like another call for IPv8 - we had that same discussion back around
Y2K. It seems in keeping with networking technologies in general that it takes
about two decades for history to repeat itself.

> -----Original Message-----
> From: ipv6 [mailto:[e-mail]] On Behalf Of Toerless Eckert
> Sent: Friday, May 29, 2020 10:13 AM
> To: Ted Lemon <[e-mail]>
> Cc: 6MAN <[e-mail]>
> Subject: One size fits all !?! (was: Re: So where have all these new 6man WG people come from?)
> 
> To me the main issue is that all the discussions about possible
> improvements of IPv6 steering headers (all the options out there)
> do nothing but monopolize precious industry cycles into tactical
> issues instead of also addressing the strategic problems with IPv6
> that go way beyond optimizing steering header encoding.
> 
> IMHO, it is a misguided dogma to think that RFC8200 128 bit
> addresses IPv6 is a one-size-fits-all solution not only for
> what it was built for, the Internet, but also all arbitrary controlled
> networks - for the infinite future!
> 
> IoT with IPv6 is an extreme pain (header compression, MTU).
> Most controlled networks do not even want global addresses (security,
> segment based app-gateway architectures, ...).
> 16-bit/32-bit/48-bit address sizes would be highly desirable.
> Even the 1980'th CLNP network protocol had variable sized addresses.
> IPv6 has not solved core problems to be even equal to L2 switching:
> plug routers together, get automatic connectivity, no bother about addresses.
> CLNP was a lot closer to that goal too.
> 
> We have no "maintenance-only" constraint in IETF multicast,
> yet for unicast network layer we only permit maintenance or
> else you need to create another WG for just a sub-problem.
> How silly of a structure is that ?  And please do not create
> an IPv6.00001 working group, but think really about another
> instance of IPv6-NG, but this time backward compatible.
> 
> And do not let a vendor force the hand of the IETF by developing
> and deploying proprietary solutions first. We know how bad that works from
> ongoing work in other layers, as well as historic examples.
> 
> If we continue to proliferate this "one-size-fits-all" myth,
> then we are just continuing to extend our own version of
> a winchester mystery house and kill our industry.
> 
> On Fri, May 29, 2020 at 10:30:01AM -0400, Ted Lemon wrote:
> > On May 29, 2020, at 10:17 AM, Stewart Bryant <[e-mail]> wrote:
> > > My main point was that a list discussion of this type rarely reaches an acceptable outcome, and that an objective discussion at IETF
> is normally a better approach. Indeed resolving issues like this is exactly why we meet F2F at IETF.
> >
> > My experience with this is more that working group chairs are quite active in moderating discussions during in-person meetings, and
> really tend not to take responsibility for doing that on the mailing list. This produces the effect you???ve observed, that it???s easier
> to get consensus in-person than on the list.
> >
> > This is unfortunate; if the chairs took a more active role on the list, considering the cost of the time it takes for participants with
> coding jobs to follow multi-hundred-post repetitive arguments, we would probably do a better job of reaching consensus on-list.
> >
> > Of course, this is a lot of work, and it???s sort of understandable that it doesn???t happen; my point is simply that if we want to be
> an effective _online_ organization, maybe we need to start doing things a bit differently.
> >
> 
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> 
> 
> --
> ---
> [e-mail]
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------