Resumen

  • En PendingU, RETRY_AND_TERMINATE concede servicio cuando vence Tx y mantiene pendiente la solicitud. Un fallo de envío o una notificación posterior de error temporal conduce a terminarlo.
  • Ni la configuración local identifica siempre la política vigente ni un servidor alternativo accesible basta para trasladar una sesión de control de crédito con estado.

Un panel puede registrar una respuesta de crédito satisfactoria y aun así contar una historia incompleta. Antes de que llegara esa respuesta, quizá hubo un intervalo en el que se siguió prestando servicio con la solicitud todavía pendiente. No se afirma aquí que haya ocurrido en una red concreta. Es una posibilidad prevista por el protocolo y, por ello, una pregunta razonable para quien debe explicar cómo se sostuvo la continuidad.

El caso exige precisión: una sesión ya está establecida, el cliente ha solicitado una actualización de crédito y espera en PendingU. Con RETRY_AND_TERMINATE, el vencimiento de Tx permite prestar servicio sin abandonar ese estado. Más adelante, un fallo de envío o un error temporal definido por el protocolo cambia la acción: terminar el servicio y pasar a Idle. Así lo recoge la sección 7, tabla 4, de RFC8506, junto con los procedimientos de fallo de la sección 5.7.

Dos momentos que no conviene llamar igual

Vencer un temporizador de aplicación no equivale necesariamente a conocer el resultado final de una petición. Mientras esta sigue pendiente puede llegar una respuesta válida. Si la actualización obtiene una respuesta satisfactoria, la máquina de estados detiene Tx y vuelve a Open. En cambio, el fallo de envío comprende situaciones como la imposibilidad de comunicarse con el destino y, cuando corresponda, con una alternativa, o el agotamiento final del plazo de una solicitud.

«Error temporal» tampoco es una etiqueta informal para cualquier lentitud. Designa una clase de notificaciones del protocolo. Confundirla con el simple vencimiento de Tx elimina justamente la diferencia que explica por qué una misma política primero permite continuar y después exige terminar.

La sección 13 recomienda diez segundos para Tx. No certifica que ese sea el ajuste de un operador ni establece un límite universal de exposición de diez segundos. Hay otros relojes: la validez de las unidades y la supervisión del estado en el servidor no cumplen la misma función. La gestión necesita reconstruir el orden de los eventos, no elegir un número del estándar y presentarlo como garantía de servicio.

El crédito, además, no es necesariamente un saldo monetario. El control por sesión reserva unidades que pueden representar tiempo, volumen de datos o cantidad de servicio. La sección 5.3 prevé consultas intermedias al consumir la asignación, caducar su validez o cambiar condiciones relevantes; permite pedir por anticipado para evitar una interrupción. Continuar temporalmente no significa que el cliente haya creado una cuota nueva e ilimitada. Sigue habiendo un intercambio sobre unidades utilizadas y nuevas concesiones.

El alcance de una política de continuidad

La sección 8.14 define TERMINATE, CONTINUE y RETRY_AND_TERMINATE. Si no llega el atributo de gestión de fallos, el valor predeterminado es TERMINATE. En PendingU, ese valor termina el servicio al vencer Tx. Los otros dos lo permiten en ese primer momento, pero se separan ante el posterior fallo de envío o error temporal: CONTINUE sigue concediendo servicio y RETRY_AND_TERMINATE lo termina. La posibilidad de intentarlo con otro destino depende también del soporte de conmutación y de que exista una alternativa disponible.

Nada de ello convierte una denegación explícita en una recomendación. END_USER_SERVICE_DENIED termina el servicio en la tabla 4 con independencia de CCFH. Tampoco cabe aplicar esta tabla a cualquier primer acceso. La interrogación inicial asociada a una AA-Request tiene otra máquina de estados y desconecta cuando vence Tx. RFC8506 se ocupa de autorización de crédito; la autenticación y la autorización específicas del servicio quedan fuera de ese ámbito. La espera analizada no es una vía general para prescindir de ellas.

Antes de atribuir el comportamiento a una decisión local hay que comprobar de dónde vino la regla. Según la sección 5.7, el valor del servidor AAA del dominio de origen prevalece sobre la configuración local; el que aporta el servidor de control de crédito en su respuesta sustituye al valor existente. Una revisión basada solo en el ajuste predeterminado puede describir una política distinta de la que estaba actuando.

Conmutar requiere conservar el significado de la sesión

Encontrar otro servidor no resuelve por sí solo la continuidad de una sesión establecida. CC-Session-Failover regula la posibilidad de mover su flujo de mensajes de control de crédito. Si el atributo está ausente, se aplica FAILOVER_NOT_SUPPORTED y ese flujo no debe trasladarse, según las secciones 5.7 y 8.4. Elegir un respaldo para una sesión nueva es otra cuestión. También lo es cambiar de par en el camino de transporte, algo que puede generar duplicados sin autorizar la migración de la sesión.

Para las implementaciones que admiten dicha migración, el RFC recomienda transferir el estado de sesión y de cuenta entre servidores y exige detectar mensajes duplicados y fuera de secuencia. No define el mecanismo interservidor que realiza la transferencia. Session-Id junto con CC-Request-Number identifica una petición; disponer de ambos no demuestra que las reservas se hayan replicado correctamente. La prueba de disponibilidad debe abarcar algo más que una dirección que responde.

Las cuentas tampoco desaparecen durante la espera. La sección 5.7 recomienda un flujo alternativo de contabilidad de uso; su ejemplo de CONTINUE combinado con DELIVER_AND_GRANT depende expresamente de recoger esos datos e intercambiarlos con el servidor de crédito. Por tanto, continuidad no significa gratuidad, ausencia de medición o pérdida económica demostrada. La consulta final de la sección 5.4 sigue sirviendo para comunicar consumo y liquidar reservas no utilizadas. A la inversa, liberar una reserva en el servidor no acredita por sí solo que el cliente haya dejado de prestar servicio.

Lo que sabemos y lo que no

La ficha oficial sitúa RFC8506 como Proposed Standard de marzo de 2019 y sustituto de RFC4006. La consulta de erratas no mostró entradas coincidentes el 8 de septiembre de 2026. Esto no acredita implantación, conformidad de productos ni un incidente real. No se dispone aquí de cifras de clientes afectados, consumo o pérdidas.

La tesis de Lu Heng sobre la realidad como producto, en lugar de la defensa de una posición invita a explicar el mecanismo antes de calificarlo. Su ensayo sobre el problema de agencia en la gobernanza de internet sirve para preguntar quién decide y quién asume el resultado, no para imputar motivos a un operador. Aquí la observación suficiente es concreta: puede haber consumo real mientras una decisión de crédito sigue pendiente.