[Standards] A Meta-Discussion about the Standards Process

Dave Cridland dave at cridland.net
Thu Jan 16 21:49:41 UTC 2020

On Thu, 16 Jan 2020 at 21:18, Peter Saint-Andre <stpeter at mozilla.com> wrote:

> On 12/13/19 6:58 AM, Dave Cridland wrote:
> >
> >
> > On Thu, 12 Dec 2019 at 16:41, Daniel Gultsch <daniel at gultsch.de
> > <mailto:daniel at gultsch.de>> wrote:
> >
> >     I mean correct me if I'm wrong but the IETF seems to be doing fine
> >     with just two stages.
> >
> >
> > Some history...
> >
> > The IETF used to have, essentially, three stages. Proposed Standard,
> > Draft Standard, and Internet Standard - the latter getting a STD number
> > as well as the RFC number. PS was the wild west,
> Actually, the wild west was not so wild. [1]
I do miss your injections of culture and history; the frontier west was
indeed law-abiding compared to the anarchy of the east coast cities, and
larger towns sensibly prohibited firearms like real civilisations. ;-)

> > with (fairly) low
> > requirements.
> >
> > Then they formalized the step before, Internet Drafts, and
> > gradually the Proposed Standard quality (and gating function by the
> > IESG) improved, to the point where it was felt that there was an
> > additional stage that added little, so they dropped it.
> >
> > Peter Saint-Andre (I think) designed our standards process to avoid the
> > Internet Draft stage and go straight to the wild-west of Experimental,
> > but it's otherwise the same as the original IETF design.
> Originally, the Editor (me) accepted anything for publication as a JEP,
> after minimal coherence / formatting checks and IPR assignment. Then the
> Council decided it wanted to act as a gate to publication, which is how
> got here. Instead of adding more epicycles, I propose that we remove the
> one we added. Consider me in favor of the "Daniel Plan".

I can easily be persuaded to go for the Florian Plan (or indeed the
closely-related Kev Plan), but I rather lean toward the Daniel Plan - as
you note, it fits the history of the XSF much better. I would be fascinated
to hear the original reasoning for the Council wanting the veto in the
first place, and I doubt it has much to do with how it's used now.

My concern is that on several occasions the Council has been the only thing
preventing encumbered specifications from entering the Standards Track, so
I think this use of the veto is risky to lose entirely.

But I would be perfectly fine with restricting the veto to be only for
enforcing our own documented policies (and if we introduce another XEP Type
that has different policies, that reason might disappear for that Type

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200116/2325b911/attachment-0001.html>

More information about the Standards mailing list