Resumo

  • O OpenConfig padroniza o campo, mas seu modelo terminal-device define operational-mode como específico do fabricante e exige sua presença na lista suportada.
  • No exemplo do NANOG 98, 5003 corresponde ao OIF 400ZR AppSel 1 na plataforma do palestrante; não é universal.

5003 parece perfeito para automação: curto e fácil de copiar. A nota do slide muda a leitura. Philip Bedard associa 5003 ao OIF 400ZR Application Selection 1 na plataforma do exemplo. A mesma página diz que o valor numérico operational-mode no OpenConfig não é padronizado e sugere 6xxx para representar o AppSel real.

Esse é o limite de controle. O OpenConfig oferece um campo comum, mas não transforma cada número nele em vocabulário óptico compartilhado. O modelo terminal-device chama o valor de identificador específico do fabricante e exige que apareça na lista de modos suportados. A lista comprova que o destino reconhece o identificador.

Ao passar do inventário pelo controlador até o roteador, copiar 5003 sem definição pode preservar o texto e perder a intenção. O registro deve levar o modo padrão ou organizacional, o identificador local, o par host/mídia e as capacidades do destino. A automação resolve o código local na aplicação.

Modo configurado, estado informado pelo módulo, medições ópticas e serviço entregue são fatos diferentes. Uma gravação aceita não prova que o modo pretendido está ativo nem que o caminho completo é viável.

A OIF anunciou C-CMIS 1.5 em setembro de 2026. O rascunho YANG de DWDM do IETF, atualizado em 30 de outubro, diferencia modos padrão, organizacionais e explícitos, mas não garante interoperabilidade de transceptores. O vocabulário melhora; a correspondência com a capacidade de cada equipamento continua sendo trabalho operacional.

Os slides não mostram matriz de migração entre fabricantes nem interrupção atribuída à divergência de IDs. Mostram por que um inteiro sem definição é um contrato fraco: o número viaja mais longe que seu significado.

Fontes