Resumen

  • draft-toutain-t2trg-coreconf-m2m-01 enlaza un modelo compacto YANG/SID con ontologías, FROST y herramientas MCP para consultar o configurar dispositivos limitados.
  • La resolución correcta de host, sensor, unidad y SID demuestra que el sistema encontró un destino bajo una proyección; no demuestra que el solicitante pueda actuar ni que el mundo alcanzó el estado pedido.
  • El recibo completo conserva versión del modelo, procedencia del mapa, principal, aprobación, decisión de acceso, petición, respuesta, aplicación local, interbloqueo, actuación y lectura independiente.

La base histórica dice que un sensor de temperatura pertenece a cierta estación. El agente sigue la relación, recupera un SID, aplica una precisión y solicita una lectura en vivo. Todo funciona, salvo por un detalle: la estación fue sustituida la semana anterior y el registro aún apunta al equipo retirado.

No hay error sintáctico. El SID existe, la herramienta acepta los argumentos y el mensaje CoAP puede estar perfectamente protegido. El fallo está en la afirmación intermedia que casi nunca aparece en el resultado: «este identificador sigue representando este dispositivo, aquí y ahora».

La revisión 01 de CORECONF for Machine-to-Machine Communication convierte esa afirmación en una cuestión de gobierno. A 2 de octubre de 2026, el Datatracker la mostraba como Internet-Draft individual activo, actualizado el 16 de septiembre. El texto es de esa fecha, aspira a Informational y vence el 20 de marzo de 2027. No tiene RFC stream, area director responsable ni telechat. Datatracker advierte que una contribución individual no está respaldada por el IETF ni ocupa una posición formal en su proceso. La lista T2TRG sirve para discutir, no prueba adopción por el IRTF.

El proyecto parte de una necesidad seria: equipos con poca energía y enlaces estrechos no pueden pagar siempre el peso de representaciones verbosas. YANG aporta estructura; CBOR, compacidad; CoAP, transporte; los SID sustituyen nombres largos por identificadores numéricos. La revisión 01 añade una proyección hacia SOSA, SensorThings y MCP.

El servidor que elimina traducciones sigue tomando decisiones

El resumen del borrador dice que CORECONF/SID puede conectar dispositivos y agentes sin una capa intermedia de traducción específica para cada aparato. La frase no significa que desaparezca la interpretación. El servidor MCP propuesto consulta FROST para resolver hostname, endpoint CoAP, identidad del sensor, SID de instancia, SID del campo, unidad y precisión. Después construye la petición.

Ese trabajo crea una superficie de autoridad. Quien edita FROST puede cambiar el destino de una operación sin cambiar la herramienta. Quien actualiza un fichero SID puede alterar el significado de un número. Quien controla el modelo decide si un transductor es sensor, actuador o ambos. Quien aplica la precisión convierte el entero de red en magnitud física.

El propio modelo separa defaults y overrides de unidad, precisión y categoría. El bootstrap contiene inventario, uptime, época de referencia y paso mínimo; es config false, cambia con el reinicio y obliga a una nueva fase de descubrimiento. Tratar una resolución anterior al reboot como verdad actual rompe el contrato aunque cada componente sea válido por separado.

Por eso el recibo de proyección necesita módulo y revisión YANG, features y deviations, fichero SID y traducción privada, identidad del equipo y transductor, generación del bootstrap, endpoint, unidad, precisión, categoría, control, método, ruta, SID objetivo, versión y antigüedad de FROST. No basta con guardar el nombre amable de la herramienta.

La ontología describe capacidades; la política asigna derechos

La revisión 01 crea instancias ccm2m:Control para lectura instantánea, estadísticas, reset, preparación y suscripción a notificaciones, y escritura instantánea. El modelo distingue con acierto configurar un historial de empezarlo y reconoce que detener Observe pertenece al estado de transporte.

La descripción de una operación no contiene por sí sola al sujeto autorizado. Tampoco indica propósito, rango permitido, ventana temporal, doble aprobación, límite de repeticiones, interbloqueo o parada de emergencia. Una ontología puede decir «este elemento tiene un control instant-write» sin decir «este agente puede usarlo a las 03:00».

La revisión 21 del borrador CORECONF subyacente exige impedir lecturas y escrituras no autorizadas. Define 4.01 Unauthorized cuando el cliente no tiene permiso sobre un nodo, datastore, RPC, acción o event stream, y remite a autenticación y autorización apropiadas. No es correcto afirmar que CORECONF carece de control de acceso.

MCP tampoco convierte tools/list en una concesión universal. La especificación 2026-07-28 permite que el conjunto dependa de la autorización presentada en cada petición. Obliga a validar inputs y aplicar controles de acceso, recomienda confirmación humana en operaciones sensibles y manda desconfiar de annotations no respaldadas por un servidor de confianza.

El problema práctico es conservar la unión. La definición y hash de la herramienta, cliente solicitante, principal autenticado, audiencia, scopes, política, aprobación, recurso, rango y decisión CORECONF deben quedar en el mismo linaje. Sin ese vínculo, un log demuestra que había un verbo y que alguien lo llamó, no que poseía mandato.

Una respuesta exitosa no gira un eje

El documento seleccionado exige DTLS u OSCORE para las operaciones. Eso protege el intercambio según el perfil utilizado. No decide la seguridad industrial. Una petición bien cifrada puede exceder una envolvente mecánica; una identidad autenticada puede tener el scope equivocado; una autorización válida puede llegar durante mantenimiento.

CORECONF distingue errores de protocolo y de restricciones YANG. Un 4.01 rechaza autoridad, un 4.05 método, otros códigos informan de datos ausentes o fuera de rango. Una respuesta 2.xx demuestra procesamiento en ese nivel. No mide presión, velocidad, posición o temperatura.

El borrador usa una bomba ficticia para ilustrar instant-write: 1.500 rpm, un SID de identidad PPPPPP porque la bomba no existe en el módulo y el SID estructural real de la cantidad. Registra una sosa:Actuation con el valor escrito y el momento en que el cliente emitió la orden. El texto afirma que no es una observación.

Esa frase impide una confusión esencial. La orden “1.500” no es un tacómetro. Una lectura posterior debe declarar sensor, calibración, unidad, precisión, origen temporal y ventana causal. Si el gateway confirma leyendo el mismo registro que acaba de escribir, la segunda evidencia es una copia de la intención.

La escalera honesta separa invocación MCP, intención y consentimiento, autorización, transporte protegido, validación de aplicación, commit, estado del interbloqueo, comienzo y fin de actuación, observación aparte, persistencia y reconciliación. No hace falta fingir que todos los peldaños existen: hace falta no llamar «resultado» al último que sí existe.

Un ajuste de un cliente puede gobernar a todos

Los parámetros de notificación revelan otro límite. El paso, máximo de muestras, periodo, codificación, tamaño, umbrales, histéresis, dampening y frecuencia de mensajes confirmables son compartidos por todas las observaciones de un transductor. Un iPATCH activo cambia de inmediato lo que reciben otros clientes.

Una herramienta start_history_notify combina configuración y suscripción. Para el llamante parece una preparación privada; para los demás puede alterar cadencia o fiabilidad. El flag active sólo dice que alguien observa. No enumera quién, qué propósito tiene ni si acepta el cambio.

La herramienta segura debe mostrar el alcance compartido, leer versión y valores previos, aplicar una precondición, registrar before/after y determinar afectados. El permiso para observar no debería implicar el permiso para reconfigurar observadores ajenos. Tampoco el permiso para editar entidades históricas debería permitir cambiar el mapa usado por el controlador en vivo.

La eficiencia desplaza la incertidumbre

FETCH e iPATCH deben enviarse como mensajes CoAP Non-Confirmable en el perfil. La decisión ahorra retransmisión en enlaces costosos, pero entrega a la aplicación la política de timeout y retry.

Si no vuelve respuesta, el servidor MCP no sabe si la petición se perdió, si el dispositivo la aplicó y se perdió la contestación o si sigue ejecutándola. Repetir un set idempotente y repetir una acción con efecto lateral no son equivalentes. El recibo debe conservar token, identidad y hash de la petición, número de intento, regla de tiempo, tratamiento de duplicados y lectura posterior.

Un ACK de una notificación confirmable sólo demuestra recepción en el peer CoAP. No acredita almacenamiento duradero, lectura humana ni resolución del fenómeno. La compacidad del enlace hace más importante conservar el tipo exacto de recibo.

El reloj y la escala también deciden

El modelo admite una época de referencia opcional y distingue timestamps creados por la fuente o por el receptor. El historial puede reconstruir instantes desde la recepción y el intervalo. Hora de orden, aceptación, actuación y observación pueden diferir.

La cantidad viaja como entero y depende de unidad y precisión. El minimal-step avisa que preguntar más rápido puede consumir batería sin obtener una muestra nueva. Toda prueba de postcondición debe especificar modelo, unidad, precisión, calibración, fuente de tiempo, calidad del reloj y edad.

Datatracker mostraba 19 errores y 8 warnings de validación YANG. Ese dato pertenece al recibo de la revisión: alerta de trabajo pendiente, no autoriza a declarar inseguro el diseño. Del mismo modo, un futuro cero errores certificaría sólo la aceptación por esas comprobaciones, no autoridad, interoperabilidad ni movimiento físico.