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-i...@jck.com> wrote:
> --On Thursday, May 30, 2013 08:03 +0000 "Eliot Lear (elear)"
> <el...@cisco.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
<el...@cisco.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
