On May 30, 2013, at 1:24 PM, John C Klensin <john-i...@jck.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-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. 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 > <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 > > > -- Don't be impressed with unintelligible stuff said condescendingly. -- Radia Perlman.
