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

[Fernando Gont]

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