Resumen

  • El compromiso de nivel de servicio de AFRINIC, identificado como Versión 1 de noviembre de 2015, ofrece una respuesta efectiva en dos días laborables para las consultas dirigidas al equipo de Operaciones y enumera doce colas.
  • El directorio de asistencia publica dieciséis clases de correo especializado. La página Contact Us reduce la elección visible a Registry Queries, Technical Support y Media & Press, además de un formulario general sin selector de servicio.
  • Las diferencias no demuestran que se haya perdido un mensaje ni que se haya incumplido un plazo. Sí impiden comprobar públicamente qué cola recibe cada entrada, cuándo arranca el reloj y si una reclasificación conserva la hora original.
  • Una tabla pública y versionada puede mantener las vías generales y especializadas: tipo de solicitud, dirección vigente, cola responsable, evento de recepción, regla de transferencia, canal alternativo y escalado.

El tiempo se puede prometer; la entrada también debe poder señalarse

Dos días laborables parecen una medida inequívoca. El problema aparece un paso antes. Para cronometrar una respuesta hace falta decidir qué acontecimiento inicia la cuenta: el envío del formulario, la llegada al correo anunciado, la creación de un ticket, el traslado a un especialista o la primera lectura humana.

El Service Level Commitment de AFRINIC no es ambiguo sobre la clase general de obligación. La página se identifica como Versión 1 de noviembre de 2015 y afirma que el equipo de Operaciones se compromete a dar una respuesta efectiva a todas las consultas que se le dirijan en un plazo de dos días laborables. Su anexo distingue entre el tiempo de respuesta y el tiempo de resolución completa.

Esa distinción protege una expectativa realista. Una solicitud de recursos puede requerir documentos. Una corrección de facturación puede exigir comprobaciones. Un incidente de RPKI puede necesitar trabajo técnico antes de quedar cerrado. La primera respuesta no resuelve necesariamente el asunto, pero debe decir que alguien lo ha recibido y qué falta para avanzar.

La dificultad no está en la definición final, sino en la unión con los canales actuales. AFRINIC publica tres maneras de describir la puerta. Las tres pueden funcionar bien. Lo que no publica es la equivalencia temporal entre ellas.

El primer mapa habla de doce colas

Debajo de la promesa de dos días, el documento de servicio enumera doce filas con nombre: 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 y Complaint escalation.

Las descripciones permiten entender bastante. Hostmaster se ocupa de recursos adicionales y de consultas generales sobre su administración. Service support incorpora DNS inverso, certificados BPKI, MyAFRINIC, Whois y determinados errores al crear o modificar objetos. RPKI, DNS y el registro de rutas aparecen como competencias diferenciadas.

La colocación importa. No es una lista cualquiera situada en una página lejana. Es el cuadro que el propio compromiso usa para explicar la respuesta a consultas y solicitudes. Por eso es razonable interpretar que esas doce categorías son el lenguaje con el que se organiza la promesa.

El capítulo de reclamaciones aporta otro dato. AFRINIC dice que responderá en dos días laborables, sin contar los festivos observados en Mauricio, a una reclamación recibida por teléfono o correo. Si la persona sigue insatisfecha, puede escalar el caso, explicar que desea hacerlo y adjuntar la información útil, incluido el número del ticket. El escalado recibe la misma declaración de respuesta en dos días.

No hay aquí una obligación de resolver a favor de quien reclama. Tampoco una garantía de cierre en dos días. Hay una secuencia documental: consulta, ticket, reclamación, escalado. La continuidad del identificador y de la fecha es lo que permite saber si la secuencia se está siguiendo.

El segundo mapa clasifica dieciséis especialidades

En su directorio de correos de asistencia, AFRINIC explica por qué usa varias direcciones. Cada materia puede requerir conocimientos particulares y la separación pretende que ninguna consulta pase inadvertida. Para una institución técnica, esa especialización tiene sentido.

El directorio ofrece dieciséis etiquetas: 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.

Algunas parejas parecen evidentes. Account Info & Services puede ocupar el terreno que el compromiso denomina Service support. Outage puede conducir a Service Infrastructure Maintenance. Prospective Members puede reunir parte de las dos colas de adhesión. Pero una semejanza semántica no prueba una identidad operativa.

También hay huecos y añadidos. El compromiso nombra Complaint report; el directorio muestra Escalation, pero no una fila con el nombre exacto de reclamación inicial. Website information no reaparece con esa etiqueta. A la inversa, formación, becas, privacidad y divulgación responsable amplían el directorio más allá del cuadro de 2015.

Nada de esto demuestra que existan veintiocho colas distintas. Las direcciones pueden ser alias. Una sola bandeja puede dividirse por reglas. Dos nombres pueden representar la misma responsabilidad. La observación comprobable es más modesta: las páginas públicas no dicen cuál de esas interpretaciones es la correcta.

El tercer mapa pide elegir entre tres categorías amplias

La página de contacto adopta una estrategia diferente. Su bloque de asistencia muestra tres destinos con nombre: Registry Queries, Technical Support y Media & Press. Después dirige al visitante a un formulario para cuestiones de afiliación, asignación de direcciones IP o registro BGP.

Es una simplificación defendible. La persona que acaba de iniciar una solicitud de membresía quizá no sepa si su caso ya está en evaluación. Un operador puede no tener claro si un cambio relacionado con el enrutamiento pertenece a Whois, IRR o RPKI. Un acceso general evita que la institución convierta su propia terminología en una barrera.

El formulario general de AFRINIC solicita nombre, correo, asunto y mensaje. No presenta un desplegable que asigne públicamente el caso a una de las doce colas o a una de las dieciséis especialidades. Un asunto bien escrito puede bastar para la clasificación interna. El sistema puede añadir datos que el formulario no muestra. Este análisis no envió una prueba ni accedió a herramientas internas.

Desde el lado del remitente queda una duda verificable. Si elige Technical Support y su problema acaba en Billing, ¿el plazo se mide desde el primer correo o desde la recepción en Facturación? Si utiliza el formulario para un asunto del IRR, ¿qué etiqueta aparecerá en el acuse? Si la dirección amplia responde para pedir que se reenvíe el mensaje al especialista, ¿se conserva el primer tiempo?

Las páginas no afirman que el reloj se reinicie. Tampoco afirman que se conserve. El déficit es esa ausencia de regla pública.

La transferencia es donde dos versiones honestas pueden divergir

Una institución puede medir con exactitud desde la entrada en la cola especializada. Un miembro puede medir con la misma exactitud desde el canal que la institución le mostró. Si no hay una regla de enlace, ambos cronómetros producen cifras correctas sobre acontecimientos distintos.

Esto se vuelve más delicado en una reclamación. El compromiso pide un número de ticket para escalar, pero la página de contacto no enseña una opción llamada Complaint report. Quien empiece por el formulario quizá reciba un identificador adecuado; quizá el traslado genere otro. No hay base para suponer ninguno de los dos resultados.

La consecuencia no tiene por qué ser una espera larga. Puede ser únicamente una discusión posterior sobre cuándo se consideró recibida la solicitud. Sin una fecha común, la organización no puede demostrar fácilmente que cumplió y el miembro no puede explicar con precisión su experiencia.

El diseño correcto trataría el traslado como una operación interna. La clasificación inicial puede cambiar; el recibo original no debería desaparecer sin una regla expresa. Si ciertas entradas tienen objetivos distintos, la diferencia debe anunciarse en el momento de escogerlas.

Una tabla corta puede unir los tres mapas

El artefacto que falta no es un nuevo portal. Es una tabla pública de correspondencias con versión y fecha.

Cada fila describiría una necesidad en lenguaje normal: ser miembro, solicitar recursos, consultar una factura, actualizar los datos de una cuenta, corregir Whois, administrar DNS inverso, utilizar IRR, modificar RPKI, informar de una interrupción, presentar una reclamación, escalarla, ejercer derechos de datos o comunicar una vulnerabilidad.

La misma fila indicaría la dirección o el formulario vigente y la cola del compromiso a la que se vincula. Para una entrada general, podría enumerar las especialidades de destino. Para una dirección sensible, como la divulgación responsable, bastaría con confirmar la vía sin revelar criterios de manejo.

Después vendría la regla del reloj: qué evento confirma la recepción, qué calendario laboral se emplea, si la transferencia conserva la hora inicial, y qué plazo corresponde a la primera respuesta. La resolución tendría un campo separado. Así se evitaría que una contestación rápida y un problema abierto aparezcan como el mismo resultado.

Por último, la tabla nombraría el canal alternativo, el punto de reclamación y el de escalado. Vincularía todos los estados mediante el número de ticket. Un responsable funcional, una fecha de vigencia y un historial de cambios mostrarían cuándo se sustituyó una dirección o una categoría.

AFRINIC no tendría que publicar nombres de empleados, mensajes de miembros, configuraciones de correo ni procedimientos de seguridad. La tabla describiría el contrato visible entre enviar una consulta y colocarla bajo una promesa de servicio.

Un mínimo de datos agregados cerraría el círculo

Una correspondencia sin evidencia puede quedarse en documentación. Para mostrar que funciona, AFRINIC podría publicar por mes el número de entradas, la proporción transferida, las primeras respuestas dentro del objetivo, el stock todavía abierto y su antigüedad por intervalos.

Esos agregados pueden excluir o agrupar materias de poco volumen. No necesitan revelar la identidad, los recursos, las facturas ni las vulnerabilidades de nadie. El propósito es saber si la puerta pública y la cola contabilizada forman la misma unidad.

Conviene evitar el promedio único. Una media rápida puede ocultar unos pocos casos antiguos. Un porcentaje de cumplimiento puede mejorar si cada traslado inicia una nueva cuenta. Por eso el primer recibo y la regla de transferencia son anteriores a la estadística.

Un registro así beneficia también a la institución. Le permite saber qué nombres generan más reclasificaciones, qué página dirige mal al público y qué clase concentra trabajo sin resolver. La transparencia no consiste sólo en fiscalizar; también reduce el coste de administrar una nomenclatura fragmentada.

Límites de lo observado

No se ha localizado un caso de mensaje perdido, cola equivocada o respuesta tardía. No se envió un formulario, no se obtuvo una cuenta de miembro y no se inspeccionó ningún ticket. Las tres vías generales pueden alimentar sin problemas todas las especialidades.

La fecha de 2015 no demuestra que el compromiso esté abandonado. Las páginas seguían publicadas en la fecha de corte. Los encabezados técnicos de modificación tampoco establecen cuándo se revisó la taxonomía. La conclusión se limita al registro público: no hay un cuadro versionado que una los nombres.

Responder sigue sin ser resolver. La propuesta no convierte dos días laborables en garantía de solución. Sólo hace comprobable el punto en el que empieza el deber de responder y la continuidad de ese punto cuando AFRINIC cambia el destino interno.

Fuentes