Jari,
Inspired by two of your recent notes and Dave Crocker's long
one last weekend (with which I almost completely agree should
that be notable), let me make a few observations:
(1) To the extent to which the IETF's focus is on protocols that
we hope vendors and others ("producers" in the vocabulary of
some other SDOs) will implement and try to get deployed, lines
of argument that start with "they use the Internet there,
therefore they should be participating in the IETF" may just be
irrelevant. If there is a major vendor design presence in a
region, then we should be very concerned if we don't have
significant presence from that region in the IETF as well. But,
if the vendor presence is limited to marketing, sales, and
perhaps implementation, then, if that is a problem, it is one
that doesn't lie easily within IETF scope... and probably
shouldn't.
(2) As far as I can tell, the operators in most regions are
generally well represented in, and collaborate using, the
various *NOGs. If those groups aren't serving their needs, it
is probably not a problem for the IETF. If they are, then the
IETF should no more be trying to invade that turf than a certain
Geneva-based organization should be invading ours. We are not a
user group either. To the extent to which there is a need for
more user groups or more effective ones, I hope that the ISOC
Chapter structure is at least making useful contributions in the
area.
(3) Our Operations and Management Area is mostly about protocols
and tools (just as the Applications area really isn't about
applications as user/purchasers normally understand that term)
and therefore those with the most skin in the game are, again,
producers, vendors, and designers, not users or even operators.
The latter are important for figuring out whether a particular
facility will meet identified needs, but that is typically more
of a review function than a design one. If we need more input
about such specs, we might ask the various *NOGs or similar
groups to formally review proposed specifications rather than
depending on people to come to f2f IETF meetings or even to
follow our mailing lists. So, while closer contact with
operator communities is always good (and not just for that
Area), we may need to adjust our expectations to the reality of
what we can do effectively, rather than forcing on broadening
participation for its own sake.
(4) There are some areas of work in the IETF in which very broad
geographic input --more accurately, broad cultural and
linguistic input-- are absolutely essential. For example, the
more we move into internationalization or make decisions that
dictate or constrain user interfaces, the more danger we get
into of making really stupid decisions if we don't have broad
and diverse participation and input. To a degree, the same
issue shows up in lower layers of the stack. For example, the
vast majority of us spend our time using current-technology
hardware, fast and high-capacity connections to the public
Internet, and even faster LANs. We often subconsciously design
for that sort of environment because we don't encounter the
other kinds on a regular basis. I contend that we have a
relatively poor history of protocol decisions when people are
affected whose day-to-day technology is a decade or two behind
our current experience.
(5) There are a lot of non-vendor participants in the IETF and
even ones whose days as producers of implementations are mostly
over, but it is still a relatively small minority (and, as far
as I can tell, getting smaller). As a member of that group, I
wish it were larger, both for balance and because I think that
we may have an easier time maintaining focus on the overall
well-being of the Internet as a complete system than people
whose focus is getting the next product specified, implemented,
and into the hands of users (or marketing organizations). But,
if we contribute usefully, it is mostly because we bring
considerable experience or perspective of one sort or another to
the table. With rare (and occasionally very important)
exceptions that include people from the research side of the
community, a newly-minted engineer who has no producer
organization affiliation to provide context is unlikely to be
useful to us (and is reasonably likely to have a frustrating
experience no matter what we do about "newcomers" or recruiting).
(6) The IETF is (or has become) primarily an engineering and
protocol design and standardization organization, something that
was recognized over two decades ago when the community kept the
IRTF separate but got rid of all the other non-IETF task forces.
While we could try to "diversify" to include a much broader base
of experience and interests that do not focus directly on our
current range of activities, it is likely that doing so would
increase noise without adding much to the signal.
One thing that all of those observations have in common is that
none of them are likely to be affected by a single meeting in a
single location. Probably holding a whole year or two of
meetings in the same general vicinity wouldn't make any
significant difference either, at least after we moved on.
Borrowing from some of the discussions about mentoring during
and after IETF 86, I suggest that, if we really want to
encourage active participation from places where we now have
very little, we would:
(i) Try to increase awareness of the IETF and what it does in
those areas, via ISOC chapters, lectures, and other forms of
contact. Variations on this have been suggested by others.
Note that doing this for a given location would require putting,
at most, one or two people on airplanes (possibly at IETF or
ISOC expense), not order 1000 of us at individual or company
expense. (See George Michaelson's most recent note in the "IETF
Meeting in South America" thread.)
(ii) Try to assign a document process advisor to each newcomer
the first time that person posts an I-D (or earlier if we can
determine that an I-D is in progress or should be generated from
other discussions). This is a little different from a mentor
(see Iiii)) in that the role would be to specifically advise on
the process of getting a document through the system, what
obstacles are likely to be encountered, etc., and could be
pretty aggressive if that were necessary. The process advisor
could recommend that that author seek out other resources,
including a mentor or editorial help, when necessary. The
IETF's curmudgeon component, many of whom would make lousy
mentors, might still be good document process advisors.
(iii) Allow new participants who intend to participate remotely
and by mailing list to request and be assigned mentors, ideally
mentors who speak the participant's primary language. Focusing
our efforts only on people who show up at meetings means that we
leave the folks who could be among our more productive
participants in the cold and, for most regions where we have
little penetration and resources are a problem, pretty much
guarantees that it will stay that way.
(iv) Encourage ISOC to redesign the IETF Fellows program so that
people who were reasonable candidates for long-term
participation were tracked differently from the
observer-tourists. In the potential participant track, the
assumption should be that Fellows might have participated
remotely (including by mailing list) already, that such
participation would give a candidate Fellow some extra priority
or points in the selection process, and that activities during
IETF should include explicit and focused discussions of optimal
ways to participate without attending meetings. If we (or ISOC,
or other organizations) later get the Fellows to more meetings,
that would be great, but the goal should be to make a good
remote participant, not people who can be effective only if they
attend a lot of face to face meetings.
The above would not be easy. It would require a large number of
experienced members of the community to make a major commitment
to working with new authors and non-attendee newcomers. But it
would help significantly to bridge the gap between "interested
in the IETF and its work" and "contributing participant".
Flying a thousand person-weeks worth of folks into an area where
we have little participation and attracting a few local tourists
won't have the same effect --with or without a few hours of
"newcomer" sessions-- and will still leave people with the need
to make that transition if they are going to be effective.
best,
john