Resumo

  • draft-toutain-t2trg-coreconf-m2m-01 conecta um modelo compacto YANG/SID a ontologias, FROST e ferramentas MCP que podem ler, configurar e acompanhar dispositivos restritos.
  • FETCH e iPATCH Non-Confirmable economizam tráfego, mas deixam timeout, retry e ambiguidade de duplicação com a aplicação; uma resposta de sucesso continua sendo diferente de movimento físico observado.
  • O recibo defensável liga revisão do modelo, resolução, principal, autorização, aprovação, bytes da requisição, tentativa, resposta, commit, interlock, atuação e readback separado.

Uma iPATCH sai em uma mensagem CoAP Non-Confirmable. O retorno não chega. O servidor MCP tenta de novo? Se a primeira mensagem se perdeu, repetir pode ser necessário. Se a primeira chegou, alterou o estado e só a resposta desapareceu, a segunda tentativa pode duplicar um efeito.

O protocolo não cometeu um erro. O perfil transferiu a política de retransmissão para a aplicação porque links de pouca energia não suportam sempre o comportamento padrão. O erro surgiria se a camada MCP escondesse essa incerteza atrás de “falhou” ou “concluído”.

Em 2 de outubro de 2026, o Datatracker do IETF listava a revisão 01 de CORECONF for Machine-to-Machine Communication como Internet-Draft individual ativo, atualizada em 16 de setembro. O texto é da mesma data, pretende ser Informational e expira em 20 de março de 2027. Não tem RFC stream, AD responsável ou telechat. A página informa que uma submissão individual não recebe endosso do IETF nem posição formal em seu processo. Discussão na lista T2TRG não equivale a adoção pelo IRTF.

O resultado YANG exibido naquela data tinha 19 errors e 8 warnings: referências de revisão e descrições ausentes, ordem canônica e um alerta de acessibilidade do bootstrap config false, entre outros. O número descreve a maturidade da submissão, não uma contagem de vulnerabilidades nem um teste de implantação.

A eficiência de representação não elimina interpretação

O projeto combina YANG, CoAP, CBOR e Schema Item iDentifiers. O transducer pode ser sensor, actuator ou ambos. O modelo guarda quantidade atual, origem do timestamp, estatísticas e parâmetros de notificação. Os SID reduzem nomes a inteiros compactos, o que faz sentido onde energia e largura de banda são escassas.

A revisão 01 projeta esses dados para SOSA e SensorThings e descreve dois servidores MCP. Um executa ações CoAP ao vivo; o outro consulta e edita a base FROST. No exemplo de Rennes, o agente localiza um Thing, segue Datastreams, obtém SID e precision, lê o dispositivo e grava uma Observation.

O resumo afirma que isso evita uma camada intermediária específica para cada dispositivo. Evita código artesanal de serialização; não evita um mediador semântico. O servidor ainda escolhe hostname, endpoint, identidade, instance SID, target SID, unidade e precisão com base em FROST.

Uma linha antiga pode enviar a operação ao equipamento retirado. Um identity reaproveitado pode apontar para outro transducer. Uma precision errada transforma inteiro válido em grandeza errada. Uma mudança de category pode expor escrita onde antes havia apenas leitura. Nada disso exige um pacote malformado.

O recibo de projeção deve fixar módulo e revision YANG, features, deviations, arquivo SID, tradução privada, identidades, geração do bootstrap, endpoint, unidade, precisão, category, control type, método, path, target SID e versão/proveniência/freshness do registro FROST.

Saber que uma ação existe não concede mandato

O grafo ccm2m:Control nomeia read-single, read-stat, resets, preparação de histórico, subscription e instant-write. A separação entre configurar e iniciar é correta; o encerramento de Observe depende do token e do estado de transporte, não de outro controle SID.

Mas a ontologia não identifica quem pode agir. Ela não informa finalidade, intervalo permitido, janela de manutenção, aprovação humana, limite de retry, interlock ou autoridade de parada.

O draft CORECONF revision 21 exige que o servidor impeça usuários não autorizados de ler ou escrever recursos. Ele define 4.01 Unauthorized para falta de permissão sobre data node, datastore, RPC, action ou event stream e pede mecanismos adequados de autenticação e autorização. Portanto, a questão não é “CORECONF não tem autorização”; é como provar a ligação entre a decisão e a chamada MCP.

A especificação MCP 2026-07-28 permite que a lista de ferramentas varie pela autorização apresentada na requisição. Exige input validation, access control, rate limit e sanitização. Recomenda confirmação em operações sensíveis e trata annotations como não confiáveis quando o servidor não é confiável.

O log precisa unir identidade e hash do MCP server/tool, client, principal autenticado, audience, scopes, política, aprovação, target e limites ao resultado de autorização CORECONF. Uma linha com o nome da ferramenta e argumentos não mostra quem delegou poder.

Canal protegido, resultado limitado

O draft selecionado exige DTLS ou OSCORE para CORECONF sobre CoAP. A proteção de transporte é indispensável, mas não define a regra operacional de uma bomba. Uma credencial válida pode carregar scope excessivo; uma solicitação íntegra pode chegar durante manutenção; uma autorização correta pode esbarrar em um interlock local.

CORECONF separa Unauthorized, Method Not Allowed, Not Found e violações do modelo. Um código de sucesso diz que a requisição foi processada naquele nível. Não mede rotação, pressão, temperatura ou posição.

O exemplo de instant-write usa uma bomba fictícia a 1.500 rpm. O identity SID é o placeholder PPPPPP, pois ela não existe no módulo; o SID estrutural da quantity é real. A sosa:Actuation guarda valor e hora de emissão do comando, e o texto afirma que isso não é Observation.

Essa distinção deve aparecer no produto. Comando não é tacômetro. Readback precisa de sensor separado, calibração, unidade, precisão, origem temporal e janela causal. Consultar o cache que recebeu o write repete a intenção, não observa o eixo.

A cadeia é: invocação; intenção e consentimento; principal e autorização; request protegido; validação da aplicação; commit/action start; estado de interlock; execução física; observação separada; duração; reconciliação ou rollback. Cada elo pode faltar. A resposta deve revelar o último confirmado.

Configuração de notificação tem alcance coletivo

Os parâmetros de history e sensor-alert incluem step, precision, max-samples, time-period, encoding, max-payload, limites, hysteresis, dampening e check-interval. Eles são comuns a todas as observações do transducer. Mudanças durante uma notification ativa valem imediatamente para todos os clients.

start_history_notify primeiro faz iPATCH de configuração e depois FETCH+Observe. Uma preparação aparentemente local pode alterar frequência, formato ou confirmação de streams existentes. active apenas informa que uma ou mais pessoas observam; não diz quem são ou se consentiram.

A ferramenta precisa expor o shared scope, ler versão e valor anterior, aplicar precondition ou regra de conflito, registrar before/after e enumerar afetados. Permissão de subscribe não deveria incluir reconfigurar terceiros. Permissão de editar FROST também não deveria permitir alterar o mapa usado no caminho ao vivo.

Retry é uma decisão operacional

Com request NON e resposta ausente, a aplicação encara três mundos: nada chegou; chegou e foi aplicado; ainda está em curso. Repetir set-value pode ser idempotente sob certas condições; reset, criação ou ação com efeitos laterais pode não ser.

O recibo deve guardar request identity, CoAP token, payload hash, attempt, timeout policy, duplicate semantics e leitura posterior. A interface precisa diferenciar sent, accepted, committed, executing, observed e reconciled.

Já ACK de uma notification CON demonstra recepção pelo peer CoAP. Não prova persistência no FROST, avaliação pelo agente, reconhecimento humano ou fim do evento físico. O pacote menor pede um vocabulário de evidência maior.

Relógio, unidade e calibração fecham o sentido

Bootstrap pode trazer reference epoch, uptime e minimal-step. A época absoluta pode faltar. O timestamp da quantity pode vir do source ou do receiver, e o histórico pode reconstruir tempos a partir de chegada e step. Hora da ordem, aceitação, movimento e gravação são fatos diferentes.

O inteiro bruto depende de identity, unit e precision. Polling acima de minimal-step pode drenar bateria sem aumentar freshness. A postcondition deve indicar modelo, escala, calibração, origem do tempo, qualidade do relógio e idade.

Os 19 errors e 8 warnings pertencem ao recibo do modelo. Exigem correção e acompanhamento, não autorizam rotular a arquitetura como insegura. Um futuro resultado limpo provaria conformidade com aqueles validadores, não autorização, interoperabilidade ou atuação.