Tools Architecture and Strategy Team (tools-arch)

Team Name Tools Architecture and Strategy Team
Acronym tools-arch
Area General Area (gen)
State Active
Additional URLs
- Wiki
- Issue tracker
Personnel Chairs Martin Thomson
Rich Salz
Area Director Alissa Cooper
Members David Schinazi
Jari Arkko
Jim Schaad
John Levine
Mark Nottingham
Silvia Botros
Tero Kivinen
Tony Hansen
Liaison Members Jay Daley
Robert Sparks
Mailing list Address tools-arch@ietf.org
To subscribe https://www.ietf.org/mailman/listinfo/tools-arch
Archive https://mailarchive.ietf.org/arch/browse/tools-arch/

About

The current set of tools supported by the IETF Tools Team, including Datatracker, Postconfirm, Mail Archive, XML2RFC, RFCDiff, and YANGCatalog, has been developed and maintained over many years by committed volunteers and contractors. The current tools suite has been developed with extensive input and contributions from the community, and as a result many previously unmet needs are today being met with the IETF tools.

As with many community-driven software development efforts, IETF tools implementations have seen contributions from multiple developers and the tools footprint has spread organically over many years. While this has been productive it has been in the absence of a well defined architecture and strategy that unites them all together. Given the breadth of functionality in the tools suite and advances in how software is developed, it would be useful to have a guiding set of architectural principles to which IETF tools align and an overall strategy that sets out general objectives and means of achieving them, applicable across the full tools suite.

The IETF Tools Architecture and Strategy (TAS) team is tasked with developing this architectural and strategic guidance for IETF tools development. Initial topics that the TAS team may wish to consider include:

  • End-to-end coverage

    • How well the tools suite supports the workflow of the standards development process end-to-end and how to address gaps or overlaps in the existing suite.
  • Extensibility and Maintainability

    • How different tools interoperate and how to specify a standard interoperability architecture, for example modern microservice design (APIs) to create a fully pluggable tool chain.
    • Needs for test infrastructure across the full tool chain, including test suites and automation (continuous integration) for those.
    • Reproducibility of results and processes, including automation of deployment and maintenance of processes. Specification of development practices for automation tools that meet the same standards as the service or tool that the automation tools support.
    • How well the tools architecture and development practices support new code contributions.
  • Operational

    • How the current tools scale and what scalability is required.
    • The performance of the current tools and what performance levels are required.
    • The current security profile of the tools suite, security objectives for the suite, and what structures/processes should be in place to reach those objectives.
    • When to develop new tools (or modify existing ones), vs. using “off-the-shelf” software or services.
  • User experience

    • Support for automation.
    • What adoption of user-centered design and usability testing is appropriate.
    • How to integrate user research and data analysis into tools development.

It is not the role of the TAS team to implement, maintain, or manage the operation of individual tools. Those responsibilities remain with the IETF tools team. Once TAS team guidance documents become available, the IETF Tools Project Manager will establish plans and workflows to align ongoing and future tools development with the guidance.

The TAS team is expected to consult widely with the IETF community, to draw on best practices from the software development industry and open source communities, and to evolve its guidance over time as practices change.

The TAS team members and team leaders are appointed by the General Area Director. The composition of the team is meant to reflect understanding of the IETF tools suite and its history as well as cloud software development processes and deployments. Team leadership changes are expected approximately every two years. Team membership will be assessed and potentially refreshed annually.