Summary

  • RFC 5237 retiró Expert Review para solicitudes amparadas por acuerdos de confidencialidad. Conservó IESG Approval y Standards Action, pero con especificaciones públicas que pudieran examinarse.
  • La asignación evita colisiones de significado. No demuestra software, interoperabilidad, seguridad, despliegue ni uso. La revisión pública justifica consumir el identificador; no certifica el resultado posterior.

La excepción se propagaba a quienes no firmaron el acuerdo

RFC 2780 permitía asignar valores de IPv4 Protocol mediante Expert Review, IESG Approval o Standards Action. La primera opción se reservaba a casos especiales con información no divulgada y un experto designado por el IESG.

El solicitante podía así proteger una investigación o un producto futuro. Pero la reserva no quedaba encerrada en la relación confidencial. Todos los fabricantes de pilas, analizadores, filtros y herramientas de diagnóstico debían reconocer que la casilla estaba ocupada.

Esos terceros no habían firmado el acuerdo ni podían evaluar el propósito. Aun así, heredaban el deber de evitar la colisión y mantener una excepción cuyo fundamento permanecía oculto.

RFC 5237 decidió que ese reparto ya no era razonable. La organización podía conservar el secreto; no podía convertirlo en una reserva opaca y permanente dentro de este campo limitado.

Doscientos cincuenta y seis lugares cambian la economía

El campo tiene 256 valores. El documento afirmó que el 55 % estaba en uso cuando se publicó en 2008. No es un dato de ocupación actual, sino la fotografía histórica que motivó un control de necesidad.

Ese control puede preguntar si existe una especificación estable, si hay una comunidad que quiera usar el protocolo, si la solicitud duplica una función y si un número IP es realmente el límite correcto. Quizá un puerto TCP o UDP resuelva el problema sin consumir otra posición del campo.

Standards Action siguió sirviendo al desarrollo de estándares. IESG Approval siguió disponible para usos no IETF o no Standards Track con una justificación suficiente. La política no cerró el registro; retiró la posibilidad de llenarlo con razones que el público técnico no podía ver.

Una especificación pública no es un sello IETF

Hacer visible una especificación permite contrastar el diseño, localizar duplicaciones y examinar la capa elegida. No convierte automáticamente la propuesta en estándar. La ruta de IESG Approval conserva precisamente asignaciones que pueden ser legítimas sin Standards Action.

Tampoco resuelve por sí sola licencias, patentes o propiedad. La exigencia se limita a la evidencia necesaria para coordinar el número. Lo que da significado a la casilla debe ser inspeccionable; otros detalles comerciales pueden tener un régimen distinto.

Por eso deben separarse el documento, la decisión y la ejecución. Un texto público describe una intención. La aprobación autoriza el uso del identificador. El registro conserva la asociación. Ninguno de los tres prueba que exista código interoperable.

IANA conserva la fila, no fabrica el protocolo

La tabla Protocol Numbers de IANA es el registro autoritativo de asignaciones y referencias. IANA administra las reglas publicadas; una fila no significa que haya creado el protocolo, validado su mercado o auditado su seguridad.

La separación evita dos errores. El administrador no se convierte en dueño del espacio por mantenerlo. El asignatario tampoco obtiene una garantía técnica por aparecer en la tabla.

Un número registrado no prueba implementación, despliegue, volumen de tráfico ni efecto operativo. Sólo demuestra que, bajo la política y referencias correspondientes, ese valor tiene un significado coordinado.

La salida experimental conserva la incertidumbre

RFC 4727 reservó los valores 253 y 254 para experimentación. Un equipo puede probar una idea sin reclamar inmediatamente una semántica permanente y exclusiva.

Los valores experimentales no son una red privada perfecta. Dos pruebas pueden interferir y los equipos intermedios pueden bloquearlas o tratarlas de modo especial. Precisamente por eso no deben presentarse como despliegue global.

El orden correcto es útil: experimentar donde la ambigüedad está declarada, publicar evidencia estable y solicitar una asignación permanente sólo cuando el coste común esté justificado.

El límite del precedente

RFC 5237 dice expresamente que no adopta una posición sobre acuerdos de confidencialidad en otros espacios de parámetros. Cada registro tiene tamaño, estructura y coste de colisión distintos. La regla concreta pertenece a IPv4 Protocol y, por la referencia de RFC 2780, a IPv6 Next Header.

La lección general es de incentivos. La confidencialidad beneficia al solicitante; el agotamiento del espacio afecta a todos. Una política legítima no debe ocultar ese traslado de costes.

RFC 8126 modernizó después el vocabulario de las políticas de asignación. Ayuda a entender los mecanismos actuales, pero no sustituye el acto histórico: RFC 5237, BCP 37 de febrero de 2008, eliminó una opción específica.

No ascender la asignación a realidad operativa

La secuencia de evidencia incluye recepción de la propuesta, publicación de una versión revisable, decisión por una vía autorizada, registro, implementación, pruebas entre implementaciones, despliegue y observación de uso.

Cada eslabón responde a una pregunta diferente. La publicación no garantiza un buen diseño. La asignación no produce software. El software no garantiza interoperabilidad. Un despliegue no demuestra el impacto anunciado.

La prioridad que Lu Heng da a la realidad operativa exige mantener esas fronteras. La transparencia mejora la decisión, pero no sustituye el código en marcha. El número es un recibo de coordinación, no una certificación de rendimiento.

Sources

Additional standards record

  1. Texto plano de RFC 5237
  2. Ficha de RFC 5237
  3. RFC 5237 en Datatracker
  4. Historial de RFC 5237
  5. Erratas de RFC 5237
  6. Documentos que citan RFC 5237