Resumo

  • A revisão 04 de draft-ietf-green-power-and-energy-yang foi disponibilizada em 9 de setembro de 2026. Continua como Internet-Draft do grupo GREEN no estado I-D Exists, não como RFC ou padrão aprovado.
  • A nova seção de identificação afirma que source-component-id se vincula ao uuid do RFC 8348 para correlacionar Energy Objects entre dispositivos, sistemas de gestão e domínios administrativos.
  • No próprio módulo, o leaf ainda referencia /hw:hardware/hw:component/hw:name. Pelas regras do YANG 1.1, o path determina o nó e o espaço de valores; portanto, o contrato executável escolhe o nome local, não o leaf UUID separado.
  • Texto e esquema precisam primeiro indicar a mesma identidade. Daniel Kade também propõe um comprovante protegido de vinculação para trocas futuras. Ele não faz parte da especificação.

A promessa mudou; o destino do leaf não

A lista recente da IETF mostra a revisão 04 em 9 de setembro. O registro do Datatracker a mantém como documento ativo do GREEN, e o histórico registra a nova versão às 05:30:49 no fuso -0700 apresentado. O estado é I-D Exists. A validação YANG sem erros não é aprovação e tampouco compara uma afirmação em prosa com a semântica do path.

O texto novo separa os identificadores do RFC 8348. name vale dentro de um dispositivo; physical-index depende do suporte ao modelo legado; apenas uuid é descrito como globalmente único. Depois declara que source-component-id usa esse UUID e permite correlação sem depender da nomenclatura de cada equipamento.

O bloco YANG, porém, mantém type leafref, path /hw:hardware/hw:component/hw:name e uma descrição que fala no nome do componente. A revisão 03 já tinha a mesma definição. A comparação oficial revela uma explicação mais forte sobre UUID sem alteração equivalente do leaf.

O modelo de dados escolhe um espaço de valores

O RFC 7950 define leafref: o path identifica o leaf ou leaf-list de destino, e o valor da referência pertence ao espaço desse destino. Aqui, ele termina em name.

No RFC 8348, name é a chave string da lista de componentes. uuid é outro campo, opcional, somente leitura e do tipo yang:uuid. O documento foi desenhado para hardware em um único servidor. Dois aparelhos podem usar legitimamente psu-1; isso não produz uma identidade global compartilhada.

Nada disso demonstra falha em produto. Um implementador pode ter criado mapeamento próprio, seguido a intenção do parágrafo ou aguardado nova revisão. UUID também não prova propriedade, presença física atual ou autorização de controle. A conclusão verificável é que a versão imutável fornece duas instruções distintas para o mesmo source-component-id.

A qualidade do número depende do objeto certo

O framework GREEN propõe agregação e validação por hierarquias. Os casos de uso incluem inventário de ciclo de vida, observação indireta e controle de energia. Se um nome reaproveitado une componentes diferentes, estimativa, certificado e classe de precisão continuam anexados ao sujeito errado.

Na parte de controle, a versão distingue o estado administrativo solicitado do estado operacional observado. Uma referência separada com require-instance false deixa a configuração sobreviver antes da aparição do Energy Object ou depois de seu desaparecimento; sem o objeto, ela não tem efeito. A seção de segurança alerta que escrita administrativa indevida pode desligar infraestrutura crítica, danificar hardware ou mascarar ataque por ciclos de energia. O texto recomenda NACM para restringir acesso via NETCONF ou RESTCONF.

Controle de acesso comprova quem pode escrever, não se a configuração persistente reencontrou a mesma peça. Substituição exige um juízo de identidade próprio.

Uma correção no draft e uma prova local de religação

O conserto editorial e técnico vem primeiro. Se o objetivo é correlação entre sistemas, o módulo deve carregar ou referenciar UUID sem ambiguidade. Se a escolha for nome local, a alegação interdomínio precisa ser reduzida e um mapeamento separado deve ser especificado.

Uma operação madura pode guardar um comprovante protegido contendo:

  1. revisão e hash do módulo realmente usado;
  2. Energy Object id, dispositivo e domínio administrativo;
  3. nome local e UUID observado, com ausência explícita;
  4. fonte, autoridade e horário do vínculo;
  5. serial, ativo ou evidência de substituição disponível;
  6. desaparecimento, troca, reatribuição ou união de registros;
  7. intenção administrativa que permaneceu ligada;
  8. autoridade e tempo da decisão de religação;
  9. resultado da checagem antes de retomar agregação ou controle.

O registro não precisa expor topologia nem atividade comercial. A própria revisão avisa que medições finas e relações de alimentação podem revelar carga, capacidade e alvos críticos. Referências compactas podem ficar na zona de gestão autorizada.

A disciplina de especificação mínima de Heng Lu sugere padronizar somente a borda necessária à interoperabilidade. The Policy Mirror lembra que uma ação automatizada deve conservar visíveis sua regra e seu sujeito.

Esse comprovante é proposta editorial minha. Não foi definido pela revisão 04 nem aprovado pelo GREEN.

Limite das evidências

Os documentos mostram a divergência entre parágrafo e leafref. Não mostram implantação, medição atribuída incorretamente, comando reativado ou dano. O UUID do RFC 8348 é opcional e não substitui prova de posse ou autoridade. Uma futura versão pode alinhar tudo.

O achado presente é restrito: a revisão declara correlação por UUID, enquanto o módulo ainda seleciona component/name.

Fontes