Resumo

  • O SLA proposto cobre desempenho e disponibilidade de sistemas, não desempenho da Tools Team nem agendamento e planejamento de seu trabalho.
  • A consulta de UX examina interfaces, acessibilidade, controles de acesso, requisitos de clientes e usos pela Web, CLI, plugins, API, MCP e modo offline; desempenho fica no processo paralelo.
  • Um recibo público e versionado pode registrar feedback, serviço, métrica, exclusões, autoridade decisória, responsável pela execução, prioridade, prazo e revisão, mantendo estados distintos para SLA e UX.

A coincidência de datas não cria uma única competência

Em 17 de setembro de 2026, a IETF LLC pediu comentários sobre duas dimensões das ferramentas da IETF. As duas consultas terminam em 12 de outubro e aceitam respostas privadas ao Board e ao Executive Director ou discussão pública na lista tools-discuss. A porta de entrada é comum; o objeto não.

O texto do SLA organiza comportamento observável. Propõe metas de disponibilidade, resposta Web, demora de e-mail e resposta a incidentes, além de níveis de criticidade, pesos para degradação parcial, exclusões, relatórios mensais e revisão anual. Ele procura converter a tradição de “best efforts” em uma expectativa mensurável para os sistemas.

O texto de experiência trata de caminhos de uso. Mapeia Web, linha de comando, plugins, API, Model Context Protocol e operação offline. Pergunta sobre acessibilidade, autenticação, requisitos do cliente, URLs estáveis e personalização. Desempenho de sistemas é excluído porque já está na consulta do SLA.

A fronteira define o valor probatório de cada resultado. Disponibilidade pode mostrar o comportamento de um serviço em um ponto e intervalo definidos. Não mede automaticamente a qualidade do trabalho da equipe e não escolhe quais tarefas devem entrar primeiro no plano. Uma decisão de UX pode reconhecer um modo de uso sem provar que a infraestrutura correspondente já cumpre um objetivo.

O relógio do serviço

O próprio rascunho impede a ampliação indevida: desempenho da Tools Team e agendamento ou planejamento do trabalho estão fora do SLA. Esses temas podem ser debatidos em outro lugar, mas não podem ser inferidos de uma falha ou de um percentil.

No escopo correto, a proposta é detalhada. Monitoramento automatizado serviria de referência. Indisponibilidade completa teria peso 1; degradação grave, 0,5; menor, 0,25; defeito apenas visual, zero. Serviços críticos teriam tratamento diferente de sistemas de menor impacto ou operados por terceiros. O tempo Web seria medido no servidor, sem renderização do cliente, rede do usuário e certas dependências externas.

As exclusões precisam acompanhar a pontuação. Manutenção programada, falhas de terceiros, força maior, aparelho ou rede do usuário e mitigação de segurança deliberada não entram da mesma forma. Manutenção emergencial e efeitos de abuso ou tráfego excessivo não somem automaticamente. Sem o denominador e o motivo da exclusão, o número perde responsabilidade.

O mecanismo também não é uma multa. Uma meta perdida aciona revisão e melhoria. O documento reconhece uma equipe pequena e distribuída, trabalhando em horário normal, e pergunta se a comunidade aceita esse modelo ou prefere financiar outra capacidade. Isso é uma escolha de serviço e investimento, não uma nota de produtividade.

Há ainda uma limitação histórica: os dados monitorados ficam apenas sete dias e não são exportados regularmente. Isso impede análise retrospectiva e reforça a necessidade de observação durável. Não autoriza afirmar que as ferramentas estejam falhando hoje.

O relógio da experiência

O problema de UX é diferente. As ferramentas cresceram organicamente e muitas decisões de interface ficaram com desenvolvedores. O novo rfc-editor.org recebeu apoio especializado, mas faltava um processo formal para ouvir a comunidade sobre todo o conjunto.

As perguntas envolvem preferência e desenho: mais CLI ou uso offline, dependência aceitável de JavaScript, alcance do login único e do autoatendimento, possível acesso por IA ou MCP e uso de especialistas em acessibilidade. Cada resposta pode gerar trabalho operacional, porém não é uma meta de disponibilidade.

Um pacote offline pode exigir sincronização e manutenção. Autenticação adiciona dependências. API e MCP alteram volume e podem justificar chaves ou limites. Acessibilidade muda a estrutura do cliente sem necessariamente mover o tempo do servidor. O efeito deve ser medido depois que a escolha é feita, não usado para escolher por ela.

Um recibo para os pontos de passagem

A política de participação comunitária da IETF LLC já determina que feedback seja acompanhado, incorporado ou respondido com a razão de não incorporação, e que a decisão seja comunicada. A lacuna prática é tornar visível a travessia entre os dois processos.

Cada item relevante deveria ter um recibo versionado com: conteúdo do feedback; serviço ou modo de uso aplicável; métrica e ponto de medição; exclusões; autoridade que decide; responsável por implementar; prioridade e estado de prazo; e relatório ou revisão futura. Itens relacionados ganham referências recíprocas, não um estado único.

Uma solicitação de acesso offline em reuniões ilustra o modelo. O registro UX mostra aceitação, rejeição ou adiamento, autoridade e opção de produto. O registro de serviço identifica conjunto de dados, sincronização ou imagem de contêiner, onde será medido e quais dependências ficam fora. Aceitar a necessidade não significa cumprir a meta; cumprir uma meta não significa entregar a experiência.

Versões preservam a ordem dos atos. A escolha pode vir antes do orçamento; uma implementação pode alterar carga e exigir nova meta. O histórico deve mostrar quem autorizou cada mudança, quando e com qual alcance.

Não é uma fila-mestra para todas as tarefas. É uma trilha de transferências. Serviço continua sendo serviço, experiência continua sendo experiência e planejamento mantém seu processo próprio.

Fontes