"The mission of the IETF is to make the Internet work better by producing high quality, relevant technical documents that influence the way people design, use, and manage the Internet." tl;dr: I feel sometimes that the IETF mission should be more truthfully restated as "The goal of the IETF is to make the IETF work better", which is not a bad goal in itself, as long as there is a causal relationship between that goal and IETF current goal of "...making the Internet work better". Firstly I would point out the discrepancy between the recent level of activity in the ietf@ mailing list, and the difficulty we have to get reviews and support for works that are WG items (I am not even talking about new work). I am not saying that we should not have the kind of discussion we recently had about Singapore, quite the opposite. It is well established that race, gender, nationality, sexual orientation, etc... are absolutely no indicators of competence in our line of work, so any attempt to exclude members of one of these groups should be actively fought because they are counter-productive to the main goal of the IETF (I left out religion in that list because I have personal difficulties to understand how multiple alternate realities can coexist in the same brain without negatively affecting the one that matters for our job. I'd like to be educated on that subject, but that's not the place for that). Now let's look at some of the things listed in the blog entry: 1. Make it easier for people to be involved in the IETF. I think that it is incomplete. The goal should be something like "Make it easier for people that can produce high quality, relevant technical documents that influence the way people design, use, and manage the Internet to be involved." Personally I think that the barrier of entry to contribute to the IETF is already very low. Effort should be made to be sure that we do not exclude people that meet these criteria, not trying to make things easier for people that cannot contribute to that goal, and ultimately would waste our time. 2. Be even better positioned to use online collaboration. I am personally not sure that there is a link between increased online collaboration and increase in sustained output quality, but any pointer to peer reviewed studies on that subject will be welcomed. I understand that increasing of online collaboration, when applied to the IETF, is in fact two different things. The first one is replacing good old email collaboration by web-based collaboration. I would use the Linux kernel project, arguably one of the most successful collaborating project, as a counter-example of that trend, as is entirely managed through email, and seems to thrive is spite of having very little other kind of online collaboration. But I admit that this a high barrier of entry (purposefully so) , so at the very least online collaboration should be seen as a path to the more boring but more efficient way of collaborating which is email, in the same way that Eclipse is the natural path to vim/emacs and Word to WriteRoom (boredom being one of the most powerful force in the universe). The second one is about replacing or reducing the IETF meetings. My personal experience is that the IETF meetings are invaluable - my most productive meeting was Dallas 92 which was also the one where I probably attended the lowest number of sessions. Although it is expensive - the budget to go to all 3 meetings is around $10K per year - I believe it is worth it. I should note that it takes some time to establish the personal connections that makes it worth spending that kind of money, so any opinion on that subject from people would did not attend at least 4 meetings should be taken with the proverbial grain of salt. So we should first be sure that online collaboration (as a replacement for email and/or as a replacement for IETF meetings) would really be to attract more people that can produce high quality, relevant technical documents, especially the people that would give up before they can see the advantage of our way of doing things. But not simply to attract more people for the sake of attracting more people. This is not Facebook. 3. Focus on linking open standards to code, operationals, and interoperability. My view on this evolved these last years. Few years ago I was convinced that developing a reference implementation at the same time than a specification and testing it against other people implementations was the right way to to find bugs in the specification. I even applied that idea when RFC 6940 was developed. Sure I found hundred of issues in the draft (and got "punished" for it by becoming - with Dean Willis - informal editors of the draft). But, in spite of my best efforts, my implementation could not cover 100% of the specification, so if on the one hand that made the specification better, on the other hand it certainly did not made the specification good by any of my standards. Basically a reference implementation is to a specification what a unit test suite is to a program: It was a great new technology 15 years ago, and everybody should do it today, but time has passed and there is now good solutions to cover 100% of a specification (or a program). That is what formal specifications and theorem proving are meant to achieve, and what I have being working on these last 3 years (talk to me in Berlin if that interest you). So here I think that these goals are good, but insufficient to "make the Internet better." 4. Evolve IETF sponsorship models to focus more on our work than meetings. Here again, let start looking at what works and what does not work in producing high quality, relevant technical documents that influence the way people design, use, and manage the Internet. That in turn should be cost evaluated. Then, and only then we can talk on how to finance these. That's the "technology is at our service, not the other around" principle in action: Let's discuss what we need; then we can find, extend or invent the technologies that are needed to fulfill these needs; finally we can search for ways to pay for that technology. I would like to add one point to this list. I believe that small and medium size enterprises are under represented at the IETF. One of reason would be because of the cost involved in participating - not even the cost of the meetings, but the cost of assigning an engineer to work part or full time on these topics. But I think that the main reason is hubris - i.e. all startups out there believe that their API/protocol will become the de facto standard, and that they will rule the market because of this superiority. That, and the fear that collaboration with other people in the same area will make them loose customers, are in my opinion the main reasons for their very low involvement. I'd like to see ISOC working on a marketing campaign or something like that to try to convince these companies to participate more in the IETF standardization process (disclaimer: as an individual paying out-of-pocket for attending the IETF meetings, I would profit from having more enterprises willing to contract me and my colleagues to work on their behalf at the IETF). On 06/12/2016 03:07 AM, IETF Chair wrote: > Hi, > > In the midst of a day’s discussion about particular issue that > troubles us with technology or something else, it can be difficult to > focus on topics that have a longer timescale. As you probably > remember, I had asked a design team to write a draft about various > trends around us that affect the IETF. > > We got some feedback on that draft, but the draft stopped short of > making specific statements about what the IETF should do. And unless > we bring the thoughts to a bit more practical level, the discussion > stays abstract and remote. So, I thought I’d try to state my view > about what we should focus on in the future, in the hopes that it > will generate discussion. Feel free to suggest alternate views or > question these! > > https://www.ietf.org/blog/2016/06/long-term-ietf-evolution/ > > Jari Arkko, IETF Chair > -- Marc Petit-Huguenin Email: marc@xxxxxxxxxxxxxxxxxx Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug
Attachment:
signature.asc
Description: OpenPGP digital signature