Resumen

  • RFC 9952 asigna co a CoAP sobre DTLS y permite anunciarlo en SVCB. También advierte que RFC 7252 no definió ALPN para el saludo DTLS y que el nuevo RFC no establece reglas equivalentes a las de RFC 8323 para CoAP sobre TLS.
  • IANA demuestra coordinación del nombre; DNS demuestra una afirmación de descubrimiento; la negociación exige la oferta exacta de ClientHello y la selección de ServerHello. Identidad, autorización CoAP y resultado siguen siendo decisiones posteriores.

El valor co ocupa dos octetos. El valor coap, usado para CoAP sobre TLS, ocupa cuatro. La diferencia parece mínima hasta que el saludo atraviesa una red restringida en la que cada fragmento de enlace aumenta la probabilidad de pérdida y retransmisión. RFC 9952 elige el nombre corto por una razón técnica y evita usar la misma etiqueta para transportes distintos.

Pero el texto se detiene ahí. La frase decisiva dice que RFC 7252 no definió el uso de la extensión ALPN durante la conexión DTLS y que RFC 9952 no cambia ese hecho. El registro habilita vocabulario; no impone una nueva máquina de estados.

El catálogo no genera la oferta

La fila de IANA responde qué bytes debe utilizar un perfil que quiera identificar CoAP sobre DTLS mediante ALPN. No responde si el binario cargado lo implementa, si la función está habilitada en un listener o si el cliente la incluyó en esa conexión.

Un SVCB con alpn=co añade intención de servicio. Antes de convertirla en tráfico, el cliente debe resolver, validar según su política, evaluar frescura, procesar alias, elegir candidato y abrir el endpoint correcto. DNSSEC puede autenticar la respuesta DNS; no puede afirmar que el proceso servidor cargó la misma generación.

RFC 7301 define el recibo de negociación: lista ordenada en ClientHello, una selección del servidor tomada de esa lista, o el fallo aplicable. Hay que guardar conexión, endpoints, versión DTLS, oferta completa, selección o alerta, hora y procedencia de la captura. Si hay reintento o fallback, cada conexión necesita identidad propia.

Eficiencia prevista y resultado medido

Ahorrar dos octetos puede evitar cruzar un umbral, pero no garantiza un datagrama sin fragmentación. La longitud total incluye grupos, key shares, suites, firmas, cookies, extensiones y credenciales. DTLS puede fragmentar en una capa y 6LoWPAN en otra. MTU, radio, pérdida y temporizadores completan el resultado.

La afirmación operativa requiere mediciones comparables: tamaño de saludos, fragmentos de enlace, retransmisiones, duración y fallos bajo una configuración identificada. El RFC explica el diseño; no certifica el rendimiento de una flota.

La etiqueta tampoco autentica el negocio

Una selección real de co sigue siendo intermedia. La identidad del endpoint depende del certificado o clave, nombre de referencia, ancla y vigencia. Luego CoAP debe analizar opciones y tokens, correlacionar respuesta, aplicar método y política de recurso. La aplicación decide si el resultado autoriza un cambio de estado.

Por eso la cadena conserva por separado registro, anuncio, elección, oferta, selección, identidad, intercambio CoAP, autorización y efecto. Tampoco se debe invertir la lógica: la ausencia de ALPN no prueba por sí sola que la conexión viola RFC 9952. El perfil concreto debe decir si co es obligatorio, permitido o ajeno.

La doctrina de Lu Heng encaja con esta modestia. La especificación inicial común puede ser una etiqueta mínima. Las decisiones de despliegue quedan con quienes soportan sus consecuencias. Las capas de realidad impiden que una tabla sustituya al paquete y que el paquete sustituya a la autorización. La primacía del código ejecutado pide la versión y configuración realmente cargadas.

RFC 9952 no falla por ser pequeño. Su valor está en negarse a convertir un nombre en una orden. La operación madura debe conservar la misma separación.

Las excepciones también forman parte del despliegue

Una migración no ocurre como un cambio simultáneo de toda la flota. Habrá sensores con firmware anterior, gateways que consultan otra vista DNS, respuestas SVCB retenidas en caché y clientes configurados con una dirección que nunca hacen descubrimiento. Esas rutas determinan si una instancia pudo ver el anuncio, si su proceso cargó la capacidad y si el servidor recibió una oferta. Ocultarlas dentro de un porcentaje agregado impide explicar cualquier discrepancia.

El inventario de excepciones debe incluir propietario, población, motivo, versión, vencimiento y conducta de fallback. La fecha no cierra la excepción: la cierra una observación de que la última población abandonó el camino anterior. Mientras exista una ruta alternativa, cada conexión necesita identidad propia y cada efecto CoAP debe poder atribuirse a esa conexión. Así se evita que el éxito del segundo intento reescriba la historia del primero.

La evidencia de una entrega une al menos cuatro piezas: artefacto ejecutable con soporte, configuración que lo activa, generación DNS observada por el cliente y traza de oferta y selección. Son piezas complementarias. Un binario nuevo puede leer configuración vieja; DNS nuevo puede dirigir a un listener antiguo; un canario correcto puede convivir con miles de endpoints que siguen otra ruta.

También conviene publicar los límites de cada equipo. DNS puede demostrar un registro correcto, no un ClientHello. Plataforma puede demostrar un flag activo, no la elección remota. Seguridad puede validar la identidad sin autorizar el recurso. La aplicación puede observar un cambio sin saber cuál de dos intentos lo causó. Un informe honesto mantiene estos veredictos separados y solo después construye la cadena completa.

Fuentes