On Thu, 16 Jan 2020 at 21:18, Peter Saint-Andre <stpe...@mozilla.com> wrote:
> On 12/13/19 6:58 AM, Dave Cridland wrote: > > > > > > On Thu, 12 Dec 2019 at 16:41, Daniel Gultsch <dan...@gultsch.de > > <mailto:dan...@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 entirely). Dave.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
