"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(_at_)petit-huguenin(_dot_)org
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug
signature.asc
Description: OpenPGP digital signature