The question "Will this damage running code?" seems legitimate, and IThe concern I've raised is not whether it is sometimes useful to impose the higher barrier of requiring implementation but why it makes sense to single out this wg and bake the requirement into all its work.
hope the IESG considers it whenever relevant. It's explicit in RFC 2026
that "Usually, neither implementation nor operational experience is
required" for PS, so Dave is correct that this is a higher requirement
than normal. But it conforms to RFC 2026 because of that "Usually" and
the following paragraph:
~~~
The IESG may require implementation and/or operational experience
prior to granting Proposed Standard status to a specification that
materially affects the core Internet protocols or that specifies
behavior that may have significant operational impact on the
Internet.
~~~
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.
Right. There has long been a formal requirement for demonstrating interoperability -- and in fact deployment -- for advanced standards track.
However it has always been exception for Proposed. Basically,
when the stakes are high enough in need or risk, it makes sense to
impose this testing burden.
Baking this requirement into a meta-wg like this is, I believe, unprecedented. More importantly, it does not make any obvious sense. Pressing for community interest is one thing. Demanding that level of a priori community investment does not. (IMO.)
One of the motivating factors for this WG was the ISE
My concern is not whether there should be an umbrella email wg, but on the formal criteria for its adoption of work.
Some of the previous work that this WG is now meant to cover had, as far as could be discerned, zero or one implementation.
Quite a bit of IETF proposed standards tend to fail to get traction. And that includes efforts that get their own working group.
Singling email out for the very high barrier to entry of a priori implementation should at least warrant very clear justification that is specific to email.
That strikes me, at least, as fodder for Informational or Experimental, but not the Standards Track.
If there were a document that made this clear and if it were IETF wide, that would probably make sense. Singling out email work however has no obvious basis.
(I know. I am being repetitious. Unfortunately, it's intentional. This dynamic creation of what is frankly an onerous burden warrants it.)
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.
Lofty and laudable goal. But it is a very selective and tactical
effort for what is really a very broad and strategic problem, not
even slightly specific to email. It's been a problem for decades
throughout the IETF.
An author can avoid these requirements by seeking any of the other defined document development paths, all of which are still available.
That sounds oddly like: Don't come to the IETF until a small
email specification effort has already been deployed successfully
and usefully in production.
(Ironically, that's on a par with the advice I'm giving to nascent
efforts these days, but alas, people keep thinking the IETF is a
place to start efforts, not just finish them. In any event, there
is a difference between someone offering professional advice and
the IETF imposing it as policy.)
It might be a reasonable barrier, but again, it doesn't make sense to make it specific to email.
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.
The point is assertion of a policy without clear and compelling justification. That it is, this time, baked into a wg charter just makes it easier to document the issue...
However, experience has shown that different chairs and different ADs can sometimes interpret charters differently from one NomCom cycle to the next.
Oh, wait. You want management consistency? Heh.
This is a very odd way to attempt organizational change.
Just to get in a small dig: The IAB has a document that
specifies a list of reasonable justifications for an IETF member
issuing a Discuss. For management consistency, get AD's to start
using it. (As an exercise to the reader, try to guess why I'm
raising that specific example.)
Thus, if we want something like this to be firm and consistent over time, it's far more important to be explicit about it.
Again: Strategic goal, being applied in a narrow and tactical context. Bad management move.
d/
-- Dave Crocker Brandenburg InternetWorking bbiw.net mast:@dcrocker@mastodon.social
