IETF 87 Technical Plenary Minutes Berlin, Germany Monday, 29 July 2013 Minutes by Cindy Morgan, IETF Secretariat 1. IAB Chair Report Russ Housley delivered the IAB Chair report: http://www.ietf.org/proceedings/87/slides/slides-87-iab-techplenary-4.ppt Spencer Dawkins stepped down from the IAB in March to take the position of Transport Area Director. Russ Housley thanked Spencer Dawkins for his service on the IAB. The 2012-2013 NomCom appointed Erik Nordmark to the IAB to fill the vacancy left by Spencer Dawkins. 2. IRTF Chair Report Lars Eggert delivered the IRTF Chair report: http://www.ietf.org/proceedings/87/slides/slides-87-iab-techplenary-2.pptx 3. RSE and RSOC Chair Report Heather Flanagan delivered the RSE report and Alexey Melnikov delivered the RSOC Chair report: http://www.ietf.org/proceedings/87/slides/slides-87-iab-techplenary-3.pptx Fred Baker, Ole Jacobsen, John Klensin, and Olaf Kolkman were thanked for their service on the RSOC. Bernard Aboba, Joe Hildebrand and Tony Hansen were introduced as new members of the RSOC. 4. Technical Topic: Opus Codec The OPUS codec, defined in RFC 6716, can scale from low bit-rate narrowband speech to very high quality stereo music, making it suitable for a wide range of audio applications. This session covers the past and future of Opus as well as the lessons learned that could apply to future IETF work. Jean-Marc Valin introduced and gave an overview of the technical topic for the evening, the Opus Codec. Greg Maxwell spoke about the testing work done on Opus. Peter Saint-Andre presented a history of the Opus codec in the IETF. Jean-Marc Valin and Tim Terriberry spoke about future work on Opus. Tim Terriberry spoke about Opus deployment in Firefox. Justin Uberti spoke about Opus deployment at Google. Emil Ivov spoke about audio codecs in Jitsi. Lorenzo Miniero spoke about Opus integration in Asterisk. Slides: http://www.ietf.org/proceedings/87/slides/slides-87-iab-techplenary-5.pdf Reference: http://trac.tools.ietf.org/group/iab/trac/wiki/IETF-87 At the end of the presentation, the microphones were opened for questions from the audience. A summary of the Q-and-A session follows: ROBERT BENZ: The message on one of your slides was that in WebRTC you have implemented both Opus and G.711. But from the view of an operator, when they push traffic from the good old PSTN to an IP-based environment, did you perform any tests concerning facsimile or modem transmissions? GREG MAXWELL: We've done some TTY testing over Opus, but there's been no facsimile testing that I'm aware of. Of course, in those cases you could be running G.711 and then that is more dependent on the implementation's jitter buffer and things like that, if they survive through it. JOHN LEVINE: I don't know if this is a dumb question or not, but could you tell us a little but about how the codec actually works? You said that it has a wide variety of models and it somehow adapts, but can you tell us what sort of sound model does it have, and how does it figure out when to adapt? JEAN-MARC VALIN: Without going into too much detail--and by the way, there are technical papers on http://opus-codec.org/--The general idea is that the two main components, SILK and CELP, use different technologies. The SILK part uses linear prediction, like most speech codecs, so it's got a good model for speech. On the other side, the CELP part uses discrete cosine transform coding, a bit like MP3 or AAC would use, which is usually for music, although it does handle speech. So we've got two different models, and we now have detection between speech and music to figure out which will be the most efficient for this particular signal. And at a certain rate, because there are some rates at which you'd want to use one or the other, regardless of whether it's speech or music. KALYANI BOGINENI: I would like to understand the optimizations you mentioned for mobile CPUs. Is there any plan or scheduled timeline for when the optimizations will be done? And my second question is, this is a 48-kilobit codec; when the optimization is done would these go at a lower rate? JEAN-MARC VALIN: So, the optimizations we listed are related to decoding music at higher sampling rates. Those are currently available in a beta release of 1.1 that was available at least two weeks ago. When it comes to lower sampling rates, like 8 kilobits per second, there are some people working on the optimization right now, but none of it is currently available. TIM TERRIBERRY: The fixed point macros have ARM optimizations that also apply to low-bit rate voice decoding. We have people working on it. HANNES TSCHOFENIG: The work on Opus was quite successful. Do you have lessons for those who work in other IETF working groups about how to recreate the same sort of success? What would help others be as successful as you were? TIM TERRIBERRY: The big lesson for me was that when people come up and point out the shortcomings in what you've done, the best response is to actually go back and do the work. People pointed out that we didn't actually support switching between all these different modes, and that made it very difficult to pick in advance which mode you wanted to use, because you had to know what you were using the codec for, and what the conditions of your network were going to be. So we sat down, and we said, "Well, that's a hard problem, but we can solve it." And we put in the elbow grease to solve it. And I think the result we got out of it speaks for itself. JEAN-MARC VALIN: Another part of that answer is that since the very beginning, we've been helping implementers actually use Opus while it was in development, and we were working very closely with them to get feedback and move it in the direction they wanted. That proved very useful. GREG MAXWELL: Even in cases where the implementers or users of Opus didn't directly get their hands too dirty in the process, the core group of active participants in the working group were still able to leverage their feedback, and that was really important. We didn't need to be too snooty about how people participated--just use it, expose results, get your needs. And the people who were working on it the most kept their noses to the grindstone and that worked well. ERIC BURGER: With my perpetually paranoid hat on--I'm looking around for Jorge Contreras, the IETF lawyer, is he here? I will speak slowly to make sure it is in the audio log, and hopefully someone will put it in the minutes. Of the many IPR disclosures, all are royalty-free except for three companies that declared RAND [reasonable and non- discriminatory licensing] IPR. The IETF is not promising that the codec doesn't have other undeclared IPR. So do not come crying to the IETF if someone pops up with IPR. To the best of our knowledge, no one has declared any IPR beyond what is on the site, but that is no guarantee that there is no other IPR out there. CULLEN JENNINGS: Until you said, "To the best of our knowledge, no one has declared any." To the best of our knowledge, several have declared. ERIC BURGER: Yes, several have declared. There are seven companies with 13 disclosures. Of the seven companies, three of them did RAND; two of them said no matter what, it's royalty-free; one said it's royalty-free as long as you don't sue us over codecs; and one said it's royalty-free as long as you license us your entire patent portfolio for free. [Laughter from audience.] So again, don't come to the IETF if someone else comes up. There may be others out there. Your mileage may vary. TIM TERRIBERRY: To be clear, we did work with two companies to get license terms that were slightly more reasonable. BERNARD ABOBA: Any additional questions? Okay, thank you very much. [Applause.] 5. Open Mic The IAB took the stage and introduced themselves: - Bernard Aboba - Jari Arkko (IETF Chair) - Mary Barnes (Executive Director, ex officio) - Marc Blanchet - Ross Callon - Alissa Cooper - Spencer Dawkins - Joel Halpern - Russ Housley (IAB Chair) - Eliot Lear - Xing Li - Erik Nordmark - Andrew Sullivan - Dave Thaler - Hannes Tschofenig Lars Eggert (as IRTF Chair) and Heather Flanagan (as RSE) joined the IAB on stage for the open microphone session. An edited transcript of that open microphone session follows: OLAF KOLKMAN: This is a question to the IAB in its responsibility for oversight of the standards process. It's a bit of a rhetorical question, in the sense that it will end with, does the IAB have any idea what we can do? So bear with me. There are several places where several of us are interacting with third parties, trying to explain that open standards developed by global SDOs are of high quality and are good stuff. When we do that, we often have to explain the difference between Proposed and Internet Standards. And the language that is then thrown back at us is language from RFC 2026 section 4.1.1, which says that implementors should treat Proposed Standards as immature specifications. Now, obviously, we know that the Internet runs on Proposed Standards. And we, collectively, know that the judge of quality is deployed, running code instead of nation votes. I have to acknowledge Sean Turner for that quote. But having to explain this ad nauseum is difficult. It is really a matter of explaining why the IETF doesn't take its own quality control processes seriously. It is a matter of having to explain that there is quality control in the IETF, but it is quality control that is pooled by the energy of the participants in this room. I think there are two solutions to this. Either we collectively take our own processes seriously and try to move our own documents up the standards ladder, or we rewrite our processes to mirror current realities. But having to tell the story over and over and over again what it means to have a Proposed Standard, and that the Internet actually runs over these things, while our documentation says these things are immature, doesn't really help. So, back to the beginning question: is there something you can do about this? And again, this is more rhetorical to the people in this room. RUSS HOUSLEY: There is a little bit of irony here that a past IAB Chair is asking the IAB a question about this when the current IAB Chair is the one who led the charge to change this part of the RFC. OLAF KOLKMAN: I was appointed to the body where I have to defend this after I left the IAB. ELIOT LEAR: On that last point, people may not know all Olaf does. Even after Olaf stepped off the board, he has spent an enormous amount of time to defend and to advance the IETF's views on standardization. I want to thank you for the work that you're doing, because you're doing it on behalf of all of us. [Applause.] You work with a lot of governments, and now to your question, this came up earlier today in the Applications Area Meeting. There is a gentleman who used to participate in the IETF, maybe peripherally, but he was involved in the standardization of NNTP and a few other things, by the name of Brian Kantor at UCSD, and he has a great quote that I keep with me, which is that oftentimes, what RFCs and standards should be about is documenting running code. So if our processes are broken, we should fix them. We've just gone from three to two; maybe we need to think about how we get from the first step to the second step again, and I don't have an answer to your question today, but I think it is worth thinking about. ROSS CALLON: I think you have a good point. I would be inclined--I think the alternative is either find a way to get us to advance our mature standards to [Internet] Standards, or we go back to one step instead of two. Personally, I would be more inclined to try the first of those. I think if we want to do the latter, then the IAB might be involved. For the former, where the point is we want to start moving our standards forward in our own process, that's largely a comment for the IESG and even more so for the Working Group chairs and document authors. I am inclined, since I happen to be a Working Group chair, to go back to my Working Group and ask which they think are stable, have been deployed for a long time, and ought to be moved along in the process. You've reminded me and others that we should be doing that. It's a very valid point--thank you. JARI ARKKO: I am a big believer of aligning the IETF specifications with reality. Maybe having Olaf write that one-liner RFC that says the internet runs on Proposed Standards. That's actually a fine approach, from my perspective, and it doesn't even have to prohibit us having some documents marked as having more evidence of having been in good shape. I think we need to get over the notion of us having 2026 and other documents that are so sacred that they cannot be adjusted to current reality. It is just something that we need to do. SCOTT BRADNER: We just went through your change of reducing by one and not solving any known problem. We had an opportunity at that time to deal with this particular thing that Olaf brings up, which I think is a concrete and real problem. It's a problem that can be looked at in two different ways. One, it's a problem of documentation. The way the IESG has worked for a number of years is that something is approved on the Standards Track as a Proposed Standard when it is finally done, and truly all known problems have been solved. It is easily the equivalent of a Full Standard for almost every other organization. That's the way the IESG has been acting in the last dozen years. I had an Internet- Draft not that long ago with John Klensin saying that that's not what 2026 says. 2026 says that Proposed Standard is an experiment. If we're not going to do that, then we should either change our text to say that we're not doing that, or we should go back to doing that. Get the IESG to back down, to believe that they will see this document again. But I don't think that they will see it again, or back down for that matter, because the underlying problem is not that people refuse to move things along the standards track. It's that they don't have any reason to. You've done your work, it's working out there, there are a lot of people who have deployed it, and your boss wants you to work on something new. He doesn't want you to work on the same crap. There is no real incentive for doing it. At one point, there were companies that gave rewards if you got something to Full [Internet] Standard, that were different from the rewards you just got for publishing an RFC. We don't have that anymore. And certainly that wouldn't be an IETF thingy anyway, even if individual companies might do it. So I don't know an easy way out of this. But we did have the opportunity when doing [RFC 6410] to change the definition to better match the reality of the way it's done, which is more along the line of what Olaf would like here. THOMAS NARTEN: A question for Olaf; this is really to turn it around. I don't want to talk about should we change our processes, because we've had this conversation many times, and it's painful. But I think it is important for this community to understand what the real problem is here. And Olaf, who is it you're going to and having to explain it, and what is the reaction, and why is this painful, and how does this impact the IETF's bottom line? OLAF KOLKMAN: The context in which this came up for me is that I am representing the IETF in the so-called Multi-stakeholder Platform for European ICT Standardization (MSP). It's a body that advises the European Commission on all matters [relating to] standards, but also has a second mandate, which is the identification of specifications that are allowed to be used in procurement by European governments. European governments are not allowed to point to not-formal standards. They are only allowed to point to formal standards when doing procurement. This process is being put in place to identify documents like RFCs, like W3C specifications, like IEEE specifications, those that are not numbered by ISO, to allow them to be used in procurement. There is not a lot of running code there. We just went through the exercise to identify specifications for IPv6, which is a whole bunch of RFCs that are basically all at Proposed Standard. We managed to get language in that says, "Okay, these are all at Proposed Standard," but that means that when an entity in the MSP wants to challenge that, they are free to do so because they're at Proposed Standard. There might be sufficient running code, but it is in that context that we have to explain, and there is language in the identification document that says this stuff is immature. And that's not good. THOMAS NARTEN: So in a sense, this puts the IETF at a disadvantage when compared to other standards organizations. That may not be a big deal from an engineering perspective, but it is a big deal in other circles. OLAF KOLKMAN: This is Layer 9, absolutely. STEPHEN FARRELL: Last time we had an IAB-sponsored BOF about WCIT, and post-WCIT, and telling the community about some of that. I got a sense at the end of it that there was going to be some way for the community to provide input, because that WCIT thing is just one of many processes that are going to go on. How is the IAB working to keep the community informed about this? JOEL HALPERN: We did hear the community at the BOF. We've been having discussions to try to figure out where this is going, and we are trying to find an effective way to involve the community. We will tell the community as soon as we have a useful answer as to how we're going to communicate more interactively, not just telling them things, but listening as well. STEPHEN FARRELL: From that I take it that yes, there will be a way for the community to provide their input. JOEL HALPERN: Yes. STEPHEN FARRELL: Great! RUSS HOUSLEY: It's fair to note that WCIT wasn't a one-time event. There are lots of similar things we are trying to stay on top of, and we will bring to the community things that are coming along that will be affecting the Internet. SEAN TURNER: Buried in one of the reports that they didn't throw up on the screen is that I represented ISOC at a different SDO meeting, and it was really interesting to come and have one of the national bodies come and say to me, "I don't even understand why the IETF is here; you only have 94 Internet Standards." And so of course I chuckled the whole time and was like, "You got here because of the Internet, right?" So we ran through how they sent their emails around and sent their slides and the whole nine yards. That was lost, essentially, because they are using our own documents against us. The concern I have is that it emboldens them to then work on technology because there is no international standard to their definition in that space. So then they can feel emboldened to go and do work on that, which essentially steps on other peoples' toes. So that's one of my concerns. ELIOT LEAR: The point there is that if people in other standards bodies feel there isn't a standard, then they get into the pool. Then we get into having this market confusion as a result, and multiple standards. SEAN TURNER: I think we all know it's a paper argument, but it rings true for some people, and it's really hard to fight that thing when they can pull it out and point at those three words. DAVE CROCKER: We have a demonstration that the full standard mechanism can work. It happened to be triggered because I felt like it. It just occurred to me one day that we could do that for DKIM, so I put it in the mill, and it worked. It was amusing to watch some people in the community and some people on the IESG think that the process included their being able to go back to first principles in considering the spec, which was not what that step is about. And so there is an optimization that would be erasable to consider in the future. But it wasn't a big deal. But that said, I don't think it's actually all that relevant to this topic. This topic is about political attack by other groups that want to undermine the IETF. When you're in political space, you need to think politically. One of the things you don't do is let the other side set the agenda. Everything we've talked about so far tonight is about letting the other side set the agenda. If we fix this, they'll find something else, and then we'll have to go fix that, and we'll spend all our time attending to problems that aren't fundamental to the work we're doing or the benefit that we're giving. So if somebody is challenging the reality that we have here, there are two different audiences. There is somebody who's really confused, in which case the response is, "It's bureaucratic, it's screwed up; every bureaucracy is screwed up. The reality is we turn out useful specs and they get used--you're using them today." If it's a political opponent, walk on. Just ignore them. OLAF KOLKMAN: Even for ourselves, I think it is relevant that we get our work done in a better way--and that's good for us--if our documentation reflects reality. If we are a professional organization, our documentation should reflect reality. It's not about bureaucracy or something; it's about people that come in and look at the documents and understand immediately what is happening and do not have to talk to five other people to understand that a Proposed Standard is actually at a high level. JARI ARKKO: Dave raises a good point. I'd like to raise a related point, which is that we can't respond to 7 million organizations having an issue with the IETF or Internet Standards--it doesn't scale. We have to go back to our own principles, and one of those principles of course should be that our documents be consistent. Shocking, I know, but that would be useful in some instances. Getting our own thing together, rather than responding on their agenda would be the first order of business, from my perspective. MARC BLANCHET: This is a problem we need to fix, but as Dave said, I think we need to be careful in putting too much burden on the process of the organization at the time. I think we need to find some solution that would make it better without a big burden of going through all of the RFCS. KEITH MOORE: We should realize by now that eliminating the step of Draft Standard did not solve any problem. At most, what it did was make the problem clearer. We are lousy at maintaining specifications. Once we get things out the door, if it gets maintained, it's kind of a rare, happy occurrence, not a matter of course. The reason for this is that we have structured our organization for about 20 years to doing new work, and we have not figured out how to provide incentives and attract people who are interested in doing maintenance. We've got those problems; we need to address them. But we're not going to address it by eliminating yet another step in the standards process. We're not going to address it by doing business the way we've done it for the past 20 years. We're going to have to change some things about the structure of the organization, and the kinds of incentives we provide, about how we do business. I don't even know that the answers are, but we can't continue to have the same habits that haven't been working. I'm not even sure who is supposed to address that, but it needs to be looked at. The other problem is that we operate in open-loop mode as far as the rest of the world is concerned. What I mean by that is, we do what we do here because we think it's good, and we don't pay a lot of attention to the way our organization is looked at by anyone outside the organization. That's not just other standards bodies or governments that want to use standards bodies, that's the entire user community. We really don't pay much attention to this. We don't say, "What do those people need, and how do we serve it?" We need to take a really serious look at that. ALISSA COOPER: Keith, who does maintenance better, and to what effect? KEITH MOORE: I don't know. I'm so busy with this organization that I don't spend a lot of time paying attention to other organizations. ALISSA COOPER: I'm just wondering what the standard is. KEITH MOORE: There's a saying that seems to be applicable here, that mediocrity is excellence at pursuing the mean. We need to figure out what's needed and do that, not compare ourselves to other organizations. MARC BLANCHET: While Olaf was talking, I re-read the section in 2026 that he was referring to, and to me, that section is not that bad. Maybe the fix is just some wordsmithing. But I don't think we should be spending time here for the solution, what I'm saying is that there are many ways to fix a solution. LARRY MASINTER: I'm very concerned about maintenance. I get a lot of calls to update docs I worked on 15 years ago, because there is nobody interested in maintenance. There is a substantial community that is pursuing an alternative method of standards development, by treating standards as specifications built using open-source, rather than a standards process. Rather than a series of versions, you have a living standard. The document is edited; you can maintain it, you can add new features. The status of features are noted in the document. It's a fairly radical proposal, but I think no modest proposal, no small number of changes is going to get us into a situation where we have a mechanism for maintaining documents that have no active new work but fixing bugs. The errata processes is inadequate. Once you have a standard that is frozen, it's completely antithetical to fixing bugs or making modifications. I think we should look seriously at the heretics who are pursuing an alternative approach. DAN YORK: Doing relay from Jabber for John Klensin. He asks, "Since a few folks have now mentioned the 3-to-2 transition, could the IAB comment (or could we expect a report Wednesday) about how many more documents, proportionately, have been advanced out of Proposed Standard as a result of the transition?" RUSS HOUSLEY: You can expect a report on Wednesday from Jari. KATHLEEN MORIARTY: I just wanted to echo some of the other comments. I run into these debates with very senior people within the U.S. government, and we have to have these conversations about standards versus not-standards. It's difficult, because they look at an RFC and they say, "This is a request for comment." And then you can have that conversation there, but when they have to go someplace else, they have difficulty. I've had to do that several times. I've also had lots of other discussions and problems trying to assist. This is just one area that should have some consideration. I don't know exactly what the answer is, but I just wanted to raise that I'm also running into these debates with high-level people. ANDREW SULLIVAN: One question that I have for people who are running into this is, if we just change the name to Intergalactic Super-Truth Standard, would that make the difference? Is that all this is? KATHLEEN MORIARTY: Yes. ANDREW SULLIVAN: Okay! [Laughter.] DAVID BLACK: I wanted to say a few things about an alternative operating model that I'm familiar with that does maintenance well. In the IETF, one of the Working Groups I chair is STORM, and we just turned out a rather large maintenance standard. The publication announcement for revised version of iSCSI went out today, and it's over 300 pages. It's a maintenance document. Thank you to everyone who put up with what was necessary to get that sucker done. Somewhere in there is a confirmation of somebody else's comment that we're set up to do new work, and not maintenance. iSCSI comes from the old SCSI standard--a lot of you have disk drives sitting on your desk that use it. That world does not consist of hundreds of RFCs. There are about five crucial standards. They are fairly large. The standards body that standardized it has a practice of assigning new work to a large existing document, which means that you always have a context to do maintenance, and you always have a context to catch interactions with things that you didn't realize interacted in some way. It's a very, very different operating model because you have a much smaller set of things to work on, and some stuff is easier, and some stuff is harder. But there is an example of a world that is set up to do maintenance, and actually does a decent job of it. RUSS HOUSLEY: Thanks for that observation. Okay, with that, there is no one else at the mics, and we're out of time, so I hope you've enjoyed the plenary.