[Ietf-lac] [LAC-TF] [LACNIC/Seguridad] Fwd: [sunset4] Declaring IPv4 Historic

Thu Mar 17 17:02:51 BRT 2016

I appreciate the comments from everyone, and of course I look forward to
good discussion in Buenos Aires.

Support, opposition, or especially suggestions are welcome and encouraged
on the sunset4 mailing list. https://www.ietf.org/mailman/listinfo/sunset4

Lee

On 3/17/16, 1:38 PM, "Ietf-lac on behalf of Azael Fernandez Alcantara"
<ietf-lac-bounces at lacnog.org on behalf of afaza at unam.mx> wrote:

>Buen Dia,
>
>Tratando de seguir, en el tiempo que he tenido, los comentarios y
>posturas
>sobre este tema que ha "elevado pasiones" "sentimientos" , etc.
>
>Recomiendo llevar esta discusion a la lista de ietf-lac, y formar un
>grupo
>de personas que trabajen en una version, mejora y propuestas para el
>draft
>que ha originado este intenso debate.
>Con argumentos a favor, en contra e intermedios.
>
>Y dado que la reunion IETF95 sera en Buenos Aires, seguramente varias
>personas de este grupo podran participar en la presentacion del WG
>sunset4 que esta' para el:
>
>Martes 5 de abril, de 17:40-19:10.
>https://datatracker.ietf.org/meeting/95/agenda/sunset4
>
>O participar en un Hub-Remoto.
>
>Por lo que para esta fecha, se podra llevar una 1er. postura.
>
>No creo que tengamos tiempo para darle un espacio en el proximo FLIP6,
>pero mientras madura el draft, transcurre la sig. reunion de la IETF,
>podria buscarse un espacio en sig. reuniones.
>
>
>SALUDOS
>_______
>Azael
>____________________________
>Mensaje enviado sin acentos
>
>On Thu, 17 Mar 2016, Fernando Gont wrote:
>
>> On 03/17/2016 11:04 AM, Programa STIC wrote:
>>> Para discutir esto seriamente seria necesario acordar algún criterio de
>>> evaluación de lo que consideramos "madurez técnica".
>>>
>>> Como se mide la madurez técnica? Es algo completamente subjetivo?
>>
>> El RFC6410 dice:
>>
>> 2.2.  The Second Maturity Level: Internet Standard
>>
>>   This maturity level is a merger of Draft Standard and Standard as
>>   specified in RFC 2026 [1].  The chosen name avoids confusion between
>>   "Draft Standard" and "Internet-Draft".
>>
>>   The characterization of an Internet Standard remains as described in
>>   RFC 2026 [1], which says:
>>
>>      An Internet Standard is characterized by a high degree of
>>      technical maturity and by a generally held belief that the
>>      specified protocol or service provides significant benefit to the
>>      Internet community.
>>
>> [fgont] Alguno podría argumentar que "generally held belief..." no es
>> muy cientifico que digamos.
>>
>>
>> [fgont] Pero aca se es un poco mas peciso:
>>
>>   The IESG, in an IETF-wide Last Call of at least four weeks, confirms
>>   that a document advances from Proposed Standard to Internet Standard.
>>   The request for reclassification is sent to the IESG along with an
>>   explanation of how the criteria have been met.  The criteria are:
>>
>>   (1) There are at least two independent interoperating implementations
>>       with widespread deployment and successful operational experience.
>>
>>   (2) There are no errata against the specification that would cause a
>>       new implementation to fail to interoperate with deployed ones.
>>
>>   (3) There are no unused features in the specification that greatly
>>       increase implementation complexity.
>>
>>   (4) If the technology required to implement the specification
>>       requires patented or otherwise controlled technology, then the
>>       set of implementations must demonstrate at least two independent,
>>       separate and successful uses of the licensing process.
>>
>> Apliquemos estos items a v6:
>>
>> (1) Depende de que hablemos. Los EHs, por ejemplo no tienen "sucessful
>> operational experience" en el mundo real. Mas bien, la experiencia es
>> que no funcionan.
>>
>> (2) Aca habla de erratas. Pero cosas como po ej RFC7112 pueden, en
>> teoria, hacer que dos implementaciones no interoperen.
>>
>> (3) Mucho de lo relacionado con los EH es complejidad que no se utiliza
>> para nada práctico.
>>
>> (4) No hay problemas en este item.
>>
>>
>> Creo igual que la definicion es algo pobre. Por un lado, omite
>> completamente que sucede con los documentos que "updatean" la spec en
>> cuestion (habla de los errata, pero no de los RFCs que updatean a aquel
>> del que estamos hablando. Por otro lado, se habla solo de
>> interoperabilidad y no de seguridad. Mientras que los updates no causen
>> problemas de interoperabilidad, esta todo bien. Pero un update puede
>> atacar problemas de seguridad, sin que ello implique cuestiones de
>> interoperabilidad. Por ejemplo, RFC2460 sugiere un contador global para
>> el Frag ID.. se puede considerar madura una spec que rcomienda algo con
>> implicancias de seguridad bien conocidas?
>>
>> Dicho de otro modo: si a una spec no se le encontraron cuestiones que
>> afecten la interoperabilidad, pero desde un punto de vista de seguridad
>> es como un queso gruyere... se puede decir que es madura? El texto de
>> arriba omite completamente este punto.
>>
>>
>> En lo personal, asocio madurez con estabilidad. Si hasta el dia de ayer
>> (figurativamente) estuviste arreglando problemas, creo que es dificil
>> afirmar que algo es estable o que es maduro, en particular si los
>> cambios tienen que ver con cosas bastante fundamentales en materia de
>> diseño (pero si, esto asi definido es subjetivo).
>>
>> Aca estamos hablando de un protocolo de red, algo super simple... y fue
>> necesario toquetear casi todo menos salvo el Hop Limit/TTL.
>>
>>
>> --
>> Fernando Gont
>> SI6 Networks
>> e-mail: fgont at si6networks.com
>> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>>
>>
>>
>>
>> _______________________________________________
>> LACTF mailing list
>> LACTF at lacnic.net
>> https://mail.lacnic.net/mailman/listinfo/lactf
>> Cancelar suscripcion: lactf-unsubscribe at lacnic.net

________________________________

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.