On Thu, Jul 28, 2016 at 2:24 PM, Bjoern A. Zeeb <bzeeb-lists@xxxxxxxxxxxxxxxxxx> wrote: > On 28 Jul 2016, at 8:56, Dave Taht wrote: > >> At both ietf and BBF this past week a frequent topic of conversation >> was how to get more open source involvement in standards orgs... >> >> ... and one counter-thrust of mine has always been to get more >> standards org members involved in open source, because that dialog has >> to go both ways. >> >> I thought I would point at several useful upcoming conferences in the >> hope that perhaps there would be some members of ietf/isoc "out there" >> planning some outreach in this regard. > > > There’s gazillions of conferences as you say. Being a BSD guy I could give > you a list of those but that’s missing the point I think. Well, honestly, I think a pointer to those conferences would be good too! Bugs accumulate at the interfaces between the layers. > What you should do is do the reference implementations for at least 2 > different (Open Source) Operating Systems before or rather along writing a > document. While I agree that running code and rough consensus and two implementations is the best strategy... One person rarely has the in-depth chops to handle internals of more than one OS. Usually there is a need for a large team of complementary skills. A huge problem for standards orgs are the demands of the GPL. An over-long anecdote: In 2012 Kathie Nichol's original codel code was in C++, in ns2. I ported it (from that and their paper - with a ton of help!) to C/Linux. Eric Dumazet wrote/rewrote the entire thing (not a line of my code remains) and made it fast, and a week later, wrote fq_codel in a single saturday afternoon, based on our earlier work with sfqred. There were years of experimentation (decades in the case of kathie and van) prior to that, that resulted in something that simple and elegant. We've spent years, now, with the sqm-scripts, dealing with the vagaries of the cable, dsl and PP* link layers. We've got nowhere on getting a dsl firmware maker (other than free.fr) to put in the code needed to apply them properly at the right layer there... despite only needing BQL-like buffer management in the dsl firmware. 50 lines of code. Not there. Grump. We've now spent 4 years trying to standardize fq_codel. We (toke, mostly) had to produce a text only RFC draft - due to the GPLness of the original fq portion of the fq_codel code, so that someone else with BSD chops could do a port, when funding was found. That happened, finally, a few months ago. The ns2 (BSD, kathie) and ns3(andrew mcgregor) (GPL) versions of this code are still, almost, kinda, still out of tree patches for those simulators, because they required a whole bunch of other infrastructure to "get in there" (too many contributors to list) There's been the hope that the ns3 version would finally be merged in this release cycle, I don't know if it made it yet. Work on "cake" (successor to the sqm-scripts) is dual BSD/GPL licensed in the expectation that writing a RFC will be basically impossible without reference to source code as the algorithms are too complex to write down in english. If people have lost skills to read stuff in C, tough, I'm not going to do a yang model. ... honestly, if I'd known how hard it would be and how long it would take to do, I'd have never started standardizing fq_codel. I would have moved on, instead, to applying it to wifi, and the code would have been available for Linux users to use 6+ billion wifi devices ago. I've never worked so hard in my life to give away something for free, and I'm ill-inclined to ever do it again. (at the moment). 4 years now spent, not doing stuff that would have been more immmediately valuable, had we stuck to coding, at the current pace of the internet's growth. I sure as heck hope that 5 years from now I can look back at all the work of the aqm wg and see products using it deploying faster than the internet is growing, but am pessimistic. ... So my meta point is, standardizing something takes a lot of resources, a lot of different kinds of people, a lot of time, and a lot of things that should happen in parallel that end up happening in sequence. One thought for a new ietf process might be the concept of a "funded working group", along the lines of how linux foundation, the apache foundation work, that handles the baseline needs of the group for coding, testing and rfc-writing resources. ... Innovating in userspace is much easier, except that userspaces have evolved in radically different ways also. I have no idea, none, whatsoever, about what would be required, to make the outputs of the homenet wg actually work outside of openwrt (and we're working on debian support), on iOS, OSX, Android, and Windows. Standardization may help (but there were few if any actual home router vendors in the room) - and certainly APIs for much stuff would be nice to have. Been trying to get all the OS vendors to discuss sane standard APIs to the dscp/ecn bits for over a year now, with no progress. >That will (a) guarantee running code Having a QA team and userbase also helps. > and (b) a lot of documents > will be written better, more understandable, and cover the bits that > actually matter and won’t be “theory” only which people who have to > implement them after the facts go head->desk(). +1. Actually implementing stuff first filters out the bad idea quotient and noise on the mailing lists by a lot. > That brings me to (c) as > you’ll have a valuable contribution to actually go to one of the conferences > and present your work there and engage with that community (and, yes, that > can be an overlapping effort, e.g., go and discuss while you are working on > the prototype to see what field experts think about it; their feedback then > will influence your implementation and the document and you are back at (a) > and (b)). I don't regard my end goals as writing a paper, or going to conference. My end goals are running, deployed, correct, useful code. I wish more people shared those, of course, and that academia, in particular, rewarded those that made good, oft-used, deployed code, more than those that made good, underread papers. Certainly conference attendance is a tremendous source of contacts, and collaborators, and far more than the actual meetings themselves, I love the $RANDOM in the hallways and beer bofs, and that's why I go to several different kinds of conferences, and only attend ietf once a year. To paraphrase what I said earlier... the bugs accumulate between the cracks of the organizations. As for APIs, does posix still have a pulse? > Just half a ct from me > > /bz -- Dave Täht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org