Hi, The IETF has always stressed a bottom-up approach, taking ideas and "running code" contributed by the community for new networking functionality, ranging from disruptive to purely maintenance, and deciding whether there was IETF consensus to work on standardizing the functionality.
Typically contributed functionality is described in Internet-drafts so the IETF community can better understand the technology being proposed. This approach also helps to ensure the IETF doesn't become a forum for marketing press releases or other inappropriate usage of scarce IETF face-to-face time. Originally, BOFs were simply side meetings, often in bars, for an informal discussion of a new idea. There were no IPR rules, no requirements for an internet-draft first, and so on. Meeting in a bar allowed people to discuss *ideas* without the formality of requesting an IETF session. But there is a practical limit to the size of audience who can meet in a bar, to exchange ideas on bar-napkins. To supplement bar-bofs [rfc6771], the IETF standardized BOFs explicitly designed to allow the presentation of new ideas to the community, permitting larger audiences to gather in a room and have their meeting announced. BOFs, however, grew very quickly to meetings that might include food and alcohol provided by the idea proponents, and became more formal over time, with officially scheduled sessions, BOF chairs, microphones, and the whole shebang. Internet-drafts are typically required before a BOF session will be approved. Area directors realized there was a real downside to the increasing formality of BOFs - interesting ideas in the real world were not being brought into the IETF because the requirements to get a BOF session had become a hurdle. The IETF ignores what is happening around it in the real world at its own peril. Ignoring important new relevant technologies, especially potentially disruptive technologies, risks the IETF being "overtaken by events". If we want to stay relevant to the industry we support, we must be willing to listen to new ideas even if they do not come in the form of internet-drafts. Area meetings then became a venue for what some directors refer to as "mini-BOFs" - a larger audience than the bar-napkin discussions afford, but less formal than BOFs. An internet-draft would be nice so people knew where to look to find a discussion of the technology. However, the real goal is to get the industry to come into the IETF to talk about interesting and relevant technologies they have been working on outside the IETF. David Harrington ietf...@comcast.net +1-603-828-1401 > -----Original Message----- > From: tsv-area-boun...@ietf.org [mailto:tsv-area-boun...@ietf.org] On > Behalf Of Wesley Eddy > Sent: Saturday, July 06, 2013 10:11 PM > To: l.w...@surrey.ac.uk > Cc: tsv-area@ietf.org > Subject: Re: Draft agenda for the IETF-87 TSV Area meeting uploaded > > On 7/6/2013 5:52 PM, l.w...@surrey.ac.uk wrote: > > > > IETF transport focuses on maintaining its existing standards; that's > > my point. It's not really set up for experimental work not directly > > related to those standards. > > > > > I'm not really sure how TSV could be setup any better to do this type of work. > It could be a matter of opinion how "directly related" the experimental work > is. For instance, CONEX is built on ECN, MPTCP is built on TCP, and RMCAT is > building on RTP ... but all are such significant developments that they can't be > classed as simply "maintenance". In Berlin, TSV has 2 BoFs planned in Berlin > which are not jst maintenance of existing standards (TCMTF and AQM). > Clearly, there are also important existing protocols (TCP, SCTP, etc) that a lot > of TSV energy goes into maintaining, but that's certainly not all that we do. > > The community focuses on what it chooses to, by individuals (and companies > sponsoring them) investing time and energy into the WGs and drafts that > they have shared interests in. For some experimental things, that can be > difficult because it requires a critical mass, and people have to be willing to > work together at whatever pace the group adapts. Larger groups will have > slower paces. > > The hope is that we wind up with better specs, less flaws, and stronger > interop between multiple codebases as a result of working together, and > create a better Internet. Those are not the priority for every protocol > development effort, and a lot of people have good reasons for doing things > on their own. This does not signal a problem with the IETF. > > -- > Wes Eddy > MTI Systems
