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

[Azael Fernandez Alcantara]

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
>