Hi Murray, Dave,
At 08:58 AM 13-05-2024, Murray S. Kucherawy wrote:
On Fri, May 10, 2024 at 2:33 PM Dave Crocker
<<mailto:dhc@xxxxxxxxxxxx>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?
[snip]
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.
I agree with Dave's point on the higher bar in the charter. For what
it worth, RFC 2026 also set other requirements, e.g. proprietary
rights. The requirement was moved to Section 2.2 of RFC 6410 and it
is also in BCP 79.
Murray's point is about work being taken outside the IETF because
there is very little interest. A specification could be published as
"experimental". If I recall correctly, that was done with CT.
One of the problems which might not have been apparent in 1996 is
that one or two vendors with significant market share is able to push
other vendors to adopt a specification. The working group is then
faced with the choice of either adopting the specification with minor
changes or ignoring it.
Murray raised another point, re. time. BCP 25 states that:
"While this may be renegotiated over time, the list of milestones
and dates facilitates the Area Director's tracking of working group
progress and status, and it is indispensable to potential participants
identifying the critical moments for input. Milestones shall consist
of deliverables that can be qualified as showing specific achievement;
e.g., "Internet-Draft finished" is fine, but "discuss via email" is not.
It is helpful to specify milestones for every 3-6 months, so that
progress can be gauged easily."
The only milestone of this working group is a call for adoption. I
understand that getting a draft adopted can sometimes be an
achievement. However, it is not a deliverable.
Regards,
S. Moonesamy
