Resumo

  • O Service Level Commitment da AFRINIC, identificado como Versão 1 de novembro de 2015, promete uma resposta efetiva em até dois dias úteis para todas as consultas dirigidas à equipe de Operações e apresenta doze filas nomeadas.
  • O diretório de suporte publica dezesseis classes de e-mail especializado. A página Contact Us mostra apenas Registry Queries, Technical Support e Media & Press, além de um formulário geral sem seleção visível de serviço.
  • Não há evidência, nessas páginas, de mensagem perdida, classificação errada ou descumprimento de prazo. O que falta é uma correspondência pública entre a porta usada, a fila responsável, o início do relógio e a preservação do primeiro horário após uma transferência.
  • Uma tabela curta e versionada permitiria manter a simplicidade do contato geral e a precisão dos especialistas, sem divulgar conteúdo de chamados, identidade de membros ou rotinas internas de segurança.

O pedido entra antes de ser classificado

Uma organização precisa ajustar um registro de DNS reverso. O responsável abre o site da AFRINIC e tenta encontrar a melhor forma de pedir ajuda. No compromisso de serviço, o assunto aparece sob Service support. No diretório de e-mails, há Account Info & Services, DNS and DNSSEC e DB-help. Na página de contato, a alternativa parece ser Technical Support ou um formulário livre.

Essa multiplicidade não é, por si só, um defeito. Um técnico experiente pode preferir o especialista. Um novo membro pode precisar de um canal amplo. O problema aparece quando o compromisso de dois dias úteis depende de uma classificação que o remetente não consegue relacionar às opções mostradas.

O Service Level Commitment da AFRINIC afirma que a equipe de Operações dará uma resposta efetiva, em até dois dias úteis, a todas as consultas que lhe forem dirigidas. O anexo separa o tempo de resposta do tempo de resolução: responder é reagir ao assunto levantado; resolver é concluir o caso desde o seu registro.

É uma diferença responsável. Nem toda solicitação de recursos, correção cadastral ou análise de segurança termina rapidamente. Uma primeira resposta ainda pode confirmar recebimento, atribuir responsabilidade e informar quais provas faltam. Mas a promessa só é verificável quando membro e registro reconhecem o mesmo evento de entrada.

Doze filas definem o vocabulário do compromisso

O documento traz a marca “Version 1 | November 2015”. Ele abrange serviços de registro e atendimento, bases e serviços públicos, DNS reverso, cobrança e infraestrutura. A seção de resposta a consultas contém doze linhas preenchidas.

São elas: How to Become a Member; Membership application Evaluation; Hostmaster; Billing; Service support; Service Infrastructure Maintenance; RPKI Support; DNS & DNSSEC support; Routing Registry; Website information; Complaint report; e Complaint escalation.

As descrições esclarecem parte da divisão. Hostmaster cobre pedidos de recursos adicionais e dúvidas sobre a gestão de recursos IP. Service support inclui DNS reverso, certificado BPKI, MyAFRINIC, Whois e erros na criação ou alteração de objetos. RPKI, DNS e o registro de rotas recebem linhas próprias.

A posição dessa tabela é importante. Ela está dentro da cláusula que anuncia os dois dias úteis. Portanto, suas categorias funcionam como o vocabulário público da obrigação, mesmo que a organização interna tenha mudado depois.

O capítulo sobre reclamações acrescenta uma sequência. Uma reclamação recebida por telefone ou e-mail deve obter resposta em dois dias úteis, excluídos os feriados observados nas Maurícias. Se o resultado não satisfizer o remetente, ele pode escalar o assunto, apresentar as informações úteis e incluir o número do chamado. A reclamação escalada recebe a mesma declaração de prazo para resposta.

Isso não garante uma solução favorável, nem promete encerrar o caso em dois dias. Garante, no texto, duas etapas de resposta ligadas por um identificador. A descoberta do canal atual para iniciar essa cadeia deveria ser igualmente explícita.

Dezesseis contatos organizam a especialização

O diretório de e-mails de suporte oferece outro mapa. A AFRINIC explica que assuntos diferentes exigem conhecimentos específicos e que endereços separados ajudam a impedir que uma consulta passe despercebida. É uma boa justificativa para especialização.

A lista contém dezesseis rótulos: Hostmaster/IP Resources, Billing, Account Info & Services, Routing Registry, DB-help, Prospective Members, Training, Outage, Fellowship, Fellowship Alumni, General, Escalation, RPKI, DNS and DNSSEC, Data Protection e IT security/Responsible disclosure.

Algumas equivalências parecem prováveis. Account Info & Services lembra Service support. Outage pode alimentar Service Infrastructure Maintenance. Prospective Members pode reunir as duas etapas de adesão. RPKI, DNS e Routing Registry quase repetem os nomes do compromisso.

Ainda assim, uma aproximação linguística não é uma regra operacional. O documento de serviço tem Complaint report e Complaint escalation; o diretório tem Escalation, mas não mostra uma linha com o nome da reclamação inicial. Website information não reaparece. Em sentido contrário, treinamento, bolsas, privacidade e divulgação responsável entram apenas no diretório.

Isso não significa que existam vinte e oito filas reais. Um endereço pode ser um alias. Duas caixas podem alimentar o mesmo sistema. Uma triagem humana pode preservar perfeitamente a data original. O conjunto público simplesmente não informa qual dessas arquiteturas está em vigor.

A página principal comprime tudo em três opções

A página Contact Us prefere reduzir a escolha. Seu quadro Support Emails mostra três destinos nomeados: Registry Queries, Technical Support e Media & Press. Em seguida, oferece um formulário para perguntas sobre adesão, alocação de endereços IP ou registro de rotas BGP.

Uma porta ampla poupa o visitante da obrigação de conhecer termos internos. Alguém que iniciou o processo de adesão talvez não saiba se está buscando informações ou acompanhando avaliação. Uma questão de BGP pode tocar IRR, Whois ou RPKI. A simplificação reduz desistências e erros iniciais.

O formulário geral pede nome, endereço de e-mail, assunto e mensagem. Não apresenta um seletor visível com as doze filas ou as dezesseis especialidades. O assunto livre pode bastar para a equipe classificar corretamente. O servidor também pode acrescentar informações que não aparecem para o usuário.

Nenhuma mensagem de teste foi enviada para esta análise, e nenhum sistema interno foi acessado. Assim, não há base para avaliar a qualidade da triagem. A observação é sobre o contrato visível: a pessoa não vê qual fila receberá o formulário, qual evento inicia o relógio e como o horário será tratado se o pedido mudar de equipe.

A transferência decide de quem é o tempo

Quando o remetente acerta o especialista de primeira, as diferenças de rótulo podem não produzir efeito. O caso revelador é o pedido que precisa ser transferido.

Considere uma dúvida de cobrança enviada a Technical Support. A equipe geral confirma rapidamente o recebimento e encaminha para Billing. O suporte pode medir desde a chegada inicial; Billing pode medir desde a atribuição interna; o membro mede desde o envio ao endereço publicado. Os três registros podem estar corretos e ainda assim representar relógios diferentes.

Uma reclamação torna essa divergência mais importante. O SLC pede o número do chamado na escalada, mas a página principal não oferece uma opção chamada Complaint report. Se o caso começa no formulário e depois segue ao e-mail de Escalation, o público não sabe se o número original e o primeiro horário acompanham a transição.

Não se pode concluir que o relógio reinicia. Também não se pode verificar que ele permanece. Essa é a lacuna: a regra temporal depende de dados internos que apenas uma das partes controla.

Uma correspondência pública resolve o problema

A AFRINIC não precisa substituir seus canais. Precisa publicar a tradução entre eles.

Uma linha da tabela poderia começar com o pedido em linguagem comum: tornar-se membro, pedir recursos, atualizar cadastro, consultar cobrança, alterar Whois, operar DNS reverso, usar IRR, mudar uma ROA, informar indisponibilidade, reclamar, escalar, exercer direito de dados ou divulgar vulnerabilidade.

As colunas seguintes indicariam o endereço ou formulário vigente e a fila do SLC responsável. Para o canal geral, a tabela mostraria os destinos possíveis e alguns exemplos. Para segurança, seria suficiente confirmar o contato especializado sem expor o método de tratamento.

Depois viria a regra do tempo. Qual evento é o recebimento oficial? O aviso automático confirma esse momento? Qual calendário de dias úteis se aplica? Uma transferência preserva o primeiro horário? Qual objetivo se refere à primeira resposta? Como a resolução é medida separadamente?

O mesmo registro apresentaria o canal alternativo, a entrada de reclamação e o caminho de escalada. Se um e-mail recusar a mensagem ou o formulário estiver indisponível, o remetente saberia qual substituto tem efeito equivalente. O número do chamado conectaria cada etapa.

Por fim, a tabela teria versão, data de vigência, função responsável e histórico de mudanças. Um endereço poderia ser alterado sem confusão, desde que a transição registrasse o destino anterior, o novo e o tratamento das mensagens em curso.

Não seria necessário divulgar nomes de funcionários, textos de chamados, recursos numéricos, faturas ou controles de cibersegurança. A correspondência descreve apenas a fronteira pública entre enviar uma solicitação e colocá-la sob a promessa de resposta.

Evidência agregada sem expor casos

Com classes estáveis, a AFRINIC poderia informar, por mês, entradas, transferências, primeiras respostas dentro do objetivo, estoque aberto e faixas de idade. Reclamações e escaladas poderiam aparecer como quantidades e distribuições de tempo.

Categorias sensíveis ou com poucos casos deveriam ser agrupadas ou omitidas para impedir identificação. Transparência não exige revelar quem pediu o quê. Exige demonstrar que a porta anunciada e a unidade medida são a mesma.

Uma média geral não basta. Muitas respostas rápidas podem esconder poucos casos antigos. Uma taxa de cumprimento pode melhorar artificialmente se cada transferência abrir um novo cronômetro. A data original e a regra de transferência precisam vir antes da estatística.

O benefício gerencial é direto. Uma classe com muitas reclassificações indica que o nome público talvez seja confuso. Um estoque envelhecido em uma especialidade aponta outra necessidade. Reclamações concentradas após transferências sugerem um problema de comunicação que não é idêntico à dificuldade técnica.

O que não foi demonstrado

As quatro páginas não mostram uma consulta perdida, ignorada, mal encaminhada ou respondida fora do prazo. Nenhum formulário foi testado, nenhuma conta de membro foi usada e nenhum chamado interno foi lido. Os contatos amplos podem distribuir todas as mensagens corretamente.

A identificação de 2015 também não torna o compromisso inválido. As páginas estavam acessíveis na data de observação. O cabeçalho técnico de modificação pode registrar a publicação do site, e não uma revisão substantiva da política.

Por último, dois dias são um prazo de resposta, não de resolução. A tabela proposta deve reforçar essa separação: conservar o primeiro recibo e acompanhar o problema aberto, em vez de transformar toda questão complexa em promessa de encerramento imediato.

Fontes