Re: [IETF] Re: Issues in wider geographic participation


On May 30, 2013, at 1:24 PM, John C Klensin <john-ietf(_at_)jck(_dot_)com> 
wrote:

Forwarding a discussion that started offlist for operational
reasons with permission.  I've tried to elide some irrelevant
material; I hope that, if Eliot thinks it was relevant after
all, he will add it back in once he gets to an appropriate
machine.

--On Thursday, May 30, 2013 09:20 -0400 John C Klensin
<john-ietf(_at_)jck(_dot_)com> wrote:

--On Thursday, May 30, 2013 08:03 +0000 "Eliot Lear (elear)"
<elear(_at_)cisco(_dot_)com> wrote:

If we subscribe wholly to this then to borrow from Darth
Vader, our failure is complete. As you and I have discussed
and debated, our engineering choices make certain assumptions
about what problems are high order and which ones we can
safely ignore.  An example is bandwidth.


Eliot, I think --or at least hope-- that either you have
misunderstood me or that I have misunderstood your response.

I'm not talking about bandwidth.  I'm talking about protocols
that don't work well under less than optimal circumstances.
And I'm arguing for awareness and case-by-case understanding of
tradeoffs, not somehow designing for the bottom.   We've seen
implementations that appear to be in full conformance to IETF
specifications that simply die with packet timeouts and
retransmissions.  Perhaps that is just failure to document the
use cases and limitations, perhaps it is failure to describe
the edge cases and what to do about them.  I'm disinclined to
entirely blame implementers who make a good-faith effort to
follow IETF specs carefully: if our documents don't permit them
to get things right, I think at least part of the failure is
ours for failure to cover those cases in specifications.  

We have recognized the issues with some specs and work areas,
including trying to promote delay-tolerant efforts -- whether
the environments be Mars or reindeer-based mobile stations in
areas considerably north of Jari.  In others, we have waved
them off.

The IETF was formed in part to have rapid impact, and by
necessity that required operators and even some users who we
later decided to call application developers.


Sure.  I'm not suggesting pushing either out.  I am suggesting
that more diversity in those groups would be of benefit.   I'm
also suggesting that, while including people and review
processes who can speak with good experience from operator
perspectives would be of huge benefit, that we don't want to
expand into an operator forum.  That means that the operational
folks we want are operational folks who can also speak usefully
to protocol issues.  As what I think is a corollary, I think
that beating the bushes in developing countries to try to get
more operators and end users to attend the IETF as an end in
itself is not a productive activity from an IETF standpoint.
And, yes, I think we should be seeking reviewer partnerships
with the NOGs (and maybe others) for certain classes of
protocol specifications rather than expecting people who
frequent those groups to participate actively in the IETF...
and excluding whatever valuable input they might have if they
don't.  We have tried the latter model and, IMO, failed.


The below is not a direct response to John, it is more my general views on IETF 
interaction with operators.

So, I've been a long time participant in some NOG's and still (perhaps 
incorrectly) view myself as an operator.
I've spent significant time thinking about / discussing the issue of 
insufficient operator involvement in the IETF, trying to understand some of the 
causes.
I've tried to summarize some of the operators' views below, and also some 
thoughts on how we might be able to work better / get more operator input. 

I think that at the root of much of the problem is cultural differences -- if 
we want more operator involvement / feedback there needs to be some attention 
paid (by both the operators and the IETF folk) to understanding these 
differences, and taking care to respect / accommodate the other side's culture. 

Please note: I am discussing the "operator" and "IETF participant" as 
stereotypes, obviously the reality is much more nuanced than I'm presenting. 
These stereotypes probably don't include you -- they are simply generalizations 
to try and present the different sides of the issue.


These are some of the concerns I have heard from operators:

1: The work in the IETF simply takes too long.
"I actually operate a network, and so I need results *soon*. I really don't 
want to spend months debating if requiring foo is a 'should' or a 'SHOULD', I 
just want my feature NOW."
"I give $vendor large amounts of money each year -- if I actually want a 
feature I just wave cash at them / threaten to move to $other_vendor and 
they'll add it for me."

I saw this for myself in DANE. During the time it took us to get chartered, 
write a use case document, have endless navel-gazing exercises, meet a few 
times, and then finally publish a document, a set of folk implemented a few 
alternate solutions in the real world, got some useful understanding of what 
works and what doesn't, iterated, and moved on to other things. Sure, we chairs 
could have moved thing along faster, but the IETF cycles *is* long.


2: Ivory towerism / academics.
"The work that the IETF is doing is not actually relevant to what I need."
A large number of drafts don't really explain what issue they are trying to 
address (poor problem statement) and / or are trying to address issues that 
don't actually exist in the real world. Often drafts try to address an issue 
that only exists in one small corner case on one participant's network, or 
issues that *used* to be important, but have now becomes less so as networks 
have evolved.

The DHCPv6 discussions spring to mind here -- the IETF view (hey,  I mentioned 
generalization above!)  on DHCP / SLAAC were grounded in one view of how the 
world worked / elegance, but the operator's view was that they simply wanted 
something that works like it does in V4.

This is somewhat of a vicious cycle -- operators participate less, and so the 
IETF understands less about how their networks run. This leads to solutions 
that don't understand the real world, and so operators lose faith/interest in 
IETF, and participate even less.

Many of the drafts written are either being pushed for commercial reasons, or 
because it is someone's pet project, not because they solve a critical issue 
for others.
Randy's article on "Testing Spaghetti — A Wall’s Point of View" 
(http://archive.psg.com/051000.sigcomm-ivtf.pdf) speaks mainly to the 
commercial interests, but Jon also had this to say:
"It's perfectly appropriate to be upset. I thought of it in a slightly 
different way--like a space that we were exploring and, in the early days, we 
figured out this consistent path through the space: IP, TCP, and so on. What's 
been happening over the last few years is that the IETF is filling the rest of 
the space with every alternative approach, not necessarily any better. Every 
possible alternative is now being written down. And it's not useful."
I know that I for one am guilty of this -- I wrote and have been slowly pushing 
a draft on Omniscient AS112 servers (draft-wkumari-dnsop-omniscient-as112) -- 
this is by far not the most important issue in DNS, nor in the Internet. It 
*does* solve an (IMO) important issue, but there are more important issues that 
*should* be worked on -- this one however is interesting / important *to me*, 
and so that's where I spent some cycles. 


3: I have real work to do -- I simply don't have the cycles to read a few 
thousand mails about some tiny unimportant detail.
This is related to items 1 and 2. 
Related to this is the fact that most operators can only justify attending a 
small number of conferences -- attending 3 IETFs and 3 NANOG / RIPE / whatever 
is simply too much.
 
I don't really know if this is an problems that can (or should) be solved. 
Often operators are more pragmatic than IETF folk, and simply want a good 
solution, not necessarily a perfect solution. "The perfect is the enemy of the 
good" -- this often leads is to create a solutions that is overly complex,  and 
/ or solves a problem too late…
This is (IMO) a cultural difference / an artifact that protocol design *needs* 
more precision / rigor than operations, as it is much harder to change once 
baked.

4: I tried participating, but I got ignored / attacked.
Unfortunately I think that this is one of the bigger cultural issues, and one 
of the harder ones to address. 
The IETF is in many ways a debating society -- you present an idea / draft, and 
folk challenge (in what could often be interpreted as a confrontational manner) 
what you've said.
This is simply part, and a much needed part, of the IETF culture -- if you've 
said something and no-one is challenging it, chances are is was not very 
interesting / novel. The purpose of saying something in the IETF context 
(should be) to get critical feedback so you can improve it. 
If, however, you are not expecting this / are not used to it, this interaction 
can come across as rude  / antagonistic. Folk can feel as though they are being 
attacked personally, and not simply being presented with an opportunity to 
better explain their ideas / improve them. 
I realize that this is all touchy-feely / some folk will think that everyone 
just needs to wear their big boy pants, but if you are willing to take a step 
back and consider how different cultures interpret interactions…

There are some other cultural issues at play here.
I have seen instances where an operator comes along to try and participate, but 
doesn't understand that, while they have credibility / standing in their own 
community, they are an unknown entity in the IETF community. When entering a 
new community one needs to learn the norms, and it takes time to establish your 
reputation / credibility. This can lead to frustration with item 4.

A large number of IETF participants are also senior within their organizations, 
and migrated up though operations to their current position, often managing 
operates along the way. Sometimes it is hard to admit to oneself that one has 
lost touch with one's roots, and so operates can come across as "upstarts" and 
be looked down upon by IETF participants. This causes friction.
This is partly reflected in some of the discussions one hears in threads like 
this / general hallway discussions -- we often hear about how the IETF would 
like more operators to be involved / attend, but one very seldom hears IETF 
participants trying to become more involved in operations / participate in 
their local NOGs, etc.


Anyway, these are simply my (much simplified) views on a complex topic, much 
more complex than can be easily captured in a single mail. But somebody is 
demanding their soapbox back, so I will end here.

W


[...]

To be sure, the ecosystem is different, and yet we have blind
spots like spam. Put in the vernacular some of us need to get
out a bit more.


As you know, I disagree with you about where the spam-related
blind spots are and what to do about them.  But I think that is
a separate issue.  We probably agree about getting out more
too.


Eliot then responded...


--On Thursday, May 30, 2013 15:24 +0200 Eliot Lear
<elear(_at_)cisco(_dot_)com> wrote:

John,

On this one point:

On 5/30/13 3:20 PM, John C Klensin wrote:

And, yes, I think we should be seeking reviewer partnerships
with the NOGs (and maybe others) for certain classes of
protocol specifications rather than expecting people who
frequent those groups to participate actively in the IETF..


Expectations of participation aside, how would you suggest
proceeding wrt NOGs?


As you know, I'm opposed to inventing organizational structure
unless it is clearly necessary.   I would like to ass some
IETF-NOG discussions about whether it would be appropriate to
announce Last Calls for particularly relevant protocols on their
mailing lists and provide a way for relevant operations folks to
respond without subjecting themselves to the noise level
associated with a subscription to the IETF list.   If some NOG
wanted to put institutional positions together, I don't think we
should object, but I don't think that is either necessary or
particularly desirable.

If getting good reviews from broader perspectives that way
required that we sometimes extend Last Calls to four weeks when
RFC 2026 allows two, I think that would be a good tradeoff.

I hope we can trust the IESG to make sound decisions about what
protocols are particularly relevant and to use feedback from the
recipients of those notifications to adjust those decisions if
necessary.

None of the above is a broad solution to a broad class of
problems.  But I think it would increase opportunities for
quality reviews and would allow some relevant people
--especially from areas with little IETF involvement-- to help
themselves and us out without signing up for "IETF
participation".  If we could then suck them in gradually, so
much the better.

Finally, fwiw, I wasn't part of the discussions that created the
IETF (I was "getting out" into some work that did not involve
Internet protocol design but that definitely involved
resource-poor communities), so I can't judge whether "The IETF
was formed in part to have rapid impact".  But, to the extent to
which it is the case, I think we gave up any claim we had to
needing to shortcut either reviews or openness in the interest
of speed when our minimum time to get almost anything
standards-related done passed a year and kept climbing.   YMMD,
of course.

   best,
   john


--
Don't be impressed with unintelligible stuff said condescendingly.
    -- Radia Perlman.