Resumo

  • A RFC 3936 inseriu Standards Action, Expert Review e Vendor Private em cada uma das três faixas comportamentais de Class-Num.
  • Um valor privado podia derrubar a mensagem inteira, desaparecer sozinho ou atravessar o nó intacto; “privado” descrevia a coordenação do número, não o efeito no fio.

A política documental acompanhava o código executável

RFC 2205 deu aos dois bits superiores de Class-Num uma função de compatibilidade. Classe desconhecida 0bbbbbbb fazia o nó rejeitar toda a mensagem e devolver erro. 10bbbbbb fazia descartar o objeto sem encaminhamento nem erro. 11bbbbbb fazia encaminhar o objeto sem exame e sem alteração. O registro oficial identifica a especificação; o octeto seleciona a execução.

RFC 3936, BCP 96 de outubro de 2004, criou três caminhos de autorização dentro de cada comportamento. Nas faixas de rejeição: 0–119, 120–123 e 124–127. Nas de descarte: 128–183, 184–187 e 188–191. Nas de transporte transparente: 192–247, 248–251 e 252–255. Em cada trio, vinham Standards Action, Expert Review e Vendor Private.

O atual registro de parâmetros RSVP da IANA preserva a matriz. O eixo institucional decide revisão e documentação. O eixo de bits decide o que um nó antigo fará. Um código 252 privado continua instruindo propagação por equipamento que não entende o conteúdo.

A página de RFC 3936 registra a atualização de RFC 2205 e RFC 3209; a página de errata permite verificar correções. A página de RFC 3209 documenta RSVP-TE, sem demonstrar implantação.

Reutilização não significava anonimato

Usos Vendor Private não eram registrados individualmente. O primeiro bloco de quatro octetos precisava trazer um SMI Private Enterprise Number da lista pública de números empresariais da IANA. Assim, empresas diferentes podiam reutilizar um código privado sem confundir seus formatos.

O identificador não autenticava remetente, equipamento ou conteúdo. Também não criava interoperabilidade. Se a implementação não reconhecesse o número empresarial, ainda obedeceria à regra externa de Class-Num.

Classe desconhecida não era C-Type desconhecido. No segundo caso, a classe era conhecida e a variante não; RFC 2205 em geral exigia rejeição da mensagem. Por isso RFC 3936 tornou a política de C-Type específica de cada classe e exigiu que novas classes definissem a regra futura.

EXPLICIT_ROUTE e RECORD_ROUTE tinham espaços próprios para subobjetos, também divididos entre padrão, revisão e privado. RFC 2207 contextualiza portas virtuais para fluxos IPsec; RFC 3473, extensões GMPLS. Um tipo de subobjeto não herdava automaticamente a lógica de Class-Num.

RFC 3936 ligou ainda a mudança de processamento à categoria do documento: entidade Standards Action exigia RFC Standards Track; entidade Expert Review, RFC Experimental. A linguagem contemporânea vinha de RFC 2434, mais tarde substituída por RFC 8126.

O registro comprova autorização, não código em operação. Os ensaios de Heng Lu sobre especificação mínima e adoção e sobre running code ajudam a separar publicação, implementação e uso.

O feito da RFC 3936 foi governar uma tabela cujo conteúdo já agia sobre máquinas ignorantes. O significado podia ser privado; a reação de compatibilidade era uma propriedade pública do protocolo.