Resumo

  • A revisão 01 cria uma hierarquia de folhas somente leitura para dizer que tipo de alteração uma regra SCHC suporta; ela não identifica quem recebeu o direito de executar a alteração.
  • A decisão precisa combinar autorização do ator e da requisição com toda a cadeia de permissões SCHC, além de provar a versão anterior, a validação, a ativação nos pares e a recuperação.

Uma requisição chega por um canal autenticado. O usuário pertence a um grupo com direito de atualizar configuração. Na regra SCHC, o campo devolve change-tv. A automação vê duas permissões e interpreta o resultado como uma autorização completa.

As permissões, porém, têm objetos diferentes. A primeira trata da sessão e da operação de gestão. A segunda limita o formato de mudança tolerado por um Field Descriptor. Ainda falta ligar aquele usuário àquele Context, àquele RuleID e àquela versão. Também falta saber se o par remoto aceitará o mesmo significado e se haverá retorno em caso de falha.

O cenário é reconstruído, não um incidente atribuído a uma rede real. Ele serve para ler draft-ietf-schc-access-control-01 no tamanho certo: a proposta oferece um limite semântico importante, mas um limite de mutabilidade não é uma credencial.

A economia de bits depende de uma memória comum

No RFC 8724, o SCHC comprime cabeçalhos porque os participantes já compartilham um Context. O RuleID aponta para uma regra, e cada Field Descriptor contém elementos como Target Value, Matching Operator e Compression/Decompression Action. O pacote pode omitir informação porque compressor e descompressor concordam antes sobre ela.

Essa arquitetura transforma a integridade da regra em condição operacional. Se os lados interpretam o mesmo RuleID por Contexts diferentes, o pacote reduzido não leva dados suficientes para resolver a diferença. O RFC 9363 alerta que a alteração de um endereço IPv6 de aplicação pode bloquear comunicação ou permitir escuta. Por isso, pede validação da identidade do solicitante e restrição para que um dispositivo modifique apenas suas próprias regras.

O rascunho novo acrescenta a granularidade que um simples direito de escrita não oferece. Dentro de uma regra, pode fazer sentido mudar o Target Value de Uri-Path e, ao mesmo tempo, impedir mudança no prefixo de aplicação. Autorizar todo o módulo YANG apagaria essa distinção.

Uma permissão depende das permissões acima dela

ac-modify-set-of-rules controla o nível do conjunto: nenhuma mudança, mudança de elemento existente ou inclusão e retirada. ac-modify-compression-rule aplica limite aos Field Descriptions da regra de compressão. ac-modify-field separa nenhuma mudança, alteração do Target Value e alteração de TV, MO e CDA.

A hierarquia não é decorativa. A folha da regra de compressão só vale quando o pai permite modificação. A folha de campo só vale quando os dois pais permitem. Um filho permissivo não supera um pai com no-change. Se a folha não aparece, o texto diz que a informação não pode ser alterada.

Todas são config false. O cliente remoto as lê, mas não as escreve para conceder poder a si próprio. Essa assimetria evita que o pedido produza a própria autorização.

Mesmo assim, as folhas não têm nome de usuário, grupo, certificado, sessão, proprietário do dispositivo, delegação ou versão da política. Elas respondem “até onde este objeto pode mudar”. Não respondem “quem pode levá-lo até lá”.

O ator está no plano de gestão

O próprio rascunho usa NACM como referência. O RFC 8341 recebe do transporte o usuário autenticado e seus grupos, compara regras para operações e nós de dados e devolve access-denied quando necessário. A política efetiva no começo do processamento de uma mensagem permanece durante a mensagem inteira.

NACM e as folhas SCHC não competem. O primeiro decide se o principal pode fazer a requisição. As segundas decidem se o elemento aceita aquela classe de mutação. A regra segura é uma conjunção:

este ator pode executar esta operação e este elemento SCHC pode sofrer esta mudança.

NETCONF pode acrescentar validação, datastore candidato, lock e rollback-on-error, quando as capacidades forem anunciadas. RESTCONF permite usar ETag e If-Match para rejeitar um write baseado em uma representação antiga. CORECONF leva a gestão YANG a dispositivos restritos com CoAP e exige que o servidor impeça leituras e escritas não autorizadas, apoiando-se em proteção e autorização adequadas.

Nenhum desses recursos elimina a outra metade. CRUDX não expressa sozinho por que um Target Value pode mudar e o prefixo ao lado não. change-tv não autentica o portador da sessão. Uma implementação que aceita apenas o primeiro cria administradores largos demais; outra que aceita apenas o segundo deixa a mutabilidade sem sujeito.

A confirmação da API não confirma o novo Context

Depois das duas autorizações, surge a questão temporal. Outro controlador pode ter alterado a regra entre a leitura e o write. If-Match pode detectar esse conflito no RESTCONF; locks ou candidate configuration podem oferecer proteção diferente no NETCONF. O rascunho SCHC não escolhe uma composição obrigatória.

Há ainda uma fronteira mais profunda. O datastore pode aceitar a edição enquanto o outro endpoint continua usando a regra anterior. Um 204 ou <ok/> prova que o servidor de gestão concluiu uma transação. Não prova que o protocolo passou a operar com o mesmo Context nos dois lados.

Uma mudança completa precisa nomear revisão, instante de ativação, pares atingidos, verificação de compatibilidade e estado de recuperação. Sem isso, a automação pode transformar um sucesso de controle em uma falha de dados.

A revisão 01 também não define quem fornece as folhas somente leitura, de onde vêm seus valores, como uma revogação alcança requisições em trânsito ou como um principal é ligado à posse de um Context. Concorrência, atomicidade de vários campos, auditoria e rollback permanecem fora do texto. Implementações podem fornecer essas funções; o rótulo de acesso não deve receber crédito por controles que não contém.

O estágio do documento faz parte do risco

O material analisado é um Internet-Draft ativo do grupo SCHC, atualizado em 29 de setembro de 2026, com cabeçalho Standards Track. Não é RFC. A seção Terminology ainda mostra ToDo; Security Considerations e IANA Considerations estão como TBD. O módulo YANG conserva revisão de 2023 e texto sobre compound-ack e RFC YYYY, além de descrições Reserved slot number em valores de field access.

Esses vestígios não tornam a ideia inválida. Eles impedem que uma organização trate nomes e comportamento como contrato congelado. O rascunho de arquitetura SCHC de julho de 2026 já recomenda autenticar e autorizar gestores, registrar mudanças e restaurar um Context conhecido como bom, mas reconhece que ciclo de vida e gestão ainda precisam ser desenvolvidos.

As fontes não provam uso generalizado, interoperabilidade, desempenho ou incidente real. Quem experimentar agora deve guardar a revisão exata e tratar qualquer atualização futura como mudança de segurança, não apenas editorial.

Um recibo que registra autoridade e efeito

Para cada alteração relevante, guardar:

  1. principal autenticado, grupos, sessão e proteção do transporte;
  2. operação, Context, Set of Rules e RuleID alvo;
  3. revisão anterior ou ETag e valores exatos antes/depois;
  4. folhas SCHC aplicáveis, inclusive os pais;
  5. revisão da política NACM ou equivalente;
  6. validação, controle de conflito e resultado transacional;
  7. ativação por par e evidência de compatibilidade;
  8. efeito observado, responsável e ponto de rollback testado.

Esse registro preserva autoridade estreita. Identidade comprova o ator; SCHC limita o objeto; a transação preserva a edição; o operador controla a ativação. Estarem reunidos na mesma chamada não dá a uma camada o mandato da outra.

Sources