Summary

  • The proposed IETF Tools SLA covers system performance and availability. It expressly does not evaluate Tools Team performance or decide how that team’s work is scheduled and planned.
  • The parallel UX consultation concerns interfaces, accessibility, access control, client requirements and Web, CLI, plugin, API, MCP and offline modes; it excludes systems performance because that belongs to the SLA discussion.
  • IETF LLC can keep the two decision clocks separate and still publish a versioned receipt linking feedback to the applicable service, metric, exclusion, decision authority, implementation owner, timing state and review route.

One opening date, two institutional objects

On 17 September 2026, IETF LLC asked the community to comment on two aspects of IETF Tools. Both consultations close on 12 October. Both accept private replies to the LLC Board and Executive Director and public discussion on the tools-discuss list. The symmetry ends there.

The service-level paper is an instrument for observable system behaviour. It proposes targets for availability, web response time, mail delay and incident response. It assigns services to tiers, defines how partial degradation contributes to downtime, sets exclusions, and describes monthly reports and annual review. It is meant to turn “best efforts” into a measurable expectation for systems.

The user-experience paper asks a product and access question. It maps tools across Web, command line, plugins, APIs, Model Context Protocol and offline use. It asks about accessibility, authentication, client requirements, static URLs and the balance between specialised interfaces and simpler ones. It says systems performance is outside that consultation because a parallel process covers it.

That is not administrative housekeeping. It is a division of authority. An SLA can say which service was measured, at what point and against which target. It cannot, merely by reporting a missed target, establish that a team performed badly or that one feature should displace another in the work plan. A UX decision can establish that a usage mode or access pattern matters. It cannot, merely by adopting that preference, prove that the resulting service meets an availability or latency target.

What the service clock can prove

The draft SLA makes its boundary unusually clear: it applies only to system performance and availability, not to the performance of the Tools Team or to scheduling and planning the team’s work. Those other subjects may need discussion, but this instrument is not designed to decide them.

Inside that perimeter, the proposal is detailed. Automated monitoring would be authoritative for availability. Full outage would carry a weight of 1.0, major degradation 0.5, minor degradation 0.25 and cosmetic defects zero. Service tiers would distinguish critical infrastructure from lower-impact or third-party services. Response objectives would be measured at the server side, excluding client rendering, the end user’s network and specified external dependencies.

The exclusions matter as much as the targets. Scheduled maintenance, third-party failures, force majeure, a user’s own network or device and deliberate security mitigation would be outside the calculation. Emergency maintenance and disruption caused by abuse or excessive traffic would not automatically disappear from the score. A metric without that denominator and exclusion record would invite false comparisons.

Nor is the draft punitive. Its stated response to a missed target is review and improvement, not damages or penalties. The operating model acknowledges a small distributed team working standard hours rather than a 24/7 operations centre. The consultation therefore asks the community to choose among service expectations, investment and operational trade-offs; it does not invite a staff-performance rating.

The historical-data caveat reinforces the point. The paper says performance has been monitored but retained for only seven days without regular export, so historical analysis is unavailable. That supports better measurement. It is not evidence that the current systems are failing.

What the experience clock must decide

The UX document starts from a different institutional gap. IETF tools evolved organically, and developers generally made interface choices. Specialists were brought into the new rfc-editor.org work, but there has not previously been a formal process for gathering and incorporating community views across the Tools portfolio.

Its questions are choices rather than thresholds. Should more tools work from the command line or offline? How much JavaScript is reasonable? Where should single sign-on and self-service access control reach? Should future tools accommodate direct AI or MCP use? Which accessibility work requires external specialists? How much personalisation should a feature-rich interface provide?

Those decisions can create service consequences. Offline support may shift a dependency from a hosted interface to a maintained container or dataset. Stronger authentication can add a new identity dependency. An API or MCP mode can change load patterns and the case for keys or rate limits. Accessibility work can alter client-side structure without changing the server-response clock. The consequences need measurement, but the measurement does not decide the product choice.

This is why the two consultations should not be collapsed into one scorecard. A user may report that a workflow is hard to complete even while every availability target is met. Another may ask for an interface whose operating cost would change the service tier or resource plan. Each report is valid evidence, but it enters a different decision lane.

A shared trail without a shared clock

IETF LLC’s Community Engagement Policy already supplies a baseline. Feedback should be tracked and either incorporated or accompanied by a clear reason why it was not; once a decision is made, the community should be informed. The opportunity is to make that disposition auditable across the two simultaneous Tools consultations.

For each material feedback item, a versioned public receipt should record eight fields: the feedback itself; the applicable service or usage mode; the metric and measurement point, if any; relevant exclusions; the authority that decides; the owner of any implementation; the priority and timing state; and the reporting or review route. A cross-reference can connect related SLA and UX items without merging their states.

Consider a request for reliable offline meeting access. The UX row would record whether offline use is accepted, rejected or deferred, who makes that product decision and what implementation is contemplated. A linked service row would identify any downloadable dataset, synchronisation endpoint or container image, the point at which it is measured and which external dependencies are excluded. “Accepted as a UX need” would not mean “the service target is already met.” A green availability report would not mean “the offline need was addressed.”

Versioning is essential because the consultations will not necessarily move together. A UX choice may precede an implementation plan; an SLA metric may need revision once a new usage mode changes load or dependency structure. The receipt should preserve the earlier decision, identify the later change and state which authority made each one.

The result would not be one master queue for all Tools work. It would be a decision trail with explicit hand-offs. Service measurement remains about systems. UX disposition remains about use. Planning remains planning. Accountability comes from showing where an item moved between them—and where it did not.

Sources