Standardizing BPF

Posted Apr 13, 2023 21:47 UTC (Thu) by tialaramex (subscriber, #21167)
In reply to: Standardizing BPF by kpfleming
Parent article: Standardizing BPF

What "combined effort" though? I agree this is how IETF working groups behave and I would like to think that in my small way I've contributed here and there. In contrast I haven't seen much evidence of this combined effort from WG21 in the ~3 years I've been studying it. What I see are individual (or small self-selected group) contributions, brought before a series of committees, presented to people who may or may not have any interest in the work done for their vote, and thus the contribution's destiny is sometimes apparently at a whim beyond the ken of mortal man.

This applies whether the scope is narrow or broad, whether it's a technical change to the language or library per se or just improving how the document (because WG21 doesn't produce an implementation, just the document) is worded. AIUI For the very biggest tasks - when they are recognised properly in advance - sometimes a deliberate task force is created to attack them, but this is exceptional.

But let's be more specific here, take P2806 (Barry Revzin's "Do expressions"). I say the only useful "vote" is on the question of whether the problem identified needs to be solved (obviously IMO yes but who am I), and if that's resolved in the affirmative, it's everybody's shared responsibility to get that done. That doesn't mean everybody is necessarily signed up to do equal work, but it does mean either you're helping get that done, or you're getting out of the way. That's what a combined effort is.

The WG21 process means instead that members can contribute nothing to this effort, and then show up, observe that Barry's do expressions are very ugly (sorry Barry but they are) and that Barry's argument against introducing yet more Undefined Behaviour contradicts WG21 orthodoxies in some ways, and vote "Strong against" without proposing what else to do about the problem instead. Is that work? By some definitions I'm sure it is, but IMNSHO it's not _useful_ work.

to post comments

Standardizing BPF

Posted Apr 14, 2023 15:41 UTC (Fri) by kschendel (subscriber, #20465) [Link] (4 responses)

> The WG21 process means instead that members can contribute nothing to this effort, and then show up, observe that Barry's do expressions are very ugly (sorry Barry but they are) and that Barry's argument against introducing yet more Undefined Behaviour contradicts WG21 orthodoxies in some ways, and vote "Strong against" without proposing what else to do about the problem instead. Is that work?

So what? Unless your posited member manages to convince others, an against vote need not mean anything. JTC 1 WG's operate by consensus, not vote-counting, and consensus doesn't mean unanimity.

In the WG's I participate in, said member would have been told that (s)he should have brought up the issue sooner, and would be invited to bring a solution to the table. (Unless of course the disagreement sways sufficient opinion in the absence of a solution.)

You seem to be insisting that "work" means that the WG members produce output -- which, in the standards world, means a document -- in a collaborative meeting of the members. Not all WG's choose to operate that way, and it's up to the members and the Convenor to set specifics. Quite a few WG's operate by one or more members producing a proposal document which others can read and comment on, with the actual WG meeting mostly being a review, optional discussion, and blessing (or not) of the proposal. I'll note that this is at least partly due to the fact that in prehistoric times, before the pandemic and Zoom, WG's usually only met a few times a year (because travel), and it would simply be impractical to leave all the "work" to the actual meeting.

Standardizing BPF

Posted Apr 16, 2023 16:59 UTC (Sun) by tialaramex (subscriber, #21167) [Link] (3 responses)

> So what? Unless your posited member manages to convince others, an against vote need not mean anything. JTC 1 WG's operate by consensus, not vote-counting, and consensus doesn't mean unanimity.

Consensus functions as a fig leaf. If they actually cared about consensus they wouldn't count votes and they definitely wouldn't care so very, very much about who gets to vote, and under what circumstances, which they do.

> I'll note that this is at least partly due to the fact that in prehistoric times, before the pandemic and Zoom, WG's usually only met a few times a year (because travel), and it would simply be impractical to leave all the "work" to the actual meeting.

And here we get to the crucial difference in why the IETF's Working Groups are able to actually do the work. By its nature this work happens electronically. When ISO 216 was standardised it's very understandable that ISO weren't able to do this (although note that the Mother Of All Demos happens *substantially before* ISO 216 standardisation so this was definitely not categorically impossible). But it didn't take a pandemic in 2020 to change this, it was practical for most IETF participants for 30+ years.

Most of the TLS 1.3 document (RFC 8446) came together as git PRs. When someone had a great idea for padding (check it out, TLS 1.3 padding is rather clever), they just wrote an email, they didn't need to wait until London, do a slide presentation and hope everybody present understood why it was a good idea and wasn't too hungry / playing Candy Crush / hungover. Meanwhile WG21 considers it an important innovation that in 2023 it is now able to allow people to participate without _flying to Hawaii_ at last.

The facts speak for themselves. ISO would be a disaster for BPF standardisation. I don't know if the IETF is a perfect fit, but it can't be worse than ISO for this purpose.

Standardizing BPF

Posted Apr 17, 2023 7:34 UTC (Mon) by kschendel (subscriber, #20465) [Link] (2 responses)

> > So what? Unless your posited member manages to convince others, an against vote need not mean anything. JTC 1 WG's operate by consensus, not vote-counting, and consensus doesn't mean unanimity.
> Consensus functions as a fig leaf. If they actually cared about consensus they wouldn't count votes and they definitely wouldn't care so very, very much about who gets to vote, and under what circumstances, which they do.

I have no idea what you're on about here. I'm not familiar with SC 22/WG 21, which I gather is the WG you are referring to; if it operates that way, it operates very differently from any of the working groups I'm familiar with. We do not, in fact, count votes; and if you're an expert qualified (by your national body) to sit on the working group, you have as much say as anyone else. That's universal across JTC1 as far as I understand it.

Standardizing BPF

Posted Apr 18, 2023 0:06 UTC (Tue) by tialaramex (subscriber, #21167) [Link] (1 responses)

WG21 explicitly tallies votes as I mentioned and you can even watch video of Bjarne Stroustrup crowing about just how many votes his woolly "strategy" to address the C++ safety problem got.

OOXML is also a product of JTC1. Obviously creating a "standard" that is in practice owned by single for profit corporation, in the face of an existing standard (ODF) that's widely used for the exact same purpose - is nonsense, yet somehow "consensus" was achieved to publish this as a standard.

How? By simply paying for the necessary votes, because talk of consensus is just a fig leaf.

I have no insight into what work you do, perhaps you are earnestly involved in valuable technical standardisation which makes the world a better place, but you should know that under ISO if somebody wants to splash cash to destroy everything you've ever worked on, ISO will claim there was "consensus" to go with whatever nonsense was bought and paid for and disregard your expertise.

Standardizing BPF

Posted Apr 18, 2023 2:10 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

Note that determining consensus is up to the chair of the group at hand (at the SG level at least). So while there may be 3 SA and 40 SF, if the 3 SA are implementers that say "this is not possible and we cannot implement this", a result of "no consensus" can come from such a vote (though the implementers not having swayed anyone in the discussion is…interesting for this hypothetical). That's because while the paper might get through and into the standard, if nothing implements it, what is gained? Such things also usually end up with NB veto threats. SG votes are strongly affected by who is in the room at the time and nerd sniping the topic to elsewhere is…possible (and are why papers require a champion present).

Note that the votes that ISO actually cares about are plenary votes at the WG level with NB entities as the voters and are generally unanimous (because if an NB is angered enough, they can throw all kinds of road blocks in the way of the entire standard).