[Standards] A Meta-Discussion about the Standards Process

Dave Cridland dave at cridland.net
Fri Dec 13 13:58:27 UTC 2019

On Thu, 12 Dec 2019 at 16:41, Daniel Gultsch <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, 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.

So currently, the IETF has three stages, one being a formalized pre-RFC
stage very close to the Experimental stage. We have three as well, being
ahead of the curve, though the IETF ended up dropping Draft Standard
whereas we dropped the Internet-Draft equivalent.

The difference is that there are two types of Internet Draft (that we care
about here), which is "Individual I-Ds" and "Working Group I-Ds". The
latter require formal adoption by the Working Group. The XSF is (roughly)
modelled as a "Working Group in Exile", which is one of the reasons I talk
about "Adopting a ProtoXEP".

> 2) The "Daniel Plan", which is to encourage Council to adopt pretty well
> anything. If this sounds radical to you, it might help if I described it as
> simply reimposing the de-jure standards process as described in XEP-0001. I
> can certainly see the attraction, but I also think it ignores the status
> quo and the problems alluded to above. Most recently suggested by Daniel
> Gultsch.
> In a way it doesn’t really matter if we introduce a new Florian Stage
> or if we reuse the existing Experimental stage for that purpose. In
> both cases we somehow have to deal with the status quo. There are a
> number of XEPs currently in Experimental that certainly belong into
> 'Florian'. (I'm going to follow Dave’s example of not providing
> examples.)
Taking that to mean "There are a number of XEPs which are 'wild west'
territory", yes.

> But that's to me is one of the underlying issues here; While I can
> certainly see why Council would require a certain readiness of a XEP
> before giving it a number, that quality measurement has been applied
> very unevenly in the past. There are *a bunch* of XEPs that literally
> have the text 'TODO' in them.
I think having TODO is actually fine - my concern is the unevenness.

> Which brings us to:
> > b) We have to, in particular, codify what each transition means, and
> therefore tighten up Council's veto-for-any-reason here. I don't mean that
> we remove any judgement calls on the part of Council, but I do mean that we
> should create a yardstick on what constitutes a "usual" versus "unusual"
> veto.
> Yes I agree with that. More transparent and fairer processing would
> certainly eliminate the feeling of XEP authors to retry after the next
> council has been elected.

I think my criteria are:

* Is the scope of this XEP within the scope of the XSF's expertise?
* Could this XEP [eventually] progress to Final?
* Would we want it to?

I think that much is relatively uncontroversial.

The problem is I have further considerations in play, based on past

* Do I have a fair idea of what will be needed to get it through to Final?
* Are these changes likely to occur?

I'm naturally more confident in adopting a ProtoXEP where I'm confident in
the answers there.

Sadly, it's unlikely that a given ProtoXEP will hit Last Call in the same
Council session, and I can't bind a future Council to a condition on that
transition, so this becomes largely guesswork. I suspect this is where
Council's more controversial decisions originate.

Another aspect of this is that I need to get a clear understanding of what
the scope of a proposal is, and that can often be unclear.

I suspect we could make vetos much less common if we were more willing to
kill XEPs on Last Call or Draft.

> I feel like only having two stages (Draft and stable) would help with
> that; because it is pretty obvious that for it being stable it has to
> be stable.

Hmmm. Two stages is very likely to be insufficient. That would collapse
Draft and Final, and I think these (or rather, the transitions between
them) are radically different.

Experimental to Draft says "We think this is ready for wide adoption, and
it's unlikely to change".

Draft to Final says "We think this has been widely deployed and we're
confident it won't change".

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20191213/b72329b9/attachment.html>

More information about the Standards mailing list