Resumo

  • O RFC 1239 transferiu cinco raízes MIB dos arcos experimentais sob 1.3.6.1.3 para as ramificações padrão mib-2 e transmission.
  • A justificativa era operacional: renumerar tarde obrigava fornecedores a revisar implementações mesmo sem mudança técnica substancial, podia causar problemas em campo e desestimular adoção precoce.
  • A tabela prova os códigos escolhidos pelo processo de padronização; não prova quando um agente, gerenciador, coletor ou acervo de dados os adotou.

O endereço numérico já fazia parte da interface

O RFC 1239 descreveu uma prática que parecia prudente. MIBs em desenvolvimento recebiam arcos experimentais; somente no estágio Full Standard ganhavam um arco padrão. O resultado era menos prudente: a promoção do documento podia obrigar fornecedores a revisar seus produtos mesmo quando provavelmente não havia mudança técnica substancial nas definições.

Pela SMI do RFC 1155, o OID é o nome administrativo de um tipo de objeto. Ele aparece na consulta, orienta o agente, vira chave no armazenamento e sustenta o rótulo visto pelo operador. Alterar a raiz muda o endereço de tudo abaixo dela. O texto explicativo pode continuar familiar, mas o software não pergunta por explicações; pergunta pelo número.

Havia também um problema de incentivo. Quem esperava uma renumeração futura podia adiar a implementação até Full Standard. Com isso, o padrão perdia a experiência de campo que deveria ajudar a amadurecê-lo. O RFC 1239 preferiu atribuir arcos padrão cedo e preservá-los ao longo da evolução normativa.

Hoje, o registro do RFC Editor e o Datatracker classificam o documento como Historic e Legacy. Essa é a condição atual do documento, não um inventário de equipamentos nem uma prova de uso.

Cinco raízes mudaram; cinco frotas não foram observadas

As extensões genéricas de interface do RFC 1229 estavam em 1.3.6.1.3.6. O novo endereço passou a ser 1.3.6.1.2.1.12: de experimental 6 para mib-2 12.

As demais entraram em transmission. A MIB IEEE 802.4 do RFC 1230 passou de 7 para 8. A IEEE 802.5 do RFC 1231, de 4 para 9. A DS1 do RFC 1232, de 2 para 18. A DS3 do RFC 1233, de 15 para 30. As novas raízes de transmissão ficaram sob 1.3.6.1.2.1.10.

Essa correspondência não veio acompanhada de prazo, alias, fase de dupla resposta, negociação, conversor de gerenciadores nem regra para dados antigos. O RFC indicou o novo endereço normativo. A mudança real dependia das versões locais, da configuração, do lançamento e da preservação de registros.

O registro decide autoridade; a captura decide o que respondeu

O registro SMI da IANA ainda mostra GenericIF 12 e os números de transmissão 8, 9, 18 e 30. Algumas referências atuais apontam para RFCs posteriores, pois as definições continuaram a evoluir. O registro atual responde qual atribuição vale agora. O RFC 1239 preserva a decisão de transição. Nenhum dos dois substitui a observação de um agente.

Uma consulta sem resposta no novo OID pode indicar implementação antiga, objeto ausente, controle de acesso, indisponibilidade ou erro do coletor. Uma resposta no OID antigo comprova aquela resposta naquele momento, não a rejeição global da atribuição padrão. Ausência em um caminho não determina o estado do outro.

O mesmo cuidado vale para séries históricas. Trocar a chave numérica e manter o rótulo pode dividir uma série. Juntar automaticamente as duas pode esconder uma atualização simultânea de software ou semântica. O RFC 1239 não afirma que isso ocorreu. Ele fornece a razão para guardar OID exato, versões, horário, resposta, contexto de acesso, chave persistida e critério de união.

Mesmo uma fase de compatibilidade dupla precisa ser observada em cada resposta. A tabela não autoriza inferi-la. E um OID estável não congela o significado: documentos posteriores podem mudar estado, acesso ou interpretação sob a mesma raiz. Continuidade do identificador e continuidade semântica são provas diferentes.

Fontes