Subject: [Tools-arch] My notes and thoughts from 2020-04-23 meeting

From: "Martin Thomson" <[email-masked]>
Date: Fri, 24 Apr 2020 09:46:37 +1000

What I got from this was that there is a desire to understand less of the mechanics of the process, but more of the overall user experience and how the various tools integrate.  More generally, our first task might be to ensure that we have a vision for how the process works and the tools to support that.

We immediately identified the document lifecycle as central to this, but then we also identified important supporting functions like authoring, discussion (mail), discussion (meetings), management (status tracking, evaluation, review), and finally publication (RPC).

I might even up-level and say that the business of the IETF is fostering communities that strive to reach consensus and that we use documents to capture the state of that consensus.  That places greater emphasis on the communication channels and less on the document production side of things; documents might be the focal point of our energy, but the means by which we direct that energy is more important: email, GitHub issue discussion, meetings, and side discussions.

You will note that I did not mention chat.  I think that the current state of instant messaging in the IETF is in dire need of attention.  Jabber/XMPP is dead and we cling to it to our detriment.  That's a shame because the backchannels in meetings can be very effective.  And the efforts I've been involved in have benefited greatly from the chat systems they use.  With QUIC being so active, the slack used there is a great resource.  (I am aware that chat is a known issue, but I wanted to highlight that.)

---

Jay:
Three levels of focus
1. Operational development level - making the tools

2. Technical architecture of how those tools integrate
 e.g., datatracker use shared files

3. Higher level (main focus of this group): architecture and strategy

Higher level issues:
 - nobody has done an end-to-end analysis of the process we follow and the tools
   that are used in that process
 - no big picture plan for integration of tools: how tools chain together and
   support each other, how third party tools integrate with our processes
 - user experience with tools is inconsistent: we have no idea who each tool is
   being used for, or the target platforms (mobile, command line, browser,
   desktop)
 - performance is poor in some cases, but we don't have expectations for this
   (scale and responsiveness side) Robert and Jay are looking at
   instrumentation, but we need to know what the goals are

This group will draw on Robert and Jay for getting an understanding of the
current situation, make some suggestions and recommendations.

John: understanding user needs is important; problems come up as a result of
people not know what the tool is supposed to do

Robert: we understand the users who are chairs and document authors, and other
roles that are modeled in the tracker.  What other actors depend on this.

Jay: Some more depth might be needed here.

Robert: the datatracker API is primitive, this group might help identify areas
for improvement

Jay: Do we want to have a single integrated home for all the tooling?  Something
that covers the process from authoring, to management, checking, publication,
approval, etc... ?  Or do we think that there is sufficient diversity of use
that we just need to have a suite of tools that can be self-assembled.

MT: some diversity

Robert: people using word will continue to do so

mnot: we have removed dependencies on IETF tools for various reasons
(performance, availability, etc); I have a draft on criteria for using
third-party tools

mt: what other tools are involved in the process? other than datatracker/github?

rsalz: what about the RPC

John: the RPC tools are mostly just xml2rfc

Robert: tried to get the RPC to open source their tools

John: these are a mess of scripts

Jay: we do need to look at all of this all the way to the RPC.  The IETF really
does own all of these tools.

John: not a question of ownership, it's just time (keep the RFCs flowing)

Robert: document development seems to be the backbone of things.  WE need to
look at activities around the document.  Having online meetings is another
important thing here.

Jay: In the LLC, we have an agreement that some large amount of money might be
needed to revamp the toolchain.  We need a vision for this that describes what
excellent looks like.

Jay: AMS has just two tools: meeting registration and a CMS for fundraising.
The registration system is being rewritten.

Robert presents.  (Robert: can you provide those slides?)

Jay: is this group the sort of team that can advise on how these things are
deployed?  (mt: thought is that an HTTP 3xx to a specialized file-serving
service is a reasonable substitute for serving the content directly.)

Robert: Most of this stuff is operated by SSH to the one big machine.
Datatracker has a lot of inbuilt operational capabilities so that rarely needs
manual intervention.  yangcatalog is built to modern standards for operation.
Wagtail is updated via dockerhub.

Robert: we should concentrate on how this *should* work in the ideal sense

rsalz: how do we integrate meetings (increasingly virtual?) into the overall
production process.  Mobile devices are important.

Robert: what are the first work products?  no good answer, but a good question

Jay: we might need to produce more data, we need to know what users access, we
need to know where that integrates

Jay: it might help to start a skeleton of things we need to talk about and
decide

rsalz: producing documents is a central thing, but there are other processes to
support that: meetings, IESG processes,

robert: IPR ownership is another in terms of declarations

mt: mail is a big deal

Robert: query: mail is critical and hard, can you take that to the cloud?

John: there are several services (google does that; fastmail can do that too, and
they are our friends)

Jay: we could also pay someone to do a review of this

John: talk to Bron, economies of scale are massive in mail, so this might save
money overall

mt: I'll send notes to the list and we can talk about what our first deliverable
might be

---

From: Jay Daley <[email-masked]>
Date: Fri, 24 Apr 2020 12:08:31 +1200

Martin

> On 24/04/2020, at 11:46 AM, Martin Thomson <[email-masked]> wrote:
> 

This is an excellent analysis that really helps me understand this from a high-level perspective.

> You will note that I did not mention chat.  I think that the current state of instant messaging in the IETF is in dire need of attention.  Jabber/XMPP is dead and we cling to it to our detriment.…

Now that I can see this in the context of the analysis above, I understand the need and the urgency much better.

thanks
Jay

> -- 
> Tools-arch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tools-arch
> 

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: Robert Sparks <[email-masked]>
Date: Fri, 24 Apr 2020 13:46:00 -0500

Here are the slides from yesterday's call