Resumo

  • Em 28 de agosto, a IESG anunciou a conclusão do Security Dispatch, o fechamento de sua lista e a incorporação de sua função ao DISPATCH, agora responsável por ART, SEC e pelos temas não relacionados a transporte em WIT.
  • A continuidade institucional exige um registro por proposta: versão examinada, discussão antiga, texto do resultado, estado do consenso, classe de autoridade, destino, responsável seguinte e requisito para uma nova apresentação.

A porta mudou, a área de Segurança não fechou

O comunicado indica Christopher Inacio e Deb Cooley como contatos da IESG e afirma que a área de Segurança continua incentivando o envio de novas ideias. O encerramento atinge o grupo separado e sua lista, não o direito de propor trabalho técnico.

O destino já tinha uma carta aprovada. Desde 2 de julho, o DISPATCH cobre novas propostas em ART, SEC e na parte não ligada a transporte de WIT. Uma reunião interina conjunta em 30 de junho e uma sessão única no IETF 126 mostram que o arranjo comum começou a operar antes do aviso formal de fechamento.

Há uma boa justificativa para a consolidação. Propostas sobre identidade, mensagens ou aplicações web podem atravessar várias áreas. Um ponto de entrada compartilhado diminui o custo de adivinhar a estrutura interna da IETF e pode revelar sobreposição técnica mais cedo.

Esse ponto de entrada, porém, não aprova padrões. A carta permite indicar um grupo existente, recomendar um BoF, ajudar a redigir a carta de um novo grupo, sugerir possível patrocínio por um Area Director, criar uma lista de discussão, adiar ou rejeitar. A orientação não é vinculante. Se as presidências não conseguirem determinar consenso, não há garantia de uma resposta. Com exceção de documentos administrativos estreitos aceitos pelos diretores competentes, o DISPATCH não desenvolve documentos.

A reunião conjunta deixou estados incompatíveis entre si

Participaram cerca de cinquenta pessoas da reunião interina de 30 de junho. Depois dela, as presidências publicaram seis resultados e pediram que as listas contestassem qualquer leitura incorreta de consenso aproximado.

Uma proposta poderia seguir ao Independent Submission Editor por escolha do autor; o registro esclareceu que isso não era uma ação do Dispatch. Duas não tiveram apresentação. Uma recebeu “nenhuma ação para a IETF”. Outra ficou sem ação naquele momento e precisava demonstrar mais interesse independente de implementação e encontrar um espaço de discussão. Uma quinta foi encaminhada ao BoF DAWN e ao trabalho de organização correspondente.

Essas situações não cabem na etiqueta “resolvido”. Ausência de apresentação não é rejeição técnica. Falta de ação naquele momento não é proibição permanente. Encaminhamento a BoF não é criação de grupo nem aprovação de especificação. Se a fusão preservar apenas o título do assunto, uma recomendação administrativa poderá ganhar uma autoridade que nunca teve.

O RFC 7957 define o limite: um grupo do tipo DISPATCH avalia e localiza trabalho novo, mas não o conclui. Pode registrar por que uma iniciativa não avançou. Em casos limítrofes, Area Directors e presidências responsáveis escolhem o local adequado. O RFC 2418 permite que o diretor, em consulta com o grupo, reformule a carta, escolha novas presidências ou dissolva o grupo quando tarefas ou premissas mudam, preservando recurso à IESG.

O registro deve transferir significado, não criar direitos

No corte desta apuração, o arquivo público do SECDISPATCH continuava acessível e mostrava 1.699 mensagens. Isso não garante disponibilidade permanente, mas também não sustenta uma alegação de perda.

Um registro público deveria ligar cada proposta materialmente tratada ao identificador estável e à versão do Internet-Draft, ao último fio relevante, à reunião, ao resultado literal, à confirmação ou não do consenso e à classe de autoridade. Também deveria mostrar o destino, quem possui a próxima ação, a condição de retorno, o estado na data da fusão, o arquivo sobrevivente e qualquer decisão posterior do DISPATCH. Correções precisam acrescentar versão, data e responsável sem apagar o registro anterior.

Esse mecanismo não reservaria espaço de agenda nem daria direito a reconsideração. Ele impediria que resumo das presidências, consenso aproximado do grupo, decisão de Area Director e escolha autônoma do proponente fossem confundidos.

A referência processual aponta para o RFC errado

O aviso de conclusão diz que novas ideias continuam bem-vindas “segundo o RFC7975”. O RFC 7975 especifica uma interface de redirecionamento para interconexão de redes de distribuição de conteúdo. A carta aprovada do DISPATCH cita o RFC 7957, que trata de grupos do tipo DISPATCH.

Não há indício de que o erro de um algarismo tenha alterado a fusão ou qualquer encaminhamento. Ainda assim, uma correção ou nota é necessária. O aviso de conclusão será usado como ligação entre o grupo antigo e o procedimento sucessor.

As fontes não demonstram proposta abandonada, desaparecimento futuro do arquivo, força vinculante de orientação antiga nem direito a nova audiência. A página de materiais do IETF 126 não exibia ata no momento da consulta, o que não prova inexistência de outro registro. O modelo de transição é uma recomendação de Daniel Kade, não um compromisso anunciado pela IETF.

Fontes