Resumen

  • RFC 873 discutió la propuesta de esperar protocolos de red basados en el modelo ISO y suministrados por fabricantes para las compras del Departamento de Defensa estadounidense.
  • Su objeción técnica era concreta: una suite inacabada y funciones opcionales permitían productos hechos de buena fe que necesitarían trabajo pagado para comunicarse entre sí.

Un sello de «soporte del fabricante» tranquiliza a quien firma el contrato. A un paquete no le impresiona el sello; necesita que los dos extremos hayan acordado cómo se comportan. Michael A. Padlipsky hizo de esa diferencia el centro de RFC 873, publicado en septiembre de 1982. En el Departamento de Defensa de Estados Unidos había voces que querían dejar atrás protocolos concebidos en el entorno ARPANET y esperar una suite apoyada por proveedores y asociada al modelo de referencia ISO. La promesa era ahorrar dinero público. Padlipsky tomó la promesa como un presupuesto por desglosar.

La primera línea decía «suite», pero ¿de qué piezas constaba? El autor observó que X.25 cubría parte de la comunicación y no ofrecía por sí solo todo lo necesario para compartir recursos entre ordenadores. Añadir otros mecanismos de acceso y dirección tampoco equivalía a una suite acabada. El National Bureau of Standards y la ISO trabajaban en conjuntos relacionados, aunque diferentes. Poner un solo nombre elegante en una licitación no resolvía qué se entregaría en cada capa ni qué harían juntos los sistemas comprados por separado.

La segunda línea era el tiempo. Las compras de defensa tenían plazos largos y, según el ensayo, la suite relacionada con el modelo ISO seguía incompleta en 1982. Algunas propuestas apenas habían pasado por el uso real, mientras el proceso de estandarización necesitaba años. Al mismo tiempo se estaban adjudicando contratos de redes. Había implementaciones de los protocolos de la familia ARPANET en sistemas operativos ya utilizados por el departamento. Mantenerlas costaba trabajo; esperar un conjunto aún por cerrar también costaba meses o años de decisión. Padlipsky se negó a dejar que el verbo «esperar» apareciera gratis en la cuenta.

«Soporte» era la tercera línea. Un vendedor podía comprometerse a mantener su código y, aun así, no saber si otro producto interpretaría igual las interfaces entre capas, el paso por cada capa o el número de protocolos admisibles en ella. El RFC enumeró dudas de ese tipo. Las especificaciones podían permitir varias lecturas razonables y la interoperabilidad aparecer solo después de que alguien detectara y corrigiera el desacuerdo. Comprar dos productos con papeles correctos no garantizaba una conversación correcta.

Las funciones opcionales eran el caso más limpio. La implementación de un proveedor podía contar con una función que otro, legítimamente, había decidido omitir. Ambas decisiones podían respetar su documentación. En la instalación del comprador surgía una incompatibilidad que había que resolver con configuración, software o un nuevo encargo de ingeniería. Padlipsky preguntó a quién se le enviaría la factura. Sospechaba que las empresas no competirían por pagarla. La palabra «opcional» había movido una decisión desde la mesa del diseñador común hasta el cruce entre dos clientes.

Había también una factura en tiempo de procesador y memoria. Los protocolos se instalaban en máquinas cuyos ciclos y espacio tenían valor. El ensayo criticó reglas de capas que podían obligar a recorridos innecesarios y aumentar el estado que procesaba cada host. Padlipsky contó un episodio de sondas de control repetidas cuyo coste operativo resultó llamativo. El episodio servía para exigir mediciones de consumo antes de comprar; no convertía toda implementación futura en culpable del mismo gasto. Una prueba de uso debía acompañar a la promesa de cumplimiento.

El autor escribía con ironía, pero su argumento no necesitaba villanos. Bastaba con observar que un fabricante podía recibir incentivos distintos de los de los programadores que buscaban conservar CPU y memoria en hosts compartidos. Su conclusión acudía al almuerzo que nunca es gratis: el precio de compra, el mantenimiento, la adaptación entre productos y los recursos consumidos por el software son cuentas separadas. También señaló que cada vez más proveedores ofrecían o preparaban TCP/IP. El mercado real empezaba a mezclar las dos opciones que el debate presentaba como bandos.

RFC 873 permite oír una discusión de compras mientras aún estaba abierta. Su valor está en la pregunta que dejó sobre la mesa en 1982: ¿qué suite completa puede entregarse hoy, qué partes siguen en papel, qué opciones comparten los productos y quién asume el desacuerdo? El proveedor puede prometer atención. La máquina del otro extremo sigue pidiendo una regla que ambos puedan ejecutar.