Subject: IETF Tools Architecture and Strategy Team

From: IETF Chair <[email-masked]>
Date: Wed, 5 Feb 2020 09:55:29 -0500

Hi all,

I'd like to introduce a new volunteer team that has been created in the General area: the Tools Architecture and Strategy (TAS) team.

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, guiding architectural principles to which IETF tools align and an overall strategy that sets out general objectives and means of achieving them are necessary, 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 of the IETF participant workflow
• Extensibility and maintainability
• Operational scalability, performance, and security profiles of tools
• User experience design, testing, and analysis

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 (currently Robert Sparks) 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 team's online presence resides at:

Datatracker page: https://datatracker.ietf.org/group/tools-arch/about/
Mailing list (only open to members, with a public archive): [email-masked]
Github organization: https://github.com/ietf-team-tools-arch

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. The initial team members are:

Jari Arkko
Silvia Botros
Jay Daley (LLC liaison)
Tony Hansen
Tero Kivinen
John Levine
Mark Nottingham
Rich Salz (co-lead)
Jim Schaad
David Schinazi
Robert Sparks (tools team liaison)
Martin Thomson (co-lead)

If you have questions about the team, feel free to send them to me or the co-leads, Rich Salz <[email-masked]> and Martin Thomson <[email-masked]>.

Best,
Alissa Cooper
IETF Chair

---

From: Michael Richardson <[email-masked]>
Date: Wed, 05 Feb 2020 19:14:42 +0100

IETF Chair <[email-masked]> wrote:
    > I'd like to introduce a new volunteer team that has been created in the
    > General area: the Tools Architecture and Strategy (TAS) team.

I think it is a really good idea to organize this.
I wonder if you considered just creating a WG in the general area?
What would seem to let the tools team leverage... the tools.
But, I guess you can create groups that aren't WGs based upon the links below.

    > 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 (currently Robert Sparks) will establish
    > plans and workflows to align ongoing and future tools development with
    > the guidance.

I believe that the team will mostly produce plans, and those plans will not
be in the form of RFCs, and probably not even in the form of IDs.

    > 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 team's online presence resides at:

    > Github organization: https://github.com/ietf-team-tools-arch

May I suggest that one of these people be designated as the liason to the
WG-chairs list?  And another as the liason to the EDU-team?

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 5 Feb 2020 18:33:01 +0000

Commenting only on the part that I can definitively answer.

>    WG-chairs list?  And another as the liason to the EDU-team?
 
Although not officially designated as such, I'm on WG-chairs and co-chair EDU-team.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 05 Feb 2020 19:59:23 +0100

> Although not officially designated as such, I'm on WG-chairs and co-chair EDU-team.

That's probably good enough :-)
What I want to have happen is for the EDU-team to say, "teaching people to do
X is hard", and for the TAS team to say, "hey, there is no reason to teach
people to do something we can easily change"

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 6 Feb 2020 13:32:59 -0500

Hi Michael,

> On Feb 5, 2020, at 1:14 PM, Michael Richardson <[email-masked]> wrote:
> 
> 

Great!

> be in the form of RFCs, and probably not even in the form of IDs.

Right, and that’s a good reason to have a team rather than a WG. Also, for the time being it’s meant to be a fairly small group to be able to progress quickly. Many of the topics within the team’s purview don’t necessarily benefit from a consensus process, same as the tools team itself.

> WG-chairs list?  And another as the liason to the EDU-team?

As with EDU, we’ve got a bunch of WG chairs in the team, so I think keeping the lines of communication open should be straightforward.

Thanks,
Alissa

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 7 Feb 2020 08:14:36 +1300

Alissa, how will liaison with the RFC Production Center be managed? xml2rfc is not just an IETF tool, and it's in the middle of a complex deployment process with known discrepancies between the documented and implemented versions of the v3 syntax, not to mention some very tricky issues around SVG support. 

Regards
   Brian

---

From: "John Levine" <[email-masked]>
Date: 6 Feb 2020 17:47:51 -0500

In article <[email-masked]> you write:
>Alissa, how will liaison with the RFC Production Center be managed? xml2rfc is not just an IETF tool, and it's in the middle of a complex deployment process with known discrepancies between the
>documented and implemented versions of the v3 syntax, not to mention some very tricky issues around SVG support. 

I'm on the tools team.  As you might expect, these issues are in the middle of my aRSE plate.

R's,
John