Resumo

  • Em 3 de setembro de 2026, a IESG concluiu que a revisão 12 de Safe-IOC não conflitava com trabalhos da IETF. Isso não foi endosso técnico, consenso da IETF nem aprovação para o Standards Track.
  • As revisões 13 e 14 vieram depois. Diferenças públicas mostram várias sugestões do ballot refletidas no texto, e o histórico registra ISE, IANA e produção RFC. Ainda não existe um mapa público completo de cada comentário para uma decisão atribuível e para os bytes alterados.
  • Um recibo de versão e disposição deveria guardar hash e data da revisão examinada, resposta RFC 5742, IDs de comentários, razões do ISE, hunks de implementação, estados IANA/RPC e o futuro número e boilerplate do RFC.

O parecer ficou na revisão 12

O anúncio da IESG identifica draft-grimminck-safe-ioc-sharing-12. Ele diz que não há problema com a publicação como RFC Informational e que não existe conflito com trabalho da IETF. Em seguida, separa outra decisão: o Independent Submissions Editor deve avaliar os comentários no ballot e no histórico e decidir se merecem incorporação.

São estados diferentes. A análise de conflito terminou para a revisão 12. Os comentários técnicos ficaram com o ISE. O Independent stream pôde avançar. Nenhum RFC havia sido publicado.

A página atual aponta para a revisão 14 e ainda descreve um active individual Internet-Draft do Independent Submission stream, com status pretendido Informational. A identidade sobreviveu; os bytes e a posição no processo mudaram.

RFC 5742 não transforma ausência de conflito em aprovação

O RFC 5742 define cinco tipos de conclusão. Aqui foi usada a primeira e mais estreita: nenhum conflito com trabalho da IETF. O texto também explica que documentos de streams não IETF em geral não recebem consenso IETF ou aprovação IESG; após um resultado sem conflito, o RFC Editor continua responsável por mérito técnico e possível dano à Internet.

Essa divisão evita dois atalhos. A IESG não amplia a verificação de conflito para uma revisão técnica completa. O ISE não substitui seu próprio julgamento pelo parecer da IESG. “No problem with publication” remove um obstáculo específico; não recomenda a especificação em nome da IETF.

A pergunta do ballot era se a resposta de conflito proposta estava correta. No corte havia dois Yes e oito No Objection. Essas posições não são votos técnicos sobre cada regra, vetor de teste ou alegação de segurança.

O texto mudou; a decisão item a item não apareceu

Mohamed Boucadair concordou com a resposta e sugeriu quatro ajustes: citar RFC 9424; evitar que “safe” implique risco zerado; distinguir prefixos de endereços; e incluir formas IPv4 embutidas em IPv6 de RFC 6052. Éric Vyncke registrou uma observação curta sobre a quantidade de conteúdo IPv6.

A revisão 13 surgiu após o anúncio. O histórico e o diff 12–14 mostram correspondências: “a safe obfuscation format” virou “an obfuscation format”; RFC 9424 foi incluído; a linguagem CIDR passou a falar de prefixos; RFC 6052 e dois testes entraram; Boucadair foi acrescentado aos agradecimentos.

Isso permite dizer que o texto posterior reflete as sugestões. Não permite afirmar uma disposição formal para cada item. Um diff não revela se o ISE aceitou o ponto literalmente, o combinou com outra revisão ou promoveu a mesma mudança por outro motivo.

A revisão 14 trouxe mais alterações: o termo “defanging”, ajustes na gramática de hosts e nas referências ao RFC 1035, dois SHOULD convertidos em orientação comum e um alerta sobre ambiguidade de tokens em Path, Query ou Fragment. A trilha pública não liga cada mudança a um ID e a uma decisão de aceitar, rejeitar ou aceitar parcialmente.

Estar na fila ainda não é ser RFC

Em 9 de setembro, a revisão 14 foi enviada e o ISE a encaminhou ao RFC Editor. IANA passou por In Progress e chegou a No IANA Actions em 16 de setembro. A produção RFC ficou bloqueada por Author Input Required e voltou a In Progress. O histórico RPC depois avançou de referência/formatação para aguardar designação de editor.

O XML oficial da fila ainda lista a revisão 14 no ISE stream, recebida em 9 de setembro, com ref_checker. Datatracker e fila são projeções diferentes; nenhuma delas autoriza a palavra “aprovado”. Não havia número RFC final.

O processo de Independent Submissions separa revisões repetidas, decisão inicial de publicação, entrega ao RPC, AUTH48 e publicação. O ISE pode desistir antes da liberação como RFC. A fila prova custódia e trabalho, não um objeto final publicado.

O recibo de transferência

O recibo começaria ligando hash e data exatos da revisão 12 à resposta RFC 5742. Cada comentário teria ID estável, autor, hash do texto e origem. O ISE registraria accepted, rejected ou partially accepted com justificativa. Um item aceito apontaria para a primeira revisão de implementação e para o hunk exato.

A cadeia continuaria com o resultado IANA, causa e liberação de bloqueios RPC, responsável, número RFC, boilerplate do stream e futuros errata ou substitutos. Um comentário apenas consultivo continuaria consultivo; uma mudança nascida em outra revisão não seria creditada retroativamente ao ballot.

A separação também limita promessas de segurança. Uma convenção textual reversível pode reduzir ativação acidental, mas não valida malícia, atualidade ou atribuição de um indicador. Proveniência do documento e proveniência do IOC são evidências distintas.

Fontes