<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<div id="compose-container" itemscope="" itemtype="https://schema.org/EmailMessage">
<span itemprop="creator" itemscope="" itemtype="https://schema.org/Organization"><span itemprop="name" content="Outlook Mobile for iOS"></span></span>
<div>
<div>Felicitaciones Fernando !!! por tu aporte y trabajo constante que deja huella plasmada en RFCs y es digno de resaltar.</div>
<div><br>
</div>
<div>Rafael Sandoval</div>
<div><br>
</div>
<div><br>
<div class="acompli_signature">Get <a href="https://aka.ms/o0ukef">Outlook for iOS</a></div>
<br>
</div>
</div>
</div>
<br>
<br>
<br>
<div class="gmail_quote">On Wed, Feb 22, 2017 at 9:28 PM -0500, "Fernando Gont" <span dir="ltr">
<<a href="mailto:fgont@si6networks.com" target="_blank">fgont@si6networks.com</a>></span> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="3D"ltr"">
<pre>(por si hace falta la aclaración, hubo un error te tipeo en el Subject :-) )
On 02/22/2017 10:39 PM, Fernando Gont wrote:
> Estimados,
>
> Se acaba de publicar el RFC8064
> (<http: www.rfc-editor.orgrfcrfc8064.txt="">), del cual soy co-autor.
> Este RFC basicamente recomienda la implementacion y utilización de
> RFC7217 (<http: www.rfc-editor.orgrfcrfc7217.txt="">), del cual soy
> autor, para la generación de direcciones con SLAAC.
>
> Este documento actualiza 14 estandares, incluyendo la Arquitectura de
> Direccionamiento de IPv6.
>
> Debajo les dejo una especie de "rant"/descripción/explicación en formato
> de preguntas y respuestas.
>
>
> *** FAQs ***
>
> 1) ¿Que hace este RFC?
>
> Este documento recomienda el RFC7217 (de mi autoria) para generar
> direcciones mediante SLAAC. El uso de direcciones utiizando ahora
> "Modified EUI-64 forma identifiers" (embeber la direccion MAC en el
> identificador de interfaz) es ahora *no recomendada*
>
> Este RFC, basicamente, hace lo que propuse unilateralmente hace mas de 5
> años atras, en este documento:
> <https: www.ietf.org="" archive="" id="" draft-gont-6man-stable-privacy-addresses-00.txt="">.
>
>
> 2) ¿Existen implementaciones de RFC7217?
>
> Si, claro. RFC7217 ha sido implementado en linux kernel desde la version
> 4.0. Tambien en Network Manager v1.0.4, y dhcpd desde alguna version que
> no recuerdo.
>
> Sistemas operativos como Fedora 24 y Mac OS (desconozco la version
> especifica) utilizan por defecto el RFC7217.
>
> Dependiendo de cada sistema operativo en particular, podría ocurrir que
> al actualizarlo, las direcciones IPv6 correspondientes cambien (lease:
> que pases de usar las direcciones SLAAC tradicionales, a usar RFC7217)
>
>
> 3) ¿Como es que todo esto (reemplazar a las direcciones SLAAC
> tradicionales) tardó tanto tiempo?
>
> Porque los grandes vendors tienen demasiada influencia en los procesos
> de IETF.
>
> La propuesta original antes mencionada hacia, en un solo documento, lo
> que IETF decidio hacer en 3 (RFC7217, RFC7721, y RFC8064).
> Originalmente, se opusieron a que RFC7217 reemplace las direcciones
> SLAAC tradicionales, y solo permitieron que se publicara una
> especificacion (RFC7217) proponiendo un esquema alternativo, pero sin
> actualizar formalmente ningun estandar.
>
> Durante todo el proceso, fabricantes de dispositivos moviles se
> opusieron a la idea, ya que segun ellos "por que habria el usuatio de
> querer privacidad?" y "la privacidad deberia ser un opt-in, no un
> opt-out". Luego intentaron afectar la publicacion de RFC7217 de todas
> las formas posibles...desde sugerir que habian patentes de Microsoft
> sobre el mismo, hasta sugerir la publicacion del documento como
> "Informational" en vez de como Standards Track durante la revisión de IESG.
>
> La publicación de RFC7217 como estandar fue casi un milagro.
>
>
> 4) Entiendo que la unica substancia del RFC8064 está en recomendar
> RFC7217. Tengo entendido que en su momento se te sugirió incorporar
> co-autores de algunos grandes vendors al RFC7217, sugieriendo que el
> proceso de publicacion "sería mas facil". ¿Por que no lo hiciste?
>
> Porque Diego Maradona me enseño que "la pelota no se mancha"
> (<https: www.youtube.comwatch?v="1YhNGEA8wzo">), y que no hay que
> permitir que "le tmen la leche al gato".
>
>
>
> 5) Durante el proceso de publicación del RFC8064, vi que fue
> principalmente el primer co-autor el que uso energía en el mismo.
>
> Esto no es así. Mi co-autora, y chair electa de IETF, se encargo de que
> la calidad de los "Acknowledgements" del RFC estén al nivel que IETF
> merece (<https: goo.gl1a3hya="">). Pueden encontrar mas información en:
> <https: goo.gloqtkta="">
>
>
> 6) ¿Es cierto que hubo gente de Cisco que se opuso a la idea de este
> documento?
>
> Si. No querían tener que trabajar en modificar el codigo de sus routers.
>
>
> 7) ¿Es cierto que gente de Google sigue defendiendo el esquema de
> embeber direcciones MAC en los identificadores de Interfaz IPv6?
>
> Si. Aunque es de notar que no es la unica idea descabellada que tienen.
>
>
> 8) El RFC8064 actualiza 14 estandares. Viendo RFCs de tu autoria
> (<https: goo.glsgaufg="">), veo que has hecho actualizaciones a una gran
> cantidad de RFCs de IPv6, incluyendo el propio RFC2460. ¿Que opinion
> tenes respecto de los estandares de IPv6, y de sus implementaciones?
>
> Creo que tienen, a lo sumo, la misma madurez que las implementaciones de
> IPv4 de principios de los años '90.
>
>
> 9) Lei por ahi que Latinoamerica tiene un dream team en IETF. Que opinás?
>
> En el mejor de los casos, uno solo podria ver tal aseveración como un
> exceso de optimismo.
>
> Personalmente, creo que Latinoamerica no tiene un dream team. Es mas,
> creo que no tiene ni "team", ni tampoco "dreams".
>
>
> 10) ¿Hay alguien a quien agradecer respecto a tu trabajo en IETF0
>
> Si. Los que el 6man wg decidio sacar de los "Acknowledgements":
>
> Fernando Gont would like to thank Nelida Garcia and Guillermo Daniel
> Gont for their love and support, and Jorge Oscar Gont and Diego
> Armando Maradona for their inspiration.
>
> Asimismo, a Iván Arce (a quien ya habia agredecido en RFC8021).
>
>
> 11) Algunos de tus RFCs agradecen a Diego Maradona. ¿No es esto una
> muestra de inmadurez, poca cultura, o similares?
>
> Esta pregunta lo es. Si has estudiado minimamente la vida de Maradona
> (de donde vino, lo que hizo, en que contexto lo hizo, y a que cosas se
> enfrento), el crédito no merece demasiada explicación.
>
>
> 12) ¿Que se podría hacer para mejorar el nivel de participación de IETF
> en la región?
>
> Si quienes fomentan la participación latinoamericana en IETF hicieran un
> 50% de lo que Ivan Arce, y tuvieran un 50% de sus agallas para llamar a
> las cosas por su nombre, las condiciones de participación de
> latinoamerica serian mejores... o al menos tendriamos un mejor y mas
> honesto punto de partida.
>
> El hecho de que las estrategias para mejoras en participación
> latinoamericana se discuten en hoteles estilo Hilton de lugares como
> Tokio y Seul (lease, lejos de la región), con discusiones dominadas por
> personas que no viven en la región ni tienen conocimiento directo sobre
> lo que es participar en IETF desde latinomaerica, te puede dar una pauta
> de las expectativas que se pueden tener respecto del fruto de dichas
> reuniones.
>
> Estaría genial que alguien, alguna vez, le pregunte a alguien que
> escriba RFCs para la región cuales son las trabas que ha encontrado o
> encuentra para la participación en IETF. En lo personal, soy autor de
> mas el 80% de los RFCs de la región, y me he cansado de ver esoterismo y
> teorias varias a la hora de fomentar la participacion latinoamericana en
> la región -- teorias que cualquiera que haya participado desde la región
> (o lo haya hecho sin ser parte de alguno de los dueños del kiosko) puede
> darse cuenta que son equivocadas.
>
> Jamas se han discutido en la región ninguno de los problemas de fondo
> que afectan a la participación latinoamericana en IETF. Tal vez, porque
> se pretende que se mejore la situación de latinoamerica sin afectar el
> status quo de quienes tradicionalmente han dominado IETF. Algo imposible.
>
> Saludos cordiales,
> Fernando Gont
> (<https: goo.gl2ab2kl="">)
>
>
>
>
> -------- Forwarded Message --------
> Subject: RFC 8064 on Recommendation on Stable IPv6 Interface Identifiers
> Date: Wed, 22 Feb 2017 14:56:37 -0800 (PST)
> From: rfc-editor@rfc-editor.org
> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
> CC: drafts-update-ref@iana.org, ipv6@ietf.org, rfc-editor@rfc-editor.org
>
> A new Request for Comments is now available in online RFC libraries.
>
> RFC 8064
>
> Title: Recommendation on Stable IPv6 Interface
> Identifiers Author: F. Gont, A. Cooper,
> D. Thaler, W. Liu
> Status: Standards Track
> Stream: IETF
> Date: February 2017
> Mailbox: fgont@si6networks.com,
> alcoop@cisco.com, dthaler@microsoft.com,
> liushucheng@huawei.com
> Pages: 9
> Characters: 19179
> Updates: RFC 2464, RFC 2467, RFC 2470, RFC 2491,
> RFC 2492, RFC 2497, RFC 2590, RFC 3146, RFC
> 3572, RFC 4291, RFC 4338, RFC 4391, RFC 5072, RFC 5121
>
> I-D Tag: draft-ietf-6man-default-iids-16.txt
>
> URL: https://www.rfc-editor.org/info/rfc8064
>
> DOI: 10.17487/RFC8064
>
> This document changes the recommended default Interface Identifier
> (IID) generation scheme for cases where Stateless Address
> Autoconfiguration (SLAAC) is used to generate a stable IPv6 address.
> It recommends using the mechanism specified in RFC 7217 in such
> cases, and recommends against embedding stable link-layer addresses
> in IPv6 IIDs. It formally updates RFC 2464, RFC 2467, RFC 2470, RFC
> 2491, RFC 2492, RFC 2497, RFC 2590, RFC 3146, RFC 3572, RFC 4291, RFC
> 4338, RFC 4391, RFC 5072, and RFC 5121. This document does not
> change any existing recommendations concerning the use of temporary
> addresses as specified in RFC 4941.
>
> This document is a product of the IPv6 Maintenance Working Group of the
> IETF.
>
> This is now a Proposed Standard.
>
> STANDARDS TRACK: This document specifies an Internet Standards Track
> protocol for the Internet community, and requests discussion and suggestions
> for improvements. Please refer to the current edition of the Official
> Internet Protocol Standards (https://www.rfc-editor.org/standards) for
> the standardization state and status of this protocol. Distribution of
> this memo is unlimited.
>
> This announcement is sent to the IETF-Announce and rfc-dist lists.
> To subscribe or unsubscribe, see
> https://www.ietf.org/mailman/listinfo/ietf-announce
> https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
>
> For searching the RFC series, see https://www.rfc-editor.org/search
> For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk
>
> Requests for special distribution should be addressed to either the
> author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless
> specifically noted otherwise on the RFC itself, all RFCs are for
> unlimited distribution.
>
>
> The RFC Editor Team
> Association Management Solutions, LLC
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
--
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
_______________________________________________
LACTF mailing list
LACTF@lacnic.net
https://mail.lacnic.net/mailman/listinfo/lactf
Cancelar suscripcion: lactf-unsubscribe@lacnic.net
</https:></https:></https:></https:></https:></https:></http:></http:></pre>
</div>
</blockquote>
</div>
</body>
</html>