Standardizing BPF

Posted Apr 11, 2023 0:42 UTC (Tue) by kschendel (subscriber, #20465)
In reply to: Standardizing BPF by tialaramex
Parent article: Standardizing BPF

If BPF were going to be standardized by ISO or IEC, presumably it would go into JTC 1/SC 22, which is the programming languages subcommittee; and probably into a new SC 22 Working Group. (and yes, Working Groups do typically do the actual work.) It's possible for a JTC 1 SC/WG to move quickly; it's just not the norm.

A more likely path would be for someone like the IETF to come out with a document, and then work with JTC 1 for a PAS (Publicly Available Specification) based on it.

to post comments

Standardizing BPF

Posted Apr 11, 2023 1:36 UTC (Tue) by tialaramex (subscriber, #21167) [Link] (11 responses)

WG21 certainly doesn't do the actual work. Contrast what happened to say Epochs with what happened to eSNI

Eric Rescorla wrote and presented a single draft document, sketching how eSNI could work, almost immediately after the group (TLS) had decided that encrypting SNI wasn't a solved problem and so they would publish only a "Want to have" document describing why this is a problem and what desirable properties of a solution would be - not a proposed way to actually do it. The group adopted eSNI, and (eventually renamed Encrypted Client Hello) subsequent drafts were published under the group's name, and the responsibility for driving this document, despite Eric's name as lead author, is shared by the group. There have been sixteen subsequent drafts over several years.

Epochs meanwhile was a proposal for C++ to have something akin to Rust's Editions. A way to adopt changes to the language syntax on a per-module basis. A sketch was presented to a preliminary panel, which agreed it could be presented to a sub-committee of the (sub-sub) committee for C++, that committee decided that although this was a potentially interesting idea there were further questions to answer.

And that's it. That's all that was done, because despite being a "Working Group" WG21 takes no responsibility to actually do any of this work, and so unless the author of the original proposal is willing to extensively rewrite it and present it again, and again, and again, perhaps for many years (as often happen check out the miserable story of how #embed finally made it into C23!) until the committee is satisfied that it's finished - it is discarded and plays no further role beyond historical.

Standardizing BPF

Posted Apr 11, 2023 10:28 UTC (Tue) by magfr (subscriber, #16052) [Link]

The repeated rewrite of the world is something the kernel community should be familiar with, quite a few patches have ended up in that particular hell over the years.

Standardizing BPF

Posted Apr 11, 2023 13:13 UTC (Tue) by ojeda (subscriber, #143370) [Link]

It depends on what you mean by "work". The Working Groups (and the Study Groups within them, too) definitely do work, such as discussing and voting on proposals, reviewing national comments, performing editorial reviews and so on. In many cases, paper authors are part of the committee, and some of those papers are written as a consequence of discussions within the committee, too.

That is not to say ISO is ideal for programming languages at all, but saying work does not happen there is a bit harsh, especially for those that put their own free time into it.

Standardizing BPF

Posted Apr 12, 2023 16:26 UTC (Wed) by mathstuf (subscriber, #69389) [Link] (8 responses)

> Epochs meanwhile was a proposal for C++ to have something akin to Rust's Editions. A way to adopt changes to the language syntax on a per-module basis. A sketch was presented to a preliminary panel, which agreed it could be presented to a sub-committee of the (sub-sub) committee for C++, that committee decided that although this was a potentially interesting idea there were further questions to answer.

I was there for the presentation. The questions asked are certainly relevant and not easy to answer. Given the number of things that could actually be fixed by it (without rewriting a *lot* of rules), it didn't seem worth the weight. Note that deprecating `0` and `NULL` for `nullptr` were in the "not sure how that will be done" bucket because ADL is a thing and getting a different overload/lookup that still works with `0` while wanting it to be `nullptr` sounds like a rich vein of false positive diagnostics to me. Much better to instead use something like `clang-tidy` to detect "you can use better spellings for things here" than trying to force it into a language that cares about how things are explicitly spelled as much as C++ does.

> And that's it. That's all that was done, because despite being a "Working Group" WG21 takes no responsibility to actually do any of this work, and so unless the author of the original proposal is willing to extensively rewrite it and present it again, and again, and again, perhaps for many years

I don't know who else you think should do the work. To translate to the Rust world: do Rust RFCs have anyone other than the authors to push them forward? Python PEPs? Is it the obligation of the Rust developers to do as much work as possible on every RFC submission? How about pre-RFCs (which is what SGs usually work with)?

(FD: WG21 member)

Standardizing BPF

Posted Apr 13, 2023 2:13 UTC (Thu) by tialaramex (subscriber, #21167) [Link] (7 responses)

It seems to me I explained exactly what the alternative was in my original post by referring to how this happens in the IETF. The Working Group could, and should, (but in WG21's case won't) actually do the work. Proposals for what problems should be solved and a sketch of how the group could go about solving them are quite different from "proposals" which detail finished work complete with wording for the standards document.

I noticed that even though Bjarne's recent proposal is both woollier than Epochs and attacking a problem that's much less amenable to technical solution, it somehow obtained a large majority vote in favour rather than just the endless stream of questions. It seems to me that one of the subtle good things about Rust is that while Graydon's contribution isn't ignored, nobody is under any illusions that this is Graydon's language, indeed if anything Val is likely closer to what Graydon had in mind that Rust today. In contrast people are still asking if Bjarne will write a fifth edition of his book about what is clearly still his programming language.

Standardizing BPF

Posted Apr 13, 2023 14:44 UTC (Thu) by kpfleming (subscriber, #23250) [Link] (6 responses)

> It seems to me I explained exactly what the alternative was in my original post by referring to how this happens in the IETF. The Working Group could, and should, (but in WG21's case won't) actually do the work. Proposals for what problems should be solved and a sketch of how the group could go about solving them are quite different from "proposals" which detail finished work complete with wording for the standards document.

Having participated in both WG21 and in various IETF WGs, I don't understand the distinction you are trying to make here. A WG is a collection of people providing their time and expertise to the combined effort, and that's it. No member of any WG is obligated to do any amount of 'work' on any proposal, they choose to do so.

In both cases, if there are not a sufficient number of WG participants motivated to engage with the authors of a draft document, it won't move forward. If the WG21 membership can't find a reasonable number of people to work on a proposal for 'Epochs', that's fine, it won't move ahead. The same thing happens all the time in IETF WGs; WGs call for votes on whether to accept an author's document as a WG document and start the process, and quite often those votes result in 'no' and the document does not get accepted.

Standardizing BPF

Posted Apr 13, 2023 21:47 UTC (Thu) by tialaramex (subscriber, #21167) [Link] (5 responses)

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.

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).