[Reducing the distribution to just the main IETF list]
On Fri, May 10, 2024 at 2:33 PM Dave Crocker <dhc@xxxxxxxxxxxx> wrote:
This imposes two, formal requirements for Standards Track that are
dramatically higher barriers than is typical for IETF Standards Track
specification.
What is the justification for this deviation from IETF norm?
Just to set context on what I think you mean by "norm": RFC 2026 required that interoperability be demonstrated for Draft
Standard, but not Proposed Standard. RFC 6410 moved that requirement up
to documents seeking Internet Standard status while collapsing the three-tiered
track into two tiers.
One of the motivating factors for this WG was the ISE noticing that a somewhat steady stream of email-related work was going to the ISE because these items, individually, fell below the threshold for warranting processing by the IETF in the form of either a dedicated WG or AD sponsorship (which is discretionary). Or, sometimes, the IETF disagreed with the proposal, but the author wanted it published anyway claiming it's in use (for some measure thereof). In either case, the ISE surmised that the IETF really should find a way to take care of this trickle of related stuff; it warranted more review and consideration and, possibly, coordination.
Some of the previous work that this WG is now meant to cover had, as far as could be discerned, zero or one implementation. That strikes me, at least, as fodder for Informational or Experimental, but not the Standards Track. The purpose of these constraints is to narrow slightly what can be produced on the Standards Track by this working group in particular (not the whole IETF), to head off spending precious volunteer time on what are essentially things that will never evolve beyond being individual pet projects. An author can avoid these requirements by seeking any of the other defined document development paths, all of which are still available.
It's true, of course, that the responsible AD could just direct the chairs to hold that line without actually writing it in the charter. However, experience has shown that different chairs and different ADs can sometimes interpret charters differently from one NomCom cycle to the next. Thus, if we want something like this to be firm and consistent over time, it's far more important to be explicit about it.
And, obviously, if it is reasonable here, why is is not universally
reasonable, as a basic barrier for all specifications going on Standards
Track?
Certainly if the community agrees that these minima ought to be applied universally, we could update our process documents via the normal work of producing a consensus BCP that says so.
-MSK
