IETF 81 Technical Plenary Quebec City, Canada Monday, 25 July 2011 SESSION AGENDA 1. Welcome - Bernard Aboba 2. IRTF Chair's Report - Lars Eggert 3. IAB Chair's Report - Bernard Aboba 4. RSOC Report - Fred Baker 5. Technical Session I: "Report from World IPv6 Day" - moderated by Leslie Daigle 6. Technical Session II: "The Web Privacy Tussle" - moderated by Alissa Cooper 7. IAB Open Microphone Session MINUTES 1. Welcome - Bernard Aboba [See slides: "Agenda," http://www.ietf.org/proceedings/81/slides/plenaryt-0.ppt] BERNARD ABOBA: Hello. We'd like everybody to be seated. We have a very busy agenda tonight, and we'd like to get you off to dinner in a reasonable amount of time. So if you could seat yourselves, we'll get started right away. Okay. This is the obligatory note well statement: > Note Well > > Any submission to the IETF intended by the Contributor for > publication as all or part of an IETF Internet-Draft or RFC and any > statement made within the context of an IETF activity is considered > an "IETF Contribution". Such statements include oral statements in > IETF sessions, as well as written and electronic communications made > at any time or place, which are addressed to: > > * The IETF plenary session > * The IESG, or any member thereof on behalf of the IESG > * Any IETF mailing list, including the IETF list itself, any > working group or design team list, or any other list > functioning under IETF auspices > * Any IETF working group or portion thereof > * Any Birds of a Feather (BOF) session > * The IAB or any member thereof on behalf of the IAB > * The RFC Editor or the Internet-Drafts function > > All IETF Contributions are subject to the rules of RFC 5378 and RFC > 3979 (updated by RFC 4879). > > Statements made outside of an IETF session, mailing list or other > function, that are clearly not intended to be input to an IETF > activity, group or function, are not IETF Contributions in the > context of this notice. > > Please consult RFC 5378 and RFC 3979 for details. > > A participant in any IETF activity is deemed to accept all IETF > rules of process, as documented in Best Current Practices RFCs and > IESG Statements. > > A participant in any IETF activity acknowledges that written, audio > and video records of meetings may be made and may be available to > the public. BERNARD ABOBA: This is the agenda for tonight's session. As I mentioned, it's extraordinarily dense, so we have a lot of things to go through, and we're going to start on time. We're going to start with the IRTF, IAB Chair, and RSOC Chair reports. We'll then have a panel discussion of World IPv6 Day, and then a discussion of the web privacy tussle. So, first, welcome to Quebec City, to the IETF technical plenary, and I'd like to start off with the IRTF Chair's report, from Lars Eggert. 2. IRTF Chair's Report - Lars Eggert [See slides: "IRTF Report," http://www.ietf.org/proceedings/81/slides/plenaryt-2.pptx] LARS EGGERT: Hello, my name is Lars Eggert. I'm the Chair of the IRTF; I'm Aaron Falk's replacement since the last meeting in Prague. This will be short. We do have a few new things this week, which is the IRTF Open Meeting, which is Wednesday morning at 9 o'clock. So that's where we're going to be doing a lot of work from now on the status of the IRTF. So this [IRTF Report] is shorter than normal, and it might get shorter or even disappear, if you guys think it useful to just have that update in the Open Meeting rather than here. We have seven research groups meeting this week. This is quite a bit more than usual; I think in Prague we were four. As I mentioned, we have the new things, the IRTF Open Meeting that we're going to be using for a bunch of stuff. I'll get to that later. And we're reviewing the Crypto Forum Research Group (CFRG) [http://irtf.org/cfrg] with the IAB on Thursday morning. This is my take of where the research groups are. A few of them are actively chugging along--and active means different things to different research groups. The Transport Modeling Research Group (TMRG) [http://irtf.org/tmrg] is closing. That one got spun out of the Internet Congestion Control Research Group (ICCRG) [http://irtf.org/iccrg] while back, and have now decided it makes sense to merge back into ICCRG to finish the one thing they want to do. There's re-chartering discussion going on in quite a number of research groups at the moment: Anti-Spam Research Group (ASRG) [http://irtf.org/asrg], Host Identity Protocol Research Group (HIPRG) [http://irtf.org/hiprg] and IP Mobility Optimizations Research Group (MOBOPTS) [http://irtf.org/mobopts]. Some of them will re-charter and some of them will close; we don't know what happens to any of them [yet]. There's little activity in the Virtual Networks Research Group (VNRG) [http://irtf.org/vnrg] and the Peer-to-Peer Research Group (P2PRG) [http://irtf.org/p2prg]. This is our stream. We have the IRTF stream since a few years ago. We published eight documents since the last IETF, which is quite a number. The Delay-Tolerant Networking Research Group (DTNRG) [http://irtf.org/dtnrg] was a big chunk of that. You can see it's bursty, and the number on the Y axis are not very high, but this is sort of our normal rate. One thing I wanted to mention is, we, for the first time now, awarded a thing called the Applied Networking Research Prize; there's a URL [http://irtf.org/anrp] on the slide if you want to know more about it. This is basically for academic publications that have been published in conferences or journals. People can nominate them when they think that this piece of work is interesting and practical enough to lead to transition to shipping products and related standardization efforts in IETF. We had two dozen nominations for the first one of these. We had a selection committee of about ten, 12 people from the IETF and IRTF, and we selected two winners. We're awarding two of these prizes, the award winners [Mattia Rossi and Beichuan Zhang] are going to give their talks at the IRTF Open Meeting. Both of these papers are routing related. I know the Routing Area Directors are talking to them presently about if they want to do a repeat, and so it seems that the transitioning of the ideas is working pretty well and pretty quickly. So, if you want to know more about this, come to the Open Meeting. That's the agenda for the Open Meeting. Those are the titles of the talks, and then we're going to talk about some proposals for new IRTF groups--so this is basically some mini BOFs or side meetings where we're going to pitch an idea and discuss it in the community and see what people think. So it's the second half of the Open Meeting. That's my last slide. Thank you. 3. IAB Chair's Report - Bernard Aboba [See slides: "IAB Report," http://www.ietf.org/proceedings/81/slides/plenaryt-4.ppt] BERNARD ABOBA: I'm going to give the IAB report, which will also be short. We've got the full presentation up on the materials management site, but given everything else we're trying to present to you tonight, we'll only present the highlights. The IAB's responsibilities under RFC 2850 are architectural oversight, standards process oversight and appeals, the ISOC liaison, and external liaisons. As you may have noticed, the IAB has a new website. On the site we have a description of the IAB's programs and initiatives as well as recent announcements, IAB drafts and RFCs, and minutes of the IAB meetings. I'd like to thank Cindy Morgan for the tremendous improvement in the timeliness of the minutes. As a result of Cindy's efforts, the minutes are being posted regularly and are kept up to date. In addition, the new website (which is based on Wordpress) enables us to post regular updates on the IAB's activities. As a result, everything I'm going to say tonite is up on the site, and a lot more. So if you want more detail, you can go online and get it. The new IAB website has been many months in preparation. It is a wonderful gift from Olaf Kolkman and the NLnet Labs team, so thank you very much. We still have a few bugs to work out, so if you find any issues, send mail to iab@iab.org, or if there are improvements or other things you'd like, let us know. Here are a sampling of some of the recent postings to the site: the call for nominations for the ICANN NomCom, the RFC editor search, the retreat minutes, the Smart Objects and Privacy workshop reports, recent IAB drafts and RFCs. All of this is on the site and a lot more. So, a little bit about IAB document status. We've had two documents published as an RFC since the last IETF. One is RFC 6220, which defines the role and function of the IETF protocol parameter registry operators; and RFC 6250, which is evolution of the IP model. In terms of documents that have completed call for comment, we have one on extension recommendations, another that is currently in the call for comment period, which is the RFC editor model. You'll hear more about that in a minute. And then we have five drafts that are currently IAB work items, including two new documents which are the Privacy Workshop and the Smart Objects Workshop [reports]. Actually three, including identifier comparison. In terms of standards process oversight and appeals, there were no appeals since the last IETF. With respect to liaison functions, the IAB is responsible for appointment of an ISOC Board of Trustees member, and Bert Wijnen was selected. As I mentioned, I'll be cutting the Program report short because there's too many slides given everything we have to do today. But I would like to point out the IAB's Programs and Initiatives, some of which you'll be hearing about today. Programs are long-lived activities of the IAB. These include the Privacy Program, and tonight's privacy plenary was developed within that program. We also have the Internationalization Program, the RFC Editor Program, the IANA Evolution, Liaison Oversight and ITU-T Coordination programs. Initiatives are shorter-term activities of smaller scope; these include the HTTP Web Evolution, IP Evolution, DNS and IPv6 for IAB business initiatives. Each of these is described on the IAB website, and the report has a lot more detail. We'll let you read the report at your leisure and people can ask questions at the open mic. So I'd now like to bring up Fred Baker for the RSOC report. 4. RSOC Report - Fred Baker [See slides: "RSOC Report," http://www.ietf.org/proceedings/81/slides/plenaryt-1.pptx] FRED BAKER: So, just for those of you that don't know, we're in the process of hiring a new RFC Series Editor. The RSOC has been constituted to do that, and I chair it. So that's what we're up to. We are now on [draft-iab-rfc-editor-model-v2], which I believe is pretty well through its discussion, but we're still taking comments. Now, the RSOC started out during the Prauge meeting, and launched fairly quickly into a discussion of, "Okay, exactly how do I interpret the documents that we have, and how do we use those documents for the purpose of a search, and then ultimately hiring somebody?" And now, that would sound like, "I'll just read it and do what it says." Well, it's not quite that easy, as it turns out, and as much as anything, because faced with two candidates, how do I choose between one and another? How do I make that decision? So we had to look through some fairly basic issues and have some discussions. So these were the kinds of questions we were looking at. There have been some revisions to the model and supporting documents that are on the web. And as I said, there's still some comments being taken on the rfc-interest list [https://www.rfc-editor.org/mailman/listinfo/rfc-interest]. But we feel at this point we have most of what we need in place to do that. So, we put out a call for candidates two weeks ago. We've gotten seven statements of interest. We're probably going to interview most of those. There's one that I think we can discount, but we've gotten some very interesting ones. So we're quite happy about that, and we'll probably do some things to drum up candidates from other directions as well, and specifically from the library and publishing community--we figure it might be easier to start with somebody who knows something about publishing and teach them about the RFC series than to start with someone who has written an RFC and teach them how to be a publisher. So we're probably going to do some specific things to search in that direction. So our plan: we're in the process of interviewing, and we expect to do that for the next 30 to 60 days. With any luck, we'll be able to hire somebody in the fall. 5. Technical Session I: "Report from World IPv6 Day" - moderated by Leslie Daigle [See slides: "World IPv6 Day: Observations," http://www.ietf.org/proceedings/81/slides/plenaryt-9.pdf] LESLIE DAIGLE: Thank you. So, World IPv6 day. What was it? For 24 hours on the 8th of June this year, from midnight to midnight UTC, Facebook, Google, Yahoo and more than a thousand other web sites turned on IPv6 on their front door. The goals of doing this one-day activity were to motivate internet service providers and many others involved in actually getting IPv6 deployed to get together and prepare themselves for real deployment of IPv6. It was also important from the standpoint of understanding what issues still need to be addressed in order to insure smooth deployment. Yes, so, it's fair to note there have been similar events in the world turning on IPv6 on the front door for a day, but this was the first attempt to do it on a global scale. Motivations and impact, again, breaking the chicken and egg problem that we've all been familiar with for the IPv6 deployment. We also wanted to improve IPv6 connectivity by understanding any outstanding issues, and we knew that providing a target date that was not a flag day, but a date that was publicly understood that people could work towards, that we could get people to actually dig in and move their plans from hypothetical to real. And we certainly saw that, and it spurred a number of organizations to roll out IPv6 even on a test-like basis. Another important impact of it was that it catalyzed the kind of collaboration between corporations that have characterized the successful modes of internet evolution. So, it was a good day for the industry coming together, if you will. So, yes, there was a global response. Again, this was kicked off by Google, Facebook and Yahoo. There were also content delivery networks that came out to play, and there was interest from websites, ISPs, hosting companies and all manner of industry participants from around the world. More than a thousand organizations actually contacted us saying they were interested in participating in this. That meant there were many thousands of web sites, and I do mean like tens of thousands of websites that actually turned on IPv6 for at least 24 hours. So, who did? There are a number of them. I'm not going to read through these; I just wanted to give you a list of participant in IPv6 Day. They were not strictly North American; it certainly was worldwide. There were some important sites in Korea, in the Czech Republic, in Brazil. And hosting companies added IPv6 access to their sites, and if you'll note the third line, 700,000 web sites turned on with one website hosting service in Europe. And that one actually was enough to (that and the German one with 4 million) was actually enough to cause some blips and graphs. Broad observations: there was an IPv6 reachability dashboard [http://www.worldipv6day.org/participants-dashboard/index.html] that we put together, and I'm happy to say that roughly two-thirds of the participating sites who contacted us left IPv6 on. That wasn't a condition of participating, obviously; the test flight was for one day for a very good reason. The purpose of the activity was as a test flight and an experiment, and it's important to turn it off at the end of the experiment to sit back and reflect on what actually happened. But in terms of what actually happened: an increase in traffic, not exactly orders of magnitude, but still progress, and there's a URL [http://labs.ripe.net/Members/emileaben/measuring-world-ipv6- day-long-term-effects] here if you want to have a look and see just what sorts of traffic were measured out of the RIPE efforts. Importantly, no large scale breakage at all. There were some denial of service fears leading into the day, but that didn't happen either. Overall, it was a success. We moved the needle on IPv6 deployment. And overall, the reaction seems to be as Lorenzo likes to say, "come on in, the water is fine." But again, don't take it from me. Our next panelists are going to talk about their experiences with World IPv6 Day. And I've asked each of them to speak for five minutes just to give a bit of an overview of their experiences on the day, and then we'll open it up to discussion, and comments from the audience. DONN LEE (FACEBOOK): Good afternoon, and I want to thank the IETF for this opportunity to speak to you about World IPv6 Day at Facebook. I'm Donn Lee; I'm a network engineer at Facebook, and we're going to proceed into the content. [Please see pages 23-33 at http://www.ietf.org/proceedings/81/slides/plenaryt-9.pdf for Donn Lee's presentation.] IGOR GASHINSKY (YAHOO): Hi, I'm with Yahoo, and I'm going to talk about our experience in World IPv6 Day. [Please see pages 34-47 at http://www.ietf.org/proceedings/81/slides/plenaryt-9.pdf for Igor Gashinsky's presentation.] LORENZO COLITTI (GOOGLE): So, I won't say much; my name is Lorenzo and I work for Google, and I'm one of the two people on the IPv6 effort, and I've been with it with them from the beginning. [Please see pages 12-22 at http://www.ietf.org/proceedings/81/slides/plenaryt-9.pdf for Lorenzo Colitti's presentation.] CARLOS RALLI (TELEFONICA): Okay, my name is Carlos. I'm from Telefonica, and I'm going to provide an ISP insight on the day. [Please see pages 48-53 at http://www.ietf.org/proceedings/81/slides/plenaryt-9.pdf for Carlos Ralli's presentation.] MARK TOWNSLEY (CISCO): Hello everybody, my name is Mark Townsley. I work at Cisco. While we've heard from content providers and a service provider, Leslie and Phil asked me to speak about World IPv6 Day from the perspective of enterprise. [Please see pages 54-61 at http://www.ietf.org/proceedings/81/slides/plenaryt-9.pdf for Mark Townsley's presentation.] LESLIE DAIGLE: So, I'd like to thank all the panelists, and I will say that some of the panelists had longer slide decks and more information to share with you, but because we were trying to stay compressed in this panel, the shorter version is what you just saw. So if you thought things were interesting, go dig around at the proceedings page and there's perhaps more data. --Below please find the transcript of portions of the Q&A session relating to "Report from World IPv6 Day"-- BILL ATWOOD: I'm Bill Atwood. I had a question about the brokenness of IPv6 hosts. How can you measure the brokenness of a host whose path into the network denies the existence of quad records? In other words, that host has no IPv6 connectivity, you can't even find out if it has any. IGOR GASHINSKY: Yes, we use the term to mean something different. To us, it's brokenness in the face of IPv6, as in, I had a perfectly working user who was using IPv4, and when I started dual-stacking my site, all of the sudden, that user can no longer get to me. That could be because he's using 6-to-4, and 20 percent of all 6-to-4 packets get dropped into the ether. Before I published AAAA, he was perfectly happy. The second I published it, he disappeared. And we measure it via beacons that run on our site that actually instruct the portion of users to go ahead, a set of measurement points and report on their success rates. MARK TOWNSLEY: So, I think by definition, that user that's shielded from AAAA would not be considered broken? BILL ATWOOD: If the user never got to AAAA. MARK TOWNSLEY: It's as simple as that. IGOR GASHINSKY: We should settle on a name on it. One name that has been tossed around is dual-stack brokenness (versus v6 brokenness). BILL ATWOOD: I've got a perfectly working v6 machine. I consider my IPv6 access broken. But it's my ISP who is at fault, not me. IGOR GASHINSKY: I would say that's not enabled, compared to broken. BILL ATWOOD: It's enabled on the host. LORENZO COLITTI: Let me put it this way. The definition is, if the host thinks it has global connectivity such that it will time out when you present it with an IPv6 address, then we call it broken. * TINA TSOU: I and my team built www.huawei.com for World IPv6 Day and ipv6.huawei.com for the long term, and everything was fine; we used the dual-stack, but I noticed some companies use the reverse proxy and the other special ones for Yahoo. I'd like to know, is there any survey or summary for how many percent of these web sites you still stack, how many percent use reverse proxies and the other mechanisms and so on? My second comment is that we found out for the HTTPS, there's support in the market, not so many DNS servers support that. So that means for the World IPv6 Day, most websites can do HTTP, but for HTTPS you have to use a password to access [and some high-level secure websites could not be accessed]. IGOR GASHINSKY: So just to answer the comment on the reverse proxies, the reason why we used the reverse proxies--actually IPv4 and IPv6 at Yahoo has been moved to the reverse proxies--it was simply that we couldn't, because of the issues that we found with the [neighbor discovery protocol] NDP--and there's going to be talk about that; they're going to be presented in [V6OPS working Group] tomorrow--it was where those proxies were located, we were safe. So v6 went first onto those proxies. It was just a convenience thing. Today you're probably browsing v4 through those proxies as well. So it's not that it's something special off to the side. Those are servers. Those are web servers. LORENZO COLITTI: As regards to HTTPS, that's a good point. I mean, if we ever do another event, then we should ask ISOC to monitor which websites are reachable over HTTPS over IPv6. MARK TOWNSLEY: I should mention in our case we did terminate HTTPS over IPv6 at our website because we used our own proxy, and it does support HTTPS at the proxy location. We had to put the cert there, but it works fine. I believe the open source doesn't do that. That's one of the reasons-- [Several people talking.] IGOR GASHINSKY: It does now. MARK TOWNSLEY: The one we evaluated earlier didn't. IGOR GASHINSKY: It was a corporate priority thing. We could have burned man-hours doing that, or enabling something else. And we get far more HTTP traffic than we do HTTPS. TINA TSOU: So in summary, there are more participating websites using reverse proxy, and just like our case, using the native dual-stack is the rare case? LESLIE DAIGLE: I'm not sure if anybody did actual measurements specifically on that front, but there were a number of measurements done by a number of different entities. I suggest you have a look at the proceedings from the IEPG meeting yesterday [http://iepg.org/2011-07-ietf81/index.html], and have a look at the RIPE website for a number of different measurements that people did in terms of who was doing what exactly to provide IPv6 on the day. IGOR GASHINSKY: Actually, I have a question back to you, what does it matter? The reverse proxy is just a web server. TINA TSOU: It doesn't matter, just curious to know if there is a survey or summary. It seems more natural for dual-stack. MARK TOWNSLEY: I think it would be something impossible to accurately measure. If the proxy is actually doing its job properly, you can't tell. You have to look at some particular heuristic or the content provider would have to tell you, yes, this is what we did. * BOB HINDEN: Hi, I'm Bob Hinden from Checkpoint. So we had a slightly different experience with World IPv6 Day than was talked about by most of the panelists. We're not a large content provider like Google or Facebook, or sell enterprise products. So the issues that less than one percent of brokenness for certain types of tunnels, we don't--at least our IT department--didn't really care about that. That's just noise. And so I think there's a whole lot of enterprises, companies who have websites that can go to IPv6, and don't have to worry about these kind of issues because their business model is not about getting people to the website. It's about other things. And so, I think that's the concerns which--I'm a big fan of World IPv6 Day and look forward to the World No IPv4 Day someday--but I think, we tend to focus on the large organizations here a lot. And there's a lot of smaller ones for whom the world is not as complicated. LORENZO COLITTI: Yes. Absolutely. If it's not worth your time to track down 0.03%, then don't track it down. DONN LEE: Well, I mean, I know that a lot, I think 70% of the websites left it on. And it's possible that they're the smaller websites, and they're like, well, it's not showing up on our graph, so we're happy with it. MARK TOWNSLEY: In our case, maybe we're more similar; Cisco is maybe a little bit bigger. The brokenness was a big issue. We had to do risk analysis and present it to management. But another thing was, enabling the proxy locations, at every different point around the world. So the page view performance of IPv6 afterwards required an investment that is going to take a little bit longer than what we had available in June. It worked just fine for the day, but in terms of putting it into full production, it needs a different kind of focus in order to implement. And so, having a day, anyway, the date was fantastic for us. And the idea that yes, that we're going to turn it off afterwards, it's just 24 hours, really helped move the ball forward. BOB HINDEN: Right, let me just say one other thing, not really in response; I think it's complementary. For us, and I think it's true of many people why they participated. It sent a message to our customers that we're serious about this. And, I think that's true for a lot of people who participated. So just doing it, we left it up. But, you know, I think that was important for a lot of folks who tried to sell stuff. LESLIE DAIGLE: To follow that point up, I think we saw in the requests and interest expressed in participating in the day, there was a lot of interest in terms of just participating and being visible to be supportive of IPv6 and, in fact, had to be a little bit stringent in requirements for what it meant to actually "participate" on the day. As I said earlier, 70% of the participants left it on after the day. Again, referring to the IEPG talks yesterday, somebody looked at the most popular web sites in the world, and none of them did. So I think, Bob, your point is spot on. There are a lot of entities out there that have websites that are not as worried about that particular metric, and it would help overall deployment of IPv6 to get more people to deploy it, while we recognize that there are real issues for those entities that do depend on their websites. IGOR GASHINSKY: Leslie, to get back to that point, again for some people, 0.022% could represent one user for their site. And my parents have a web site for their office, for their business, and they get less than 5,000 users. LESLIE DAIGLE: Okay. IGOR GASHINSKY: If only one person can't reach them it's not really that big of a deal for them. If it's 220,000 users, it's a different story. LESLIE DAIGLE: It is a big difference, but understand also these were not random small websites. They were websites that were savvy enough to want to participate in the day. So there's something interesting there. MARK TOWNSLEY: The 4 million that were enabled by Strata, those customers were not asked. DONN LEE: Fair enough, so if you're going start the next Google, Facebook or Yahoo, start with v6 and grow into it. * WES HARDAKER: During IPv6 day, I wrote a quick script to do some tests. I wanted to see, okay, there's 438 domains listed on your web page saying "We're going to do IPv6 Day." So I wrote some quick tests to go out and poll them myself. And I only looked for their DNS entries; I didn't actually try and connect. The interesting result is that 38 of them didn't even have a AAAA record, so 38 of them failed completely out of the door. But the thing that got me was that when I went to go look and see, can I actually get to those sites on a fully IPv6-compliant (and only IPv6-compliant) machine using an IPv6-only compliant ISP, the answer was almost overwhelmingly no. Because the only record that was actually added was a AAAA for the website. There was no AAAA for the DNS entries, there was no AAAA for an MX (Mail eXchange) record. Could you get to their e-mail system through IPv6 too. So it's an absolutely fantastic step forward and I applaud you for doing that. And I hope next year we get more than 41 sites out of 438 that actually do more than just port 80. Because there's a whole lot of other technologies. If we're going to make this thing work, we have to test a lot more than just port 80. LESLIE DAIGLE: So that's a fair point, and certainly taken on board. But again, back in January, the most significant thing about the day, was to see how dual-stacking would work. And for that purpose, it was what it was. Looking at it from this side, and knowing that nothing blew up on the 8th, it's a good list list of thing we can target. WES HARDAKER: It's a fantastic step forward, but I look forward to next June 8th when we can do other stuff. I actually tested whether they did DNSSEC too. And I think that was a good thumbs up for a completely untested thing that I threw at them. MARK TOWNSLEY: Just to provide a little more information, it wasn't in my lessons learned, but it was an in an earlier [slide] deck that didn't get squished down to five minutes. Lorenzo can probably talk about all the wonderful services they have and more than just google.com. One of the big problems we were looking at in terms of turning on the AAAAs for a long period of time was geo-location information. And that's a contractual requirement for the images that are downloaded for the routers with encryption capabilities within them, and legal requirement with the government, to have the best effort for geo-location data. We know this can all be hacked and stuff. But this is there and we need to be able to do it. And because we're not a big content provider that has our own databases with mapping up v6 with v4v4 and creating our own geo-location information, we have to rely on providers for that. And it's just not there. So luckily all the download of those crypto-images are done off a URL other than cisco.com, and we got really lucky because we didn't have to change anything. We were like, "Okay, fine, that gets an A record, not a quad A. Thank goodness." But that was in our show stopper list. If that had not been the case, and we had not been able to come up with a work-around, we might not have been able to participate. That first step versus all the other intricate things, when you've got cisco.com that's been around more than 25 years, and I think there are a lot of big enterprises like that. It's tough. Dual-stack is a good first step. LORENZO COLITTI: Also, another alternative milestone that we might want to shoot for next year is let's get some users as well. I mean, 0.3%. IGOR GASHINSKY: So we were running a test before, for what happens if you v6 glue enable all of your NS records. What we saw, instead of the breakage rate at 0.022%, the breakage rate went to 0.5%. If I enabled v6 glue on all of Yahoo's NS servers, half a percent of users would no longer be able to get to me. That's a problem. And, we haven't followed up with a test of what happens if you only enable it for one, because technically, you only need one v6-only sites to be able to get to us. But the reality is, for right now, there are not v6-only networks out there that are not using other translation methodologies, and this was a dual-stack event. We'll see what we can do for the next one, but the priority is going to be to get us some users before we start working on the really hard problem that may break a lot of people. If you want to take some numbers into perspective, in order to get v6 to 0.229% of the people, 0.024. In other words, O.024% of the users were broken, so for every ten users that I gave v6 to, a v4 user could no longer get to me. That is a really bad statistic. So we need to improve that before we can go further. LORENZO COLITTI: Right. And also, we're working on IPv6 DNS, and you saw that Google public DNS now supports IPv6. And glue is really scary for all the reasons that Igor mentioned. But really, what are we trying to do here? We're trying to make sure that users come online two years from now, without v4 addresses, and actually connect reliably. Personally, I think there will be v4 space for DNS servers and SMTP servers for quite a while. So, yes, in the fullness of time, we'll have v6 DNS glue. And in the fullness of time we'll have universal v6 adoption. But at the moment, we have to focus on short term. * UNKNOWN SPEAKER: It's a very quick question, I was wondering about the relatively high level of adoption of IPv6 in France. Can you give any insight into that number, if it's just a signal feed and if there's some motivation why they're adopting it? MARK TOWNSLEY: I'll try to be brief. This is my personal ISP in France, and I had a little bit to do with what they did there. Back in late 2007 they implemented a technology called 6RD. They've been running it for a while. They create and ship their own residential gateways, which really helps, because that's been one of the big barriers, the residential gateway equipment, as well as the access network equipment. What 6RD does, if you read about it, it skips over the access equipment, but also the residential gateway was was a big part of it. They were able to quickly put out their own source code on those residential gateways with the IPv6 changes necessary, and they did it quick because they're a fast-moving company. They are free.fr. So at the moment, well, up until last February, they were opt-in. And a little over 10% of the users clicked, "Yes, I want IPv6." But since last February, all new users are enabled by default. So you'll see an uptick. Simple as that. * JARI ARKKO: I wanted to come here and say that your success rates or deployment status, or even things like failure rates are very dependent on your viewpoint. What are you actually looking at? And you guys are mostly looking at it from content provider perspective: how much traffic do you see, how many users do you see. Other people have been looking at it from user perspective, and did some research on looking at how many popular websites can we get to with v6, and how many AAAAs we see and so forth. The numbers are actually very different, so if you talk about 0.2% or 0.1 or whatever. We actually saw within the 10,000 most popular websites, 5%, and [within the] hundred most popular, 40%. So those numbers are actually very different, and far more positive. There was a big change too; perhaps a historic change in terms of internet infrastructure. But, I could even say the content is now there in some sense. So thank you for that. And, I'd like to agree with Lorenzo, who suggested something about the users earlier. So if you're looking for a next project, maybe that could be the World IPv6 Access Network Day. Get the users there. [Applause.] LORENZO COLITTI: I don't work for an access network. * TINA TSOU: Some panelists said it will take a long time for big company websites to move to IPv6. I feel like it depends on the architecture of your website. If you use www.company.com/everything, it may be if you just change the DNS server and web server, everything is changed. And if you use like, support.company.com, education.company.com, money.company.com. Yet you can change this top web server, DNS server one by one, there will be more incremental and doable. Are you with me, or is it common understanding from the panelists? IGOR GASHINSKY: Yes, I mean, my company does both. When you have 3500 separate entry points, doing them one by one takes a really long time. DONN LEE: That was the experience that I have. I'm a network engineer, so I had to go to the software engineers about how the website is constructed, and of course, it was not constructed with v6 in mind or dual-stacking in mind. So that's why we were in that web connect situation, or Facebook Connect situation. I didn't want Facebook Connect to participate in IPv6 Day, but that's how the code is written, so it goes. LORENZO COLITTI: Also in many cases, you have layers between the web servers that accept your traffic and the actual applications that serve it. For us, it doesn't matter; it gets served by the same thing. So in that case, you don't really care. * MATTHEW KAUFMAN: Matthew Kaufman. This is for the IPv6 panelists: Could I get a show of hands of who, when they were at home on IPv6 day, could actually access the IPv6 internet? MARK TOWNSLEY: We weren't at home on IPv6 Day. [Laughter.] MATTHEW KAUFMAN: Or the next day? IGOR GASHINSKY: I was at home. I can access IPv6 every day. MATTHEW KAUFMAN: Could I see the show of hands. MATTHEW KAUFMAN: Now, put your hands down if that's through a tunnel. Okay. So for everybody with your hands down what have you done with your provider to get that rectified. [Several people talking.] MATTHEW KAUFMAN: But I was asking for the people with the hands down. Did you call your ISP. MARK TOWNSLEY: I think you made your point about residential access and how a lot of it is through managed tunnels. I mean, a lot of it is. I was at work, but we have, of course, native v6 at work. IGOR GASHINSKY: The reality is, at least in the U.S, you don't have many choices. You've got A or B. And if neither offers v6, you have a problem. If you have a choice of somebody who does, you might have more options. DONN LEE: And also, with our blog post people use their real name because it's their Facebook, so they tend to have comments that seem to be better than if they use an alias. But a lot of people were expressing their desire for ISP participation. I wanted to participate, but my ISP does not offer it. So there was some of that we saw. LORENZO COLITTI: One thing that World IPv6 Day did do for us is that it removed one of the long-standing reasons that IPv6 is not getting deployed, and the reason is, there is no content. But, so with World IPv6 Day, I think we showed that there is content. So, I think that's one thing that as an industry that we have achieved. We know that when the time comes, when v6 is rolled out to the users, the content will be there. CARLOS RALLI: I think from the ISP point of view that World IPv6 Day was an absolutely necessary step. As long as we need the content, but of course it was not in the right timeline for us to solve all the problems to scale all the things up to deliver the service today to our customers. However, in the future, in the forthcoming months, I'm sure many ISPs are starting to enable large trials for end-users, and it would be nice to have a similar experience once we can do it. So I think we are really taking care of this, but the first step was just the dual-stack just to put the content out and prove the technology and see what v6 users will need. BERNARD ABOBA: There's obviously an enormous amount of interest in this topic. And I believe there will be additional discussion in the V6OPS [working group] so you can continue this. 6. Technical Session II: "The Web Privacy Tussle" - moderated by Alissa Cooper [See slides: "Web Privacy Tussle: Alissa Cooper," http://www.ietf.org/proceedings/81/slides/plenaryt-14.ppt] ALISSA COOPER: Switching gears a little bit. Bernard briefly mentioned earlier that we've initiated the Privacy Program within the IAB, and part of the goal of that Program is to raise awareness about privacy in the IETF, and to develop better ways to document and address the privacy threats raised by protocols that we develop here. And to that end, we have three invited experts here with us today to help us sort out some of the privacy issues that we're all confronting. We have Jens Grossklags, who is from Pennsylvania State University, and he focuses on privacy, security and network interactions from a theoretical and practical perspective. We have Fred Carter, who is a senior policy and technology advisor from the Privacy Commissioners here in Canada, and he's going to give us the regulator's perspective. And we have Andy Zeigler, who is a program manager for Internet Explorer at Microsoft, and he's been responsible for a number of privacy features in IE, and he'll be giving us the browser-makers' perspective. So we'll start with Jens. JENS GROSSKLAGS (PENNSYLVANIA STATE UNIVERSITY COLLEGE OF INFORMATION SCIENCES AND TECHNOLOGY): All right. So, the title of my talk is "Users and Privacy," and what I want to do is present to you three different user interaction studies that involve in total over 3,200 users, and their interaction behavior and a variety of context and a bit of security towards the end. [Please see slides: "Web Privacy Tussle: Jens Grossklags," http://www.ietf.org/proceedings/81/slides/plenaryt-5.pdf for Jens Grossklags' presentation.] FRED CARTER (OFFICE OF THE INFORMATION AND PRIVACY COMMISSIONER, ONTARIO, CANADA): Hi. I'm Fred Carter, and I'm the senior policy and technology advisor with the Office of Information and Privacy Commission of Ontario. I used to be with the Federal Privacy office before joining the Provincial office. I'm here on behalf of the Information and Privacy Commissioner in Ontario, who could not be here today. [Please see slides: "Web Privacy Tussle: Fred Carter," http://www.ietf.org/proceedings/81/slides/plenaryt-7.ppt for Fred Carter's presentation.] ANDY ZEIGLER (MICROSOFT): Hello, everybody, I'm Andy Zeigler, I'm the program manager at Microsoft on the Internet Explorer team. I'm very excited to be speaking here today and I also recognize the fact that I'm the last speaker of the day, and I am the one in the way of your Monday evening activities, so I'll try to be brief. [Please see slides: "Web Privacy Tussle: Andy Zeigler," http://www.ietf.org/proceedings/81/slides/plenaryt-6.pptx for Andy Zeigler's presentation.] ALISSA COOPER: So, Andy thought he was last, but lucky for all of you, you get to listen to me talk for a few more minutes and give you some thoughts from the IAB Privacy Program and relate what you've already heard back to some of the work we've been doing lately in the Program. So, I want to breakdown the concept of privacy a little bit. Jens talked about how it's multi-faceted, and I think from a protocol perspective there are a number of different ways that IETF protocols can implicate privacy. Many protocols--probably most--allow or require information about end points to be shared. So, IP is a good example. Pretty much, if you have some kind of communications protocol, you need to identify the end points somehow, and end points and those identifiers can be correlated to the people who are using them. Another way that protocols implicate privacy is by allowing people to share information about themselves. So, you can share your presence information using XMPP. There's lots of other examples where protocols that we design allow information about people--not just their identifier or something about their end point--but about the person, him or herself, to be shared. And then the last way is that some protocols allow for direct communications between two people. So something like SIP, where you have two people who are actually communicating with each other, using that protocol. And so depending on the protocol, it might be facilitating different kinds of information, related to, or about or between people, and that tends to be the place where privacy comes in; where you have people and you have information about them, then you might need to think about privacy in those instances. But I think we tend to build protocols that are generic--that don't foresee with a lot of specificity particular implementation details or characteristics about deployments and use. We like that. And what that means, is that endpoints are not always proxies for people. Those endpoint identifiers are not always correlate-able to some person. A communication is not always between two people or multiple people. It can be between other kinds of entities. Even if it is, protecting it is not always a desirable feature. Some communications are meant to be public, so they don't necessarily need any kind of protection from wider exposure. And information that gets shared is not always about people necessarily. It can be about any other kind of endpoint. And protecting it is not necessarily always desirable. You heard from Jens that people give away their DNA for a lollipop. So in some situations the protection of information about people is not necessarily a mandatory feature or desired feature. So at the design phase there can be a really tremendous amount of uncertainty about what's going to happen, and what the effect will eventually be on privacy, because there's such a diversity of uses. So, what do we do in the face of uncertainty? I think there are some useful learnings that we can take from the experience in the security context, and what's on the slide is from BCP 72, talking about threat modeling which is one of, I think, the key tools that we use to deal with security issues. And it says that a threat model describes the capabilities that an attacker is assumed to be able to deploy against a resource. So the question is, can we draw from that? Can we try to do privacy threat modeling, can we be more systemic about it? So, to further that end, in the IAB Privacy Program, we've recently taken a look back at some early efforts to address privacy in protocol development, and we have a few privacy reviews on our website that you can check out [http://www.iab.org/activities/programs/privacy-program/privacy- reviews/]. Bernard did one for EAP and I did one, with the help of many knowledgeable people, about IPv6 privacy addressing. There's a couple of lessons that have come out of that process. I think, if you look back ten or 15 years ago, at some of these efforts to address privacy, they're kind of circumstantial. They sort of depend on what may have been happening at the time, something that made it into the news. They can yield counter-intuitive results, so there may be a ton of focus on trying to anonymize string identifiers, but not realizing that there's lower layer identifiers that are implicated and left out in the open so you end up with gaps in terms of what people thought was important enough to address at the protocol level. And I think there's other lessons to be learned as well. Jens and Andy both talked about effects not being reversible, and we certainly saw that in some of these reviews, how if the initial design had kind of serious privacy flaw and got deployed or deployed widely, it's really hard to eventually reverse that trend even if further standardization work has come into place in the time since. I should also say that there's been more recent work and those efforts have evolved, so where we may have been really piecemeal and haphazard at the beginning, if you look more towards [RFC] 3323 and [RFC] 3325, some of the work with SIP privacy, you at least see the beginnings of trying to say, "We have some sort of threat model, and here are the threats we're going to address, and the ones we're not going to address." So one big question we're grappling with right now is how do we become more systematic about building threat models for privacy. Because thus far, I actually think there's a lot of attention paid to privacy in various and sundry ways as protocol development takes place, but we've not been systematic in our thinking about what the threat models are. That begs the question of how to decide which threats are in scope and which threats are not in scope. Certainly if you think about building a mechanism to defend against every threat that there is against something like HTTP, that's not something that is reasonable to do; it's far too generic and there are far too many threats. And so, the question is, how do we divide them up into what can be addressed and what cannot be addressed, and we do this in security again. Going back to BCP 72, there's two purposes of the threat model: one is to identify the threats that you're concerned with, and the other one is to rule some of them out of scope. I think the plenary today has shown you some of the challenges in dealing with this scoping problem. You heard about this diversity of user privacy preferences and interests, and mental models for dealing with different kinds of risks, and that makes it hard to decide what should be addressed and what shouldn't because there's a lot of heterogeneity. We heard about existing incentive structures that might not support privacy features that are desired by certain users. I think P3P is one example of that, where there were some great ideas on the table, and various and sundry different kinds of incentives came into play such that deployment has not been what people wanted it to be, and now there's thinking ongoing about how to do something different or better in relation to some of the technologies that Andy talked about. Then we have norms and laws that might drive emphasis in a certain direction or another, and that can vary across jurisdictions. So I think those constraints (and there are many others, I think) make this scoping question really difficult. And so, there's really two questions that come out of that. One is how to determine the boundaries of which threats should be addressed, or may be addressed in protocol design. And then, how do we document the threats that are not being addressed? Which is, I think, a significant challenge as well, just because there could be an infinite number and you're not sure when to stop necessarily. So what we'd really like is more input on these questions, on this draft [draft-morris-privacy-considerations-03] that is out there that's trying to capture some of our thinking about if we're going to provide some privacy guidance for protocol development, what should it look like, how should we break down the concepts and make them actionable for people as they're doing their work in the IETF? And so, you can join the discussion on the mailing list [ietf-privacy@ietf.org], and send us your comments on the questions, the draft, or any other thoughts you might have. --Below please find the transcript of portions of the Q&A session relating to "The Web Privacy Tussle"-- PHILLIP HALLAM-BAKER: Just, in defense of Lee, who I watched writing CSS back in 1994 when I was at CERN: JavaScript did not appear for another year and a half, and it was a stupid idea then, and it was thrown together in two weeks, and it's not surprising that it was a privacy disaster. The visibility tag wasn't the worst of the problems with version one. In version one of JavaScript, you could actually just pull the history direct from the browser. ANDY ZEIGLER: Opportunities for innovation. Thank you. * JOHN LEVINE: I'm John Levine; I have two somewhat unrelated questions for the privacy panel. The first is about notice and consent. Pretty much every privacy model has some aspect of notice and consent. Like with P3P [Platform for Privacy Preferences (P3P) Project; http://www.w3.org/P3P/], the site says, "Here's what we're going to do," and you say okay or not. And the new Castle Law in Canada has a lengthy section about what you have to do before you're allowed to download and install software. It means that you have to have meaningful notice and consent. And my question is, where does notice and consent stop? I think if there were an institutional review board, reviewing the experiment where they paid people a penny to run malware for an hour, they should have said no. It's like in the real world, no amount of notice and consent is sufficient to allow you to sell your kidney. Is there a baseline beyond which you can't ask people to consent to stuff that is just too bad? And the unrelated question--and you can answer them in either order-- does anybody who understands the technology actually think that Do Not Track will work? JENS GROSSKLAGS: So, I guess the current state of affairs with notice and consent is untenable. We cannot assume the statements are contractual obligations if nobody is really consenting to these practices. And equally, we cannot assume that as users, we should all read them because they are enforceable, because it just puts too much of a burden on us. So what do we do from here? I was with a colleague from Germany, we've just written a lengthy research paper reviewing this whole space, with like 120 references, where we are really trying to categorize the situations: when this notice is actually helpful, and when it should be avoided in the first place because it doesn't contribute to better security or privacy. So one approach would be yes, let's cut down on the clutter and only notify people when it's necessary. Which is, of course, a difficult problem in the first place, but would go in the right direction. The other question that you asked, essentially is, so it wasn't entirely clear to me--when you mean vendors notice, useful, whether it's upper bar or lower bar? JOHN LEVINE: I'm saying, are there things that you should not be allowed to ask for; that even if people consent, you can't do. JENS GROSSKLAGS: From a privacy perspective, it would be better if it had a privacy baseline law. Across the board, certain things just cannot be done with user information or anything related to the consent of privacy, because the main problem we have nowadays is we have a million different contexts and solutions, and associated with them always a completely different notice and consent experience. We kind of expect that users are understanding all these different technology solutions like the Do Not Track header, the Platform for Privacy Preferences (P3P) and many other solutions, and come up with the concise framework to protect their individual privacy. So, while these solutions are individually intriguing and might solve a particular privacy problem, we still have to overcome these privacy hurdles in a much more general form to actually make a dent into this problem. ANDY ZEIGLER: What I would add to that--first of all, I think they're really good questions. The first part is consent. We have a notion of explicit and implied consent. So there's certain things that require explicit consent, like do you want this website to be able to get your physical location: that's explicit. Then there's implied consent, basically it evolves over time. If you look at the history of Internet Explorer, there were more consent dialogues, like when you change from HTTP to HTTPS, or you change zones. So, as users understand and expand their vocabulary about how the internet works, maybe your requirements for what level of consent [is needed] changes over time as well. So, [the address bar in Internet Explorer 8] is another example. It didn't have a service hooked up to it so you could get suggestions. And when we added that in IE9, we made it off by default and required an explicit action to enable that capability. But maybe over time, that's something that people just get used to. But, I think it's something that evolves. The second question was about Do Not Track-- JOHN LEVINE: If I can back up to your last answer there, the thing about the address bar being something that people get used to? There's no question that it's cool and useful. On the other hand, it also means that you're sending real time key strokes back to some organization of unknown niceness. ANDY ZEIGLER: Today it requires explicit consent. But maybe in the future, like in 20 years, it will have been around for so long, that everybody knows that that's what the address bar in the browser does. JOHN LEVINE: As the author of "The Internet for Dummies," I can assure you that the user doesn't have a clue about that. And never will. ANDY ZEIGLER: The other part about Do Not Track, can it or will it work, I think anything can work. I-- JOHN LEVINE: Let me make it clear. Technically, it's clear that your browser can send the thing in and the server can interpret it. But the question is, how can you tell if the servers are paying attention? With Do Not Call, you get junk phone calls. With Do Not Track, you get eerily targeted ads. ANDY ZEIGLER: That's one of three tough problems, I think. One other one is that the first thing people have to do is agree on what tracking is. So there has to be, if you send DNT: 1, what is a web site supposed to do? Is it don't target ads, don't collect data? That needs to be agreed upon. Then there's the issue of deploying the technology on websites and getting websites to actually do what they're supposed to do, whatever that is. And I think it's easier if you have legislation that requires that. I think that's easier than voluntary or, you know, maybe there's a Do Not Track Day in the future. But, yes, I think it can work and technically we can expand the specs so that there's an ACK from the server or something like that. But there's definitely a lot of milestones to get through before it's something that you can say to a user, "Hey, if you turn this on, it's going to give you control over your data." * DAVE CROCKER: I enjoyed both of the panels quite a lot. And I had two quick questions on the privacy panel. Concerning the Do Not Track statement that anything can be made to work: I don't think you were at last week's usable security conference at Carnegie Mellon, and it's a shame, because you would formulate a different opinion about how likely it is to be useful. In general, what I got from some of your comments was that all we need to do is give users enough information, and that's completely contrary to the human factors conclusions that have been around for a long time. But that wasn't why I got up. The other talk which I really enjoyed, and in 20 plus years, I don't think I would have expected to hear a talk about behavioral research in the IETF. And that was a real pleasure, especially, it was a really nice talk. But, my memory is a bit vague about some of the training in my methodology class, and so I couldn't quite remember, when you referred to external validity, is that the same as interoperability? JENS GROSSKLAGS: Let me start by saying that external validity is very important in the context of privacy, and in some sense, interoperability, fits in there, right? Because, our world view in the experiment needs to match also the reality as we see it outside. And of course, experiments that I've shown, while maybe excluding the one which was a field experiment, is done per definition in the laboratory context. So, as hard as we can try, there's always some kind of confounding effect that we have to take into consideration. What we also tried to do is have multiple experimental conditions and then contrast and compare from one experimental condition to the next one. And then look essentially at the differences that we observed, caring a little bit less about the overall level of information disclosure across all of these different treatments. Of course we're interested in that, but the stronger results are always contrasting and comparing those so-called subject treatments. What else did I want to say about that? We did another experiment with colleagues at Carnegie Mellon University where we asked people to come into a room and give us a certain amount of information about them, for example, by completing a quiz and computing from that a score about knowledge about a particular subject. At a later stage we asked them in two different treatments to either protect the information for an amount of money, or to sell the information to us for another amount of money. Basically giving them a take-it-or-leave -it offer of doing either protection or sales action. Otherwise the treatments were completely similar to each other, except for the difference in this particular action. So what was the surprising consequence, if they didn't protect it, if they sold the information, they had to get up and announce the information to everybody else the room--whether it was a quiz score, their weight, age, height--we tried to defend a number of different things. So coming back to the problem of external validity, of course this situation is something that does not necessarily occur in practice; however, what we are trying to create with this kind of experiment is a privacy consequence in the laboratory. Right? Something that you care about. Maybe if you have some difficult self-representation for whatever reason, then you don't prefer to get up in front of a number of people and tell them about some personal characteristic of themselves. And this has worked very well in the experimental context even though it's not replicate-able in practice. So you mentioned the security symposium for usable application, et cetera, and there is a lot of work that's going on there, but as a reader of these papers, it's always very, very important to really think about [whether] what we are seeing as a result is only something that's relevant in experimental context or in practice. DAVE CROCKER: I got back up because you started describing a second manipulation experiment and all I can say is I'm really glad you're working on this side of the problem. [Laughter.] 7. IAB Open Microphone Session BERNARD ABOBA: I'd now like to ask the IAB to come up on stage, and we'll have about a five minute Q and A, and then let you all go off to dinner. [IAB Members (many of whom are wearing hats with the IAB logo) introduce themselves: - Bernard Aboba, IAB Chair - Ross Callon - Alissa Cooper - Joel Halpern - Spencer Dawkins - Russ Housley, IETF Chair - David Kessens - Olaf Kolkman - Danny McPherson - Jon Peterson - Andrei Robachevsky - Dave Thaler - Hannes Tschofenig - Lars Eggert, IRTF Chair - Mat Ford, Liaison from ISOC] SHOUT FROM BACK: What's with the hats? BERNARD ABOBA: At IETF 80, there was a question about when IAB members had their IAB hat on and when they didn't. And much of the time we don't wear our IAB hats, but at least at this particular occasion, we are, because we're sitting here as the IAB. But if people give you their personal opinion in answering your question, they should probably take the hat off. [The microphone queues are empty.] BERNARD ABOBA: No questions? I guess you're all getting hungry. Okay. Last call. I think we're done. Have a good dinner.