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.
[...]
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