Summary

  • El formato co_repair de RFC 5225 protege con CRC-7 toda la cadena de encabezados sin comprimir reconstruida y usa, aparte, un CRC-3 para los campos de control aplicables. Esos campos pueden no haber intervenido en la descompresión que acaba de funcionar.
  • Aceptar el resultado actual, avanzar el estado persistente y emitir retroalimentación positiva son decisiones distintas. Cada una necesita evidencia cuyo alcance incluya exactamente aquello que autoriza.

La operación terminó bien, pero dejó una pregunta abierta

El descompresor recibió el paquete, reconstruyó el encabezado y verificó su CRC-7. Si el registro operativo termina ahí, la transacción aparece completa. Sin embargo, el mismo paquete puede transportar campos que actualizan el contexto con el que se interpretarán mensajes posteriores.

Por eso co_repair incluye también control_crc3_encoding. El CRC-7 se calcula sobre toda la cadena de encabezados reconstruida. El CRC de control de tres bits se calcula sobre la concatenación de los campos de control aplicables. No son dos niveles de confianza sobre el mismo objeto; responden a preguntas diferentes.

RFC 5225 explica que los campos actualizados no siempre se usan para descomprimir el encabezado que los lleva y, por tanto, pueden quedar fuera del CRC-7. Sin el control separado, la descompresión puede tener éxito, puede salir una respuesta positiva y, aun así, los campos de control pueden quedar mal actualizados.

El contexto convierte una victoria presente en una obligación futura

ROHC ahorra ancho de banda porque emisor y receptor mantienen contexto compartido. Lo omitido en cada paquete no desaparece: se traslada a la confianza depositada en ese estado. Una modificación incorrecta puede no afectar al resultado visible de hoy, pero sí a la interpretación de mañana.

La máquina de estados mantiene esa incertidumbre. En Repair Context ya hubo paquetes descomprimidos con éxito, aunque el receptor aún no confía en todo el contexto. Una verificación CRC-7 o CRC-8 conforme a la especificación puede devolverlo a Full Context. Un paquete atrasado en la secuencia puede descomprimirse sin actualizar estado y puede quedarse sin ACK. La detección del daño de contexto depende de la implementación.

Así, «funcionó» no tiene una única consecuencia. Hay que registrar qué salió bien, qué cambió y qué confianza fue razonable conceder después.

Ninguna comprobación habla de todo

El dato «CRC correcto» carece de valor de gobierno si no incluye su objeto. En co_repair, el CRC-7 habla del encabezado reconstruido; el CRC-3 habla de los campos de control aplicables. Ninguno es una firma criptográfica ni prueba procedencia, entrega a la aplicación, calidad de servicio o corrección de un producto concreto.

El recibo debe nombrar el material comprobado, el estado anterior, los campos propuestos, el cálculo utilizado, el resultado y la acción permitida. De otro modo, una luz verde se convierte en una autorización genérica que el diseño nunca concedió.

El fallo más costoso hereda una etiqueta de éxito

Cuando la salida actual es incorrecta, el síntoma suele quedar cerca de la causa. Cuando la salida es correcta y la transición de estado es la equivocada, el fallo aparece más tarde. Para entonces, la retroalimentación positiva puede haber llevado a ambos extremos a continuar desde la misma premisa falsa.

La investigación mira el último paquete, no la transacción anterior archivada como exitosa. Los detalles pueden haberse eliminado, los reintentos pueden ampliar la divergencia y la reversión de código puede conservar el estado derivado por la versión retirada.

No basta con detectar errores; hay que preservar la causalidad. El sistema debe poder mostrar qué evidencia permitió usar la salida y qué evidencia diferente permitió modificar el estado.

Dividir una decisión que parecía indivisible

Toda operación con salida visible y estado oculto debería permitir tres respuestas independientes: aceptar o no el resultado, avanzar o aislar el estado, y enviar o no confirmación positiva. El resultado puede ser útil mientras se rechaza una actualización de aprendizaje, caché, política o control. Una transición interna coherente tampoco demuestra que el usuario recibió el efecto esperado.

Un solo bit de éxito facilita la automatización, pero mezcla responsabilidades. Separar las decisiones permite que la evidencia limitada siga siendo útil sin convertirla en una garantía total.

Límites de la evidencia

RFC 5225 no acusa a ningún terminal, módem, red móvil, fabricante ni implementación. No aporta cuota de despliegue actual, incidente, traza real ni resultado de calidad. El registro de perfiles de IANA demuestra que existen identificadores, no que estén desplegados.

La existencia del segundo control tampoco demuestra que cada paquete de reparación lleve un error. Demuestra que el primer control no incluye el mismo objeto. Una salvaguarda diseñada y un accidente observado pertenecen a categorías probatorias distintas.

Conservar un recibo doble

El recibo de salida registra entrada, reconstrucción, alcance exacto de validación, resultado y frontera de entrega. El recibo de transición registra identidad del estado previo, campos propuestos, control independiente, mutación aceptada o rechazada, retroalimentación enviada, identidad del estado resultante y principal que autorizó continuar.

También conserva salidas correctas con actualización rechazada, actualizaciones válidas sin entrega confirmada, entradas tardías que no avanzaron estado, ACK retenidos, reparación solicitada y contexto restablecido. Esas excepciones son el mapa de dónde termina la afirmación de éxito.

La perspectiva de Lu Heng exige hechos de ejecución y una responsabilidad atribuible. Ni una institución ni el nombre de un protocolo pueden responder por la decisión de hacer que la evidencia de hoy gobierne el estado de mañana.

Sources

Registro normativo adicional

  1. RFC 5225 en texto plano
  2. Ficha informativa de RFC 5225
  3. Registro Datatracker de RFC 5225
  4. Historial de RFC 5225
  5. Erratas de RFC 5225
  6. Vista de erratas en línea de RFC 5225