Resumen

  • El SLA propuesto se limita al rendimiento y la disponibilidad de los sistemas. Excluye expresamente el desempeño del Tools Team y la programación o planificación de su trabajo.
  • La consulta de UX pregunta por interfaces, accesibilidad, controles de acceso, requisitos del cliente y modos Web, CLI, plugin, API, MCP y sin conexión; deja el rendimiento a la consulta paralela.
  • Un comprobante público y versionado puede enlazar ambos procesos si identifica el servicio, la métrica, las exclusiones, la autoridad decisora, el responsable de ejecutar, el estado temporal y la vía de revisión de cada comentario.

Dos consultas no forman una sola promesa

El 17 de septiembre de 2026, IETF LLC abrió dos consultas sobre las herramientas de la IETF. Ambas terminan el 12 de octubre y permiten responder en privado al Board y al Executive Director o en público mediante tools-discuss. Coinciden en calendario y canales, no en el objeto de la decisión.

El documento del SLA propone objetivos observables para disponibilidad, respuesta web, demora del correo y gestión de incidentes. Clasifica servicios, pondera degradaciones parciales, define exclusiones y prevé informes mensuales y una revisión anual. Su función es transformar expectativas de «mejor esfuerzo» en medidas de sistema.

La consulta de experiencia examina otra cuestión: cómo debería poder trabajar la comunidad. Recorre la web, la línea de comandos, plugins, API, MCP y modos sin conexión; pregunta por accesibilidad, autenticación, requisitos de navegador y cliente, URL estables y personalización. Excluye el rendimiento porque ese asunto está en el proceso del SLA.

De esa división depende el significado de los resultados. Una cifra de disponibilidad puede demostrar qué ocurrió en un servicio y punto de medición. No evalúa por sí sola al equipo ni decide prioridades o fechas de desarrollo. Del mismo modo, aceptar una necesidad de uso no demuestra que el sistema asociado cumpla un objetivo operativo.

El alcance de la medición

El proyecto afirma sin ambigüedad que el SLA no cubre el rendimiento del Tools Team ni la programación y planificación de su trabajo. Puede haber razones para discutirlos, pero no para deducirlos de un porcentaje de servicio.

En su terreno propio, la propuesta es minuciosa. El monitoreo automatizado sería la referencia de disponibilidad. Una caída total pesaría 1; una degradación grave, 0,5; una menor, 0,25; y un defecto cosmético, cero. Los servicios se separarían por criticidad. El tiempo web se tomaría del lado del servidor y dejaría fuera la renderización del cliente, la red del usuario y dependencias externas definidas.

También se debe conservar la lista de exclusiones. Mantenimiento programado, fallos de terceros, fuerza mayor, dispositivo o red del usuario y mitigaciones de seguridad deliberadas quedarían fuera. El mantenimiento de emergencia y las interrupciones por abuso o tráfico excesivo no desaparecerían automáticamente. Sin ese contexto, una cifra aislada no es una prueba comparable.

Incumplir un objetivo llevaría a revisar y mejorar, no a una penalización. Además, el modelo reconoce a un equipo pequeño y distribuido, con horario ordinario y sin operación permanente. La pregunta a la comunidad es cuánto servicio e inversión espera, no qué nota asigna al personal.

El texto añade que los datos actuales solo se conservan siete días y no se exportan regularmente. Esa limitación impide análisis histórico. Justifica construir una base de evidencia, pero no permite afirmar que las herramientas estén fallando hoy.

La decisión de experiencia

La consulta UX describe una evolución orgánica en la que los desarrolladores asumieron muchas decisiones de interfaz. La renovación de rfc-editor.org sí incorporó especialistas, pero faltaba un proceso formal para recabar e integrar opiniones sobre el conjunto de herramientas.

Aquí se discuten opciones: ampliar usos por CLI o sin conexión, definir una dependencia razonable de JavaScript, extender inicio de sesión único y autoservicio, anticipar interacciones con IA o MCP, y decidir dónde contratar especialistas en accesibilidad. No son umbrales de rendimiento.

Sin embargo, generan consecuencias medibles. Un modo sin conexión puede requerir datos sincronizados o contenedores mantenidos. Una nueva autenticación añade dependencias. Las API y MCP pueden alterar volumen, límites y necesidad de claves. La consecuencia operativa debe medirse, pero no puede elegir por sí sola la experiencia.

Un comprobante para cada cruce

La política de participación comunitaria de IETF LLC ya exige rastrear comentarios, incorporarlos o explicar por qué no se incorporan, y comunicar la decisión. La mejora posible es hacer visible la relación entre las dos consultas sin convertirlas en una sola.

Cada asunto material debería producir un comprobante versionado con ocho piezas: comentario; servicio o modo de uso aplicable; métrica y punto de medición; exclusiones; autoridad decisora; dueño de la implementación; prioridad y estado temporal; y ruta de informe o revisión. Cuando un asunto tenga dos dimensiones, habrá dos estados enlazados.

Una petición de acceso sin conexión durante reuniones lo muestra bien. La ficha UX registraría si se acepta, rechaza o aplaza y quién decide. Otra ficha identificaría el conjunto descargable, la sincronización o la imagen de contenedor que deba medirse. Aceptar el caso de uso no significa haber alcanzado un objetivo; cumplir disponibilidad no significa que el flujo exista.

El versionado preservaría la secuencia. Una elección UX puede anticiparse a la planificación. Una implementación nueva puede modificar carga y dependencias, obligando a revisar una métrica. Cada cambio debe indicar qué versión sustituye, quién lo autorizó y qué parte sigue pendiente.

No se trata de crear una cola única de trabajo. Se trata de documentar transferencias. El sistema conserva su reloj, la experiencia su decisión y la planificación su autoridad. La responsabilidad aparece cuando el registro muestra el punto exacto en que un comentario pasó de un ámbito a otro.

Fuentes