[LACNIC/Seguridad] Moviendo IPv6 a full Standard (Fwd: Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet Protocol, Version 6 (IPv6) Specification) to Internet Standard)

Fernando Gont fgont en si6networks.com
Vie Feb 10 17:24:48 BRST 2017


Como les comente tiempo atrás, estamos moviendo el protocolo IPv6 a
(full) Standard.

También les comenté que me había quedado con cierta sensación :-) que
algunas decisiones habían sido influenciadas por algun que otro gran
fabricante con $$ invertido en tecnologia que hace "inserción" de IPv6
etension headers (insertar encabezados de extension en los paquetes, en
medio de la red).

Debajo la opinion de Jinmei, quien trabajó en la implementacion de IPv6
"KAME" (la de los BSDs).

P.S.: Aquellos que hablan de procedimientos abiertos, y demás, peguenle
un vistazo, lean entre lineas, y saquen sus conclusiones.


-------- Forwarded Message --------
Subject: Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet
Protocol, Version 6 (IPv6) Specification) to Internet Standard
Date: Fri, 10 Feb 2017 10:22:52 -0800
From: 神明達哉 <jinmei en wide.ad.jp>
To: Fernando Gont <fgont en si6networks.com>
CC: Ole Troan <otroan en employees.org>, 6man en ietf.org <6man en ietf.org>,
IETF Discussion <ietf en ietf.org>, Pete Resnick
<presnick en qti.qualcomm.com>, draft-ietf-6man-rfc2460bis en tools.ietf.org,
6man-chairs en ietf.org

At Thu, 9 Feb 2017 18:30:11 -0300,
Fernando Gont <fgont en si6networks.com> wrote:

While I largely agree with Fernando on everything he said, I have to
admit most of the points are just repeated from the 6man discussion,
and won't get us anywhere new by discussing these again at this point.
I guess the only new input for the IETF last call is this:

> 2) However, some folks came up with proposals to insert EH, on the basis
> that "RFC2460 does not explicitly ban EH insertion". If there's people
> arguing that, we clearly need to make this clear in the spec.
> 3) There was a consensus call, yes. When the call was made on the
> mailing-list, the vast majority of supporters of "let's keep the
> ambiguity" were folks from the same company as "2)". I have no idea if
> this changes (or not) "consensus"... but this is clearly an important
> datapoint.

Although I don't want to point a finger at particular people or
organizations without an evidence, I guess not a small number of 6man
participants (not only those who explicitly spoke up here) suspected
that the decision process was biased with the influence of a large and
powerful organization and the process and resulting "consensus" was
not really a fair one.  And I'm not an exception to it - in fact, it
was so unbelievable to me that we can't clarify an ambiguity even when
we were also open for future extensions, that I couldn't think of
other reasons than a company agenda.

Of course, it's quite possible that it was just a coincidence that
many people with the same organization genuinely thought we should
leave it ambiguous while many others strongly thought we should
clarify it but few (if not no) people from that organization supported
the clarification.  But I don't think we can prove it either way.

But as Fernando said, I believe this point (and that several, and
arguably more, participants suspected it) should be included in making
the decision at the IESG and at the IETF last call.  And, whatever the
decision, it would be more productive to move on after that and use
our time for some other things.

I'll shut up here on this so I won't be a cause of another 600+ email

JINMEI, Tatuya

Más información sobre la lista de distribución Seguridad