Resumen

  • La IESG comunicó el 28 de agosto que Security Dispatch había concluido, que su lista se cerraría y que su función pasaba a un DISPATCH reconstituido para ART, SEC y los asuntos no vinculados al transporte de WIT.
  • El traslado del foro no debería borrar la semántica de sus resultados. Cada propuesta necesita una fila que conserve versión, dictamen, estado del consenso, tipo de autoridad, destino, condición de retorno y archivo.

Cambió el punto de entrada, no la posibilidad de proponer

El anuncio de cierre identifica a Christopher Inacio y Deb Cooley como contactos de la IESG. También deja claro que el área de Seguridad sigue invitando a presentar ideas nuevas. No es una clausura del trabajo de seguridad; es la desaparición de un canal separado.

El canal sucesor ya contaba con una base formal. La IESG aprobó el 2 de julio la nueva carta de DISPATCH. Su ámbito abarca nuevas propuestas de ART, SEC y los aspectos no relacionados con transporte dentro de WIT. Antes del anuncio de agosto hubo una reunión interina conjunta el 30 de junio y una sola sesión DISPATCH en IETF 126.

La unión puede ser útil. Un problema de identidad, correo o aplicaciones web puede requerir experiencia de varias áreas. Una entrada común reduce la probabilidad de que quien propone deba dominar primero el organigrama de la IETF.

Sin embargo, DISPATCH no adopta una norma. La carta permite orientar el trabajo a un grupo existente, aconsejar un BoF, preparar una carta para un grupo nuevo, sugerir un posible patrocinio de un director de área, abrir una lista, aplazar o rechazar. Esa orientación no es vinculante. Si las presidencias no pueden determinar consenso, ni siquiera está garantizado un dictamen. Salvo documentos administrativos limitados aceptados con los directores pertinentes, DISPATCH no desarrolla documentos.

El resultado del 30 de junio no cabe en una sola etiqueta

La reunión conjunta reunió a unas cincuenta personas. Después, las presidencias publicaron seis resultados y pidieron que se señalara cualquier desacuerdo con la lectura de consenso aproximado.

Cada caso tenía un significado distinto. En uno, la posible vía del Independent Submission Editor fue reconocida como una decisión del proponente, no como una acción de Dispatch. Dos temas no llegaron a presentarse. Otro recibió “ninguna acción para la IETF”. Un cuarto quedó sin acción por el momento y debía mostrar más interés de implementación e identificar un lugar de discusión. Otro fue remitido al BoF DAWN y a su esfuerzo organizativo.

“No presentado” no equivale a “rechazado por razones técnicas”. Una remisión a un BoF no crea un grupo de trabajo. Una pausa condicionada no es una prohibición permanente. La fusión no debería convertir esos matices en una vaga categoría histórica llamada “tratado por SECDISPATCH”.

RFC 7957 define el modelo: un grupo DISPATCH evalúa y busca ubicación para el trabajo, pero no lo completa. También puede dejar constancia de por qué una iniciativa no continuó. Los casos fronterizos quedan en manos de los directores de área y las presidencias responsables. RFC 2418, por su parte, permite al director de área, tras consultar al grupo, reorientarlo, cambiar sus presidencias o disolverlo, con una vía de apelación a la IESG.

La pieza que falta es un estado transferible

En el corte de esta investigación, el archivo público de SECDISPATCH seguía disponible y mostraba 1.699 mensajes. Eso no garantiza su permanencia, pero tampoco permite afirmar que algo haya desaparecido.

La pregunta práctica es si una persona puede seguir una propuesta sin arqueología institucional. Un registro público debería enlazar el identificador y versión, el último hilo pertinente, la reunión, el texto exacto del resultado, el estado del consenso y la clase de autoridad. También debería indicar destino, responsable siguiente, condición para volver, estado en la fecha de fusión, archivo superviviente y cualquier nueva actuación de DISPATCH.

Una corrección o sustitución debe añadir una nueva versión, no borrar la anterior. El registro no concedería derecho a ocupar agenda ni transformaría el consejo en autorización. Solo mantendría distinguibles la orientación, el consenso, la decisión del director y la elección independiente del proponente.

Un dígito conduce al documento equivocado

El aviso de cierre afirma que siguen siendo bienvenidas las ideas “según RFC7975”. RFC 7975 trata de una interfaz de redirección entre redes de distribución de contenido. La carta vigente de DISPATCH cita RFC 7957, que sí describe los grupos de estilo DISPATCH.

No hay evidencia de que el error cambiara la fusión o un dictamen. Aun así, merece una nota correctiva: el anuncio de cierre será una puerta documental durante años y debe dirigir al procedimiento correcto.

Las fuentes revisadas no demuestran pérdida de propuestas, conflicto sobre el cierre, carácter vinculante de los dictámenes ni derecho a una nueva audiencia. La ausencia de actas visibles de IETF 126 en la superficie consultada tampoco prueba que no exista o vaya a existir un registro. El esquema propuesto es recomendación de Daniel Kade.

Fuentes