IETF 80 Technical Plenary 
Prague, Czech Republic
Monday, 28 March 2011

Session Agenda:

1.  Welcome - Olaf Kolkman
2.  IRTF Chair's Report - Aaron Falk
3.  IAB Chair's Report - Olaf Kolkman
4.  Technical Session: "The Future of Applications"
5.  IAB Open Microphone Session
6.  Adjourn

Minutes:

1.  Welcome - Olaf Kolkman

Olaf Kolkman: It's a little bit dense, but, as always, these meetings 
  are under the Note Well, which we all assume you've read and memorized 
  by now.

  Today, we are in Prague for the Technical Plenary of the 80 IETF. My 
  name is Olaf Kolkman. I'm currently still chair of the IAB. Some 
  supporting tools for this meeting is that there is a jabber room. It's 
  plenary@jabber.ietf.org. We have our presentations up loaded on the 
  site where 79 is replaced by 80 on this URL. Apologies for that. There 
  is a live English transcript for the people who are not native 
  speakers, if you zoom in to the streamtext.net URL you see there, you 
  can follow the transcript of the meeting, which is live, which might 
  help you in following discussions.

  That also goes for the people who are in the audience: Questions and 
  discussion time, specifically during the plenary topic, please, keep 
  your points short, to the point, and tell everybody who you are.

  Today's agenda. We'll start off with the IRTF chair report by Aaron 
  Falk. I will give the IAB chair's report. And then we'll go into 
  working session of the IAB.

  I'm saying this very consciously, because a working session of the IAB 
  is intended to inform the IAB about things that are going on in the 
  industry. We have prepared a topic that already led to some lively 
  debate. This is a good thing, because as the IAB, we want to get 
  informed. So members of the IAB have brought in specific thoughts and 
  we essentially want to see what the people in the audience think about 
  these topics.  We hope for lively and informative discussion on the 
  topic.  After that, we will close the discussion on the future of 
  applications topic, and go over into open mic, where you can come with 
  your more generic questions.  That closes the introduction of the 
  agenda. 

2.  IRTF Chair's Report - Aaron Falk

Aaron Falk: Hello, everybody. My name is Aaron Falk. I'm the outgoing 
  chair of the Internet Research Task Force. I'm going to give the first 
  half of the report and then hand it over to the incoming chair, Lars 
  Eggert.

  Here we go. There are four research groups meeting this week. Research 
  groups on Internet Congestion Control (ICCRG), Peer-to-Peer Research 
  (P2PRG), Scalable Adaptive Multicast (SAMRG) and Host Identity 
  Protocol (HIP).  Another activity going on this week is the ICCRG 
  chairs are going to be meeting with the IAB to talk about current and 
  planned work, and that's going to happen Thursday at breakfast.

  A few updates on some recent things that have happened. A, for the 
  IRTF, a fairly large pile of drafts were handed off to the [RFC] 
  Editor for publication. A large set from the DTN Research Group, and 
  three IRTF RFCs were published, including a recommendation for routing 
  architecture. That's really a survey of several different 
  architectures. That was worked on for quite a long time and represents 
  culmination of several years' worth of effort. 

  We've had a few changes in research group leadership.  Network 
  Management Research Group (NMRG) has, after many years of service, 
  handed off leadership to Lisandro Granville, who is not here this 
  week, and Olivier Festor, who is here. And there's Stephen Farrell, 
  who was a chair of the Delay-Tolerant Networking Research Group 
  (DTNRG) and is now an incoming Security Area Director, so they brought 
  in Joerg Ott on the for the co-chair of the research group. Similarly, 
  Wes Eddy, who was a chair of the Internet Congestion Control, is now 
  becoming Transport Area Director, and Murari Sridharan from Microsoft 
  is going to take his position in the ICCRG list. 

  I'd like to give a snapshot on which research groups are active and 
  which ones are quiescent, and I've got a low bar for what is 
  considered to be active, because research groups have different 
  timelines and ways that they operate. So, it's usually measured by 
  some substantive mailing list discussion or face-to-face meeting at 
  IETF or other venue.  So you can see this list here, I'm not going to 
  go through it.

  Just, you know, one slide of retrospective.  I've been IRTF chair for 
  six years, and I think the primary change contribution to the IRTF was 
  creating a new RFC stream that has the IRTF label. There's a bunch of 
  process creation associated with that to get an editorial review of 
  these documents, and as a result, we've published 22 IRTF RFCs, and so 
  that required cooperation of a great deal of people in the IESG and 
  the RFC editor, and of course the research groups and their chairs.

  Created seven new research groups, listed here. Also, closed several 
  research groups, and if you notice some names appear on both lists. In 
  research, you take chances and make mistakes and you think there's 
  something there when it turns out there isn't.  So that's sort of a 
  snapshot of what I've done in the past few years.

  Now I'd like to hand over the podium to Lars Eggert, coming in as the 
  new IRTF chair.  He's also leaving as Transport Area Director, so 
  we're having a soft transition. We're both involved in most stuff this 
  week so Lars can finish his Transport responsibilities and hand things 
  over to Wes.  So here's Lars. Congratulations, Lars. 

Lars Eggert: So hi, my name is Lars and I'm the outgoing Transport Area 
  Director, 2006 to 2011. I followed Jon Peterson, and that's why it 
  makes it five years. So you probably have seen me in that role. 

  In my day job I'm actually more of a researcher than an engineer or 
  developer.  My day job is a principal scientist, and in Finland I have 
  a second sort of day job as adjunct prof.  Now that I'm not Transport 
  Area Director anymore, I'm hoping to do more work on the Aalto 
  [University] side, which I guess will make them happier. Basically 
  since I was a grad student at USC in Los Angeles I've worked on 
  internet research projects. When I moved to Europe, by the European 
  Union and by TEKES, which is the funding agency. So I published a list 
  of papers. If you go to that link [http://fit.nokia.com/lars/] there's 
  a lot of stuff there. I'm a member of the ACM and IEEE and in that 
  role I'm sort on the TCP and org committees of several conferences. 
  There are two big once in networking. So I'm not only a Transport Area 
  Director. I do other stuff. And now IAB has elected me to follow 
  Aaron.

  So, what are the plans and I should say that, you know I'm a 
  researcher because my slides have foot notes.

  So, these say the meeting is Monday, and so, I haven't had a chance to 
  meet with the IAB yet, so take this with a grain of salt. These plans 
  are tentative and under discussion, so don't come back later and say, 
  'Your slide had this, and where is it?'  But these are baked plans, 
  and I've discussed them with individual IAB members but not the entire 
  IAB. 

  So one thing I want to try to talk to Aaron about is to do something 
  like an Open Area meeting for the IRTF. There really is not at the 
  moment a time during the week where all the IRTF guys get together and 
  talk about sort of the broader organization and what we should be 
  doing there. One use of that open meeting would be, for example, to 
  have a public discussion about whether we want to start a new research 
  group, and what it should be doing, rather than doing it in some, you 
  know, smaller rooms that you have to know about.

  The second thing that ties into this IRTF open meeting is that ISOC is 
  piloting, together with us, a program to increase research or 
  participation in the IRTF and in IETF.  And basically this consists of 
  ISOC funding the travel and the stay of selected researchers to come 
  here, and we thank them for that. There's a selection committee that 
  researchers can either apply to themselves, or if you see good 
  research somewhere that you think might be interesting for the IRTF 
  and IETF to hear about, you can nominate them.  And then there will be 
  a selection committee made up of a few folks from the IAB and the 
  IRSG, and we'll fly the person out to get a talk at the IRTF open 
  meeting, and there will be shadowed by a mentor for the week and 
  introduced to the organization and hopefully, they'll bring their 
  ideas and we'll get an influx of new ideas through that vessel.  There 
  will be announcement very soon, I'm expecting it will come this week, 
  as soon as as tomorrow or Wednesday.  So watch out for that. It will 
  probably go to IRTF and IETF-Announce, and probably the main IETF-
  Discuss list.

  The third thing is we have a discussion that's ongoing with our 
  meeting about how can we increase the attractiveness and relevance of 
  the IRTF. That's something we're going to hit at dinner with the IRSG, 
  and we're going to discuss this more openly in Quebec.

  Finally, just sort of as a heads up, there's lots of discussion going 
  on right now about potential new research groups. One is related to 
  the Internet of Things; we had the workshop last week, there's people 
  here this week that want to do research work related to that, that 
  complements the engineering work already undergoing in some IETF 
  working groups. And there's a list of other topics that people have 
  sent e-mail about and there have been pre-meetings, and there are 
  other meeting about this this week. Some of this you might see in 
  Quebec or later this year.

  That was my last slide. Thank you.

Olaf Kolkman: Thank you. Don't run away quite yet, Lars. I mean, Aaron. 
  Your time will come.

  First, as a colleague, Aaron has been IRTF chair for six years, which 
  is a very, very long time.  It takes a lot of stamina to sit through 
  all the IAB meetings, because that's what you do too, and then have 
  your own coordination. I know it's a nice group of people to be 
  leading. I've enjoyed the pizza evenings that I've been invited to, 
  and it has been a real pleasure to work with you. Thank you, for that, 
  and on behalf of the ISOC and IAB, there is a, there is the 
  traditional plaque, thank you.

[Applause.]

Olaf Kolkman: And on behalf of your colleagues in the IAB, there's a 
  nice drink for getting home and thinking about us once more.

Aaron Falk: Thank you.

3.  IAB Chair's Report - Olaf Kolkman

Olaf Kolkman: This is the IAB report. It is structured along the 
  structure I've used before. First, about the IAB. There are a few 
  newcomers in the room that may not have heard about the IAB. The IAB 
  is a body of the greater IETF, Internet Architecture Board. It's 
  chartered, its charter is published as RFC 2850. We have an IAB home 
  page, www.iab.org. We are currently in the process of migrating that 
  site to a WordPress site so we can keep it up-to-date faster and keep 
  more vital and more fluid information on that site.  Anyway, the links 
  to the documents and the correspondence that we have with other 
  entities and the documents that we published is the link that you see 
  on the page, and minutes are published as well, not as fast as we'd 
  like. I'll get back to that in a bit.

  RFC 2850, the charter, is subdivided in a number of points: IESG 
  appointment, architectural oversight, standards process oversight and 
  appeals, RFC series and IANA, and ISOC liaison and external liaison. 
  Those are the points that are listed as responsibilities and my report 
  is structured in a way so you can see how the things we do fit into a 
  charter.

  Architectural oversight, that is basically the architectural work that 
  we do. That involves things that we don't publish about, such 
  assisting in BOF reviews, assisting/bringing new work into the IETF, 
  thinking along with the IESG about charters and such.  And also, 
  bringing IAB members to the microphone session in working groups.  
  But, the more tangible bit is our document activity there. We have 
  recently published RFC 6055, "Thoughts on Encodings for 
  Internationalized Domain Names," and we recently submitted for RFC 
  publication (so that should get a number in the next report) 
  "Evolution of the IP Model."  This has been the topic of a plenary 
  many moons ago.

  We're in the final stages of the "Design Considerations for Protocol 
  Extensions," and there is a document which has been sleeping more or 
  less, "Architectural Considerations of IP Anycast." For these 
  documents, call for comments are planned for next revs. What we 
  usually do is, before we decide to actually submit a document to the 
  RFC editor, we call for input. It's not a last call. It's not a 
  permission to publish. But a call for, have we overlooked something?

  Other documents we're working on: "Architectural Considerations on 
  Application Features in the DNS." It's one of the initiatives of the 
  2010 work plan that we constructed during our retreat. It's being 
  developed and worked on.

  And another document we're working on (and I'll come back though 
  later) is "Defining the Role and Function of IETF Protocol Parameter 
  Registry Operator." I'll get back to that in a bit.

  Also, in our architectural oversight functions, we've been organizing 
  two workshops. One fit in the program is a sort of long term work 
  structure within the IAB.  And that workshop was held in December, at 
  MIT, co-sponsored with the Internet Society, and it was a joint 
  workshop between the IAB, ISOC, W3C and MIT. The theme of the workshop 
  was how can technology improve privacy on the internet?  That is a 
  topic in itself, and I won't go into the details during this report, 
  but there is a corner on our web site with the URL on the screen 
  [http://www.iab.org/about/workshops/privacy/], which contains the 
  minutes, the position papers, slide ware, and will contain the report 
  of that meeting.  One of the immediate outputs of that meeting is 
  that, a privacy directorate has been formed within the IETF.

  Another workshop that was organized shortly before this IETF was the 
  Smart Objects workshop.  Again, the material can be found on the web 
  site: http://www.iab.org/about/workshops/smartobjects is the link.
  This was a collaboration between many entities: the IAB itself, the 
  IETF Internet Area, Routing and Applications Areas, the Technical 
  University in Prague, and the European Commission.  And after the 
  workshop, we also had a tutorial on the issues that have to do with 
  smart objects, tiny little machineries that live on the network, what 
  are the considerations that you have to take into account when 
  designing machines with low memory, low power and low footprint.  [The 
  workshop was] sponsored by Ericsson, Nokia and Cisco networks. I 
  shouldn't forget that, of course.

  In the standards process, we do oversight and appeal. And normally, 
  that takes the shape of handling appeals that are escalated before the 
  IAB level, and I'm pleased to say there were no appeals.

[Applause.]

Olaf Kolkman: I don't understand the applause, because we cannot do 
  anything about getting appeals or not. So, it's nothing that we did 
  here.

  Another section of our our responsibilities is RFC Series and IANA 
  oversight. In the context of this, we had two efforts going on, the 
  RFC Editor model and IANA, and then specifically notice of inquire 
  from the U.S. Government.

  The RFC Editor model: I've reported on this reorganization project 
  more often. We had more plenary sessions about that. You might recall 
  various meetings, since.  I have consistently pointed people to the 
  RFC-interest list for the development of consensus around this, and we 
  developed a consensus which was documented in a draft.  The consensus 
  developed in that draft formed the basis for writing an update to RFC 
  5620, the RFC Editor Model, version one.  And a body of work that is 
  needed in order to hire a permanent RFC Series Editor--the whole 
  project was started because we found it very hard to find an RFC 
  Series Editor--and at the point that we found that out, we decided to 
  hire a transitional RFC Series Editor who could make an inventory of 
  the problems and the possibilities to fix the situation and make the 
  job more attractive.

  As said, in development of consensus, we've been working towards a 
  model v2, a statement of work, a call for candidates, and a search and 
  selection procedure; and in the meantime we also have appointed an RFC 
  Series Oversight Committee.

  The RFC Series Oversight Committee {RSOC) is a formally chartered 
  program, I would say from the IAB. It is where the IAB assigns 
  responsibility for the oversight of the RFC Series, maintaining the 
  long-term consistency and knowledge and reporting to the IAB so that 
  the IAB can make final decisions.

  I would like to acknowledge Glenn Kowack, who is the Transitional RFC 
  Editor who did all the work. His engagement ended at the end of 
  February.

  As said, we appointed an RSOC, one that manages all the practicalities 
  of RFC Series oversight. And one of the first things this body will do 
  is take up the statement of work, the search and selection process and 
  the job description and will start looking for a person.  In the 
  meantime, we don't have somebody to escalate problems to. I have 
  volunteered for the role as Acting RFC Series Editor, and the jokes 
  about the acronym are plenty. The first one is a brown dot.  That 
  said, the responsibilities there are to make sure that there is an 
  escalation point to keep RFC publication moving.  As soon as there is 
  a problem that cannot be fixed by the publication house, because there 
  is a policy question that is to be asked, then, and it stops RFC 
  publication, then it's the time for me to do some work.  This RSOC has 
  been appointed: Fred Baker, Nevil Brownlee, Bob Hinden, Ole Jacobsen, 
  John Klensin and Alexey Melnikov.

  So that's the update on the RFC Series project. We're moving along the 
  expectation, the hope, I should say, because this project has been 
  suffering a few delays, but the hope is that getting a search out and 
  selecting a candidate will be done within half a year.

  The next part in this RFC Series and IANA Oversight responsibility, 
  IANA, we have been developed, I've been reporting this draft a couple 
  of times, a draft called draft-iab-iana. It is documenting what we 
  expect out of an IANA, out of IANA registry operators.  The needs of 
  the IAB, and the IETF are documented within this document.  This is 
  particularly relevant, since there is currently a U.S. government 
  notice of inquiry about the IANA functions.  

  The IANA functions are under contract with the U.S. Government, and 
  that contract is up for renewal, and they are asking for our input.  
  The IAB has been developing the input and we believe that a normative 
  reference to the draft-iab-iana content is of importance.  And that is 
  the reason why on the IETF announcement list, I told people that we 
  are planning to approve this document and submit it to the RFC Editor 
  on Tuesday. I did that on Saturday last week, which is a very short 
  call for review.  We realize that--apologies therefore.  Still, if you 
  have interest in this stuff, and you want to provide input, you have 
  until end of day today, until 12 o'clock.

  This document is not new. It has been around for a couple of years.  
  People have had a chance to read it and this is a bit of a deadline-
  driven effort, that sometimes happens with important but not-so-urgent 
  projects.

  ISOC, another responsibility in the charter of the IAB. We're 
  responsible for the appointment of an ISOC Board of Trustees (BOT) 
  member.  We have asked for candidates on the IETF announcement list. 
  We have received feedback and confirmations that those candidates are 
  willing to serve. They are Jonne Soininen, Joe Touch, Tina Tsou, Henk 
  Uijterwaal, Tom Walsh and Bert Wijnen.  We will have to make up our 
  minds by April 7 about these candidates, and we appreciate any 
  feedback you would have before April 1.  After we have made a 
  selection, we will send that selection to the IESG for confirmation 
  and it is expected that these people will start May 15, if I'm not 
  mistaken.

  IAOC selection is another responsibility that's NomCom based or based 
  on BCP 101. We have to select an IAOC member every two years. We did 
  so in the last period, and we selected Bob Hinden for the IAOC.

  External Liaison. The relations we maintain with other entities is 
  another responsibility of the IAB. Currently we're in the process of a 
  pointing a new ITU liaison. Patrik Faltstrom assumed responsibility 
  as ICANN's Security and Stability Advisory Committee chair. That meant 
  we lost a very good person. Fortunately, ICANN gains a very good 
  person; the world is in in balance. 

  And we're currently looking for a new ITU-T liaison. We have a short 
  list of candidates and we're discussing this week who to appoint.  As 
  the IAB, we are tracking from a little bit of a distance the 
  developments around the joint work on MPLS. The obvious question is 
  what is the value of the agreements the between ITU-T and IETF, 
  specifically in the context of this work?  And we're thinking about 
  the guiding principles that should be the basis of agreements going 
  forward.  And, I think that we already conversed on those long time, 
  and they've been published many many times before, it's 'work that is 
  within IETF is done under IETF process rules.' And IETF protocols are 
  to be modified by the IETF only, unless the IETF consents to give them 
  away, so to speak.  One of the things that has been done is getting 
  factual information. This is done by the IAB chair and the Routing 
  ADs, and we're looking forward to having a closer look to that list of 
  events.  And that will be made available later. 

  Another thing that we did is that members of the IETF leadership--this 
  is not formally an IAB thing but we participated in making it happen--
  We had a subset of the IAB leadership mediate with the European 
  Commission Information Society and Media Directorate General 
  leadership. That's a mouthful. But it's the club of people that 
  basically do IT at the commission level in EC.  And the the purpose of 
  that meeting was to establish informal channels and make sure that we 
  know who to talk to, what is going on in the EC, with respect to 
  funding for future internet. That kind of thing. Make sure that EU is 
  actually aware of the good work going on in the IETF, what are the 
  processes that we follow and what we do.  And a lot of that consisted 
  out of explaining how work is introduced in the IETF, and how you get 
  people to the IETF and explain that it's actually an open place where 
  you can show up and contribute.

  Another question was raised in e-mail to us, at some point. A 
  contribution was made to a notice of inquiry to the FCC, and that 
  contained the names of a few IETF leaders with their affiliations. One 
  of those members was an IAB member, and I mean their IETF 
  affiliations. One of those members was an IAB member and that can lead 
  to a various kinds of perceptions. We had some discussions about the 
  meta level of those perceptions that can be created, and we figured 
  that writing guidelines at least starting with guidelines for the IAB 
  when to use the IAB affiliation and when not is probably a good thing. 
  In the meantime, this was less relevant for the filing because that 
  was amended and re-published just with a personal affiliations of the 
  people that submitted it. So, everything was in the white for that 
  case, and was not in the gray area any longer.

  Further, on February 3, we had a meeting between the IETF chair, the 
  IAB chair, ISOC president, the CEO of ICANN, the CEOs of the five RIRs 
  in Miami, just to get to know each other a little bit better. This was 
  the first time the leadership of all these I* organizations met in one 
  place and discussed things that are of mutual interest. For instance, 
  the NNOI was one of the things we talked about.  Coincidently, the 
  last five free /8 IPv4 were allocated to the five RIRs. That was a 
  somewhat classic event I would say. We're out of IPv4. It's not the 
  end of the world as you all know. I don't have to preach to the choir 
  here. But we're out of them. And that is a good segue into making 
  people aware of June 8, 2011.

  June 8, 2011 is World IPv6 Day, where service providers and content 
  providers will try and do their best and run IPv6 for one day, for one 
  complete day.  Big players will switch over their network and prefer 
  IPv6 for a full day.  Very interesting place. And also, something that 
  you can take home to your management to say, maybe we should 
  participate in such a day. And maybe we should get ready to, well, 
  have a nice deadline there to achieve at least something.  This is an 
  initiative by ISOC, but we figure it would be good to plug it here. 
  Details are on the isoc.org web site.

  Finally, some IAB internals. As you saw and as I mentioned before, 
  minutes were late yet again. A bunch of minutes got published shortly 
  before the IETF deadline.  One of the things that we want to do is 
  organize ourselves a little better. We've taken a lot of steps with 
  organizing ourselves in programs and initiatives, but also our 
  internal organization is something that we continue to work on.  And 
  in that context, we have hired an Executive Assistant function, 
  essentially the same, similar to the IESG Secretary function, somebody 
  who will help us keep minutes, help us keep notes and agendas, and do 
  communications, make sure that things are lined up, materials are 
  available and such.  This is not an Executive Director function, 
  because that's a far more technical function, and that will probably 
  remain to exist. But we're very happy to have her, she is with AMS. 
  Cindy Morgan, thank you, for helping us out.

[Applause.] 

Olaf Kolkman: Yes. You got the applause, now you have to do the work. We 
  have a bunch of new members. I will introduce those new members when 
  we are at the mic. With open mic, but that means we also have outgoing 
  members.  Marcelo Bagnulo and John Klensin have left us this meeting. 
  Vijay Gill did that earlier. John Klensin is home for medical reasons, 
  unfortunately. For the open mic session we have brought John in in a 
  box. He will be participating remotely.  But for now, I would like to 
  invite Marcelo to the stage. Marcelo, where are you?  And this is also 
  the time that Bernard probably wants to step somewhere, because I want 
  to introduce you shortly. Yes.

  Again, on behalf of the IAB and ISOC, we'd like to thank you for all 
  the energy and time you spent, sometimes, sometimes difficult, 
  sometimes a little bit more easy. I hope you enjoyed it. I enjoyed 
  working with you, and learned a lot. Thank you, again.

Marcelo Bagnulo: Thank you.

[Applause.]

Olaf Kolkman: We also have the plaques for John [Klensin] and Vijay 
[Gill] available.

  Now, the last piece on this, the last line item on this little slide 
  is that I am stepping down as chair. And we have elected a new chair, 
  and it's Bernard Aboba. And in order to have a little token to pass 
  around, because we don't pass dots, I have here a little chair thingy 
  [a gavel] that he can use to keep order, in more physical way than I 
  could.

[Applause.]

Bernard Aboba:  Don't go anywhere. We wanted to thank Olaf for his many 
  years of service and all the wonderful things he's done. And so we 
  couldn't have a full roast here, which I think would be appropriate to 
  skim all the times, so we thought we'd have a few people come up and 
  say a few words, people who work closely with you. So the first is 
  Russ. Well, we'll bring up Lynn first and then Russ.

Lynn St. Amour: The IAB's role is to provide guidance to the internet 
  society. And I just want to thank Olaf, he's been a great partner. The 
  IAB has to deal with architecture, and increasingly policy issues 
  which is not always evident, but Olaf has put in an incredible amount 
  of time and careful thought and it's been a joy and pleasure to work 
  with him over the last year. So I just want to thank you, and we have 
  a plaque for you as well. Which means you'll get two I guess, but 
  thank you, Olaf.

Olaf Kolkman: Thank you. 

[Applause.]

Russ Housley: So, four years ago, Olaf became IAB chair and I became 
  IETF Chair in the same week. And right before that, the previous IETF 
  chair, Harald Alvestrand, described the relationship of IAB Chair and 
  IETF Chair as a two-headed troll. So, Olaf and I have had gone through 
  this journey, and I couldn't have picked a better other head.

  The numerous things in just the last few weeks, we've seen the 
  exhaustion of the last /8s from the IANA free pool; we've dealt with a 
  considerable organization. And Olaf has laid the framework for a 
  wonderful complete response of how the community feels about IANA and 
  NOIs, so it's been a pleasure working with him. I'm going to miss him, 
  and the IAB has gotten together and gotten a small token of our 
  appreciation. Thank you. 

[Applause.]

Olaf Kolkman: I'm still going to, I cannot let go, you see that. I'm 
  going to call Jon Peterson to the stage, for the content-full part of 
  the technical plenary. Please, Jon. 

4.  Technical Session: "The Future of Applications" - moderated by Jon Peterson

Jon Peterson: Thank you, Olaf and by the way, thank you, Olaf.

[Applause.]

Jon Peterson: Okay. So, I'm, I don't have any big preamble to go through 
  here. I think I'm just going to call Henry Thompson, Harald 
  Alvestrand, Jonathan Rosenberg and Leslie Daigle, if they can all join 
  me now for this exciting technical plenary we're going to have. There 
  has been a great deal of discussion about this. We want to stress that 
  we want to keep substantive questions about the presentations until 
  the time for technical discussion, of which there is plenty; we have 
  about an hour and forty-five minutes on the schedule for this. So I 
  wouldn't particularly worry about that. But if you have clarifying 
  questions that are brief and can be resolved easily, feel free to 
  bring them up to the stage.

  Henry is going to speak to us first here about an organization called 
  the W3C [World Wide Web Consortium], what they do, what their 
  responsibilities are and how they interface with us. Following Henry, 
  we're going to call Harald up to speak about the RTCWEB process, that 
  BOF is tomorrow morning. Following Harald will be Jonathan. Jonathan 
  will talk a bit about how much he likes the SIP protocol, and kind of 
  what the future is of voice over IP applications on the internet. And 
  Leslie, who was not originally scheduled to, has at the last minute 
  and great expense, we're very thankful she was able to come up here 
  and provide a slightly different perspective on this problem space--
  one that we think will show us a bit more of how this fits in with our 
  general architecture problems. Without further ado, I will hand this 
  over to Henry. 

Henry S. Thompson (W3C): [See slides: "The future of applications: W3C 
  TAG perspectives."]

Jon Peterson: Thank you, Henry. And if Harald, you could make your way 
  over here, as I get your presentation up.  That is not your 
  presentation.  Yes, the entirety of Henry's presentation will be up on 
  the web where you can see it. And actually from this point forward, I 
  think it's all former IAB members, and I believe we need to award you 
  an honorary former IAB position here. But Harald, please.

Harald Alvestrand (Google): [See slides: "IETF in the Browser."]

Jon Peterson: Thank you Harald, Jonathan Rosenberg, you're up next.

Jonathan Rosenberg (Skype): [See slides: "The End of Application 
  Protocol Standardization (?)"]

Jon Peterson: Thank you, Jonathan, very stimulating.  Leslie, you're up.

Leslie Daigle: [See slides: "Should all the building blocks be yellow?"]

Jon Peterson:  Thank you Leslie.  We will get to our open discussion on 
  this topic momentarily.  So if you are interested in talking about 
  this, please do start making your way to the microphone. Before we 
  begin that process, I'd like to reiterate what Olaf said at the start, 
  this is a session where the IAB is thinking and exploring--certainly 
  not dictating anything.  As has been pointed out on the IETF mailing 
  list, a few members of the IAB did produce a document that's draft. 
  It's not an IAB document, or really probably a state yet to be an IAB 
  document. The purpose of this plenary, aside from having these good 
  people to educate us all, is to help us think about what the IAB 
  position should be, if anything. We've had one component of that so 
  far, which is the discussion of the people to my left. Now it comes to 
  all of you to help us figure out what we need to do with this.

  We have so many interesting efforts it seems like that are bubbling up 
  to our process, which RTCWEB [Real-Time Communication in WEB-browsers] 
  is one example, HYBI [BiDirectional or Server-Initiated HTTP] is 
  another one that seems to be poking at a similar point. We've tried to 
  focus these presentations around that, but we're not sure what the 
  architecture is that needs to be articulated if any, and we appreciate 
  your thoughts about that.

  I see plenty of people at mics, I think Mark Nottingham was the 
  spriest. 

Mark Nottingham: When I first learned about this plenary, when you first 
  talked about it, I was happy because one of the hats I wear is the 
  IETF liaison to W3C. For a while now, there's been a lot of things 
  happening in the web world that seem to be flying under the radar, at 
  least around here. And I was happy because, you know, the capabilities 
  being added to browsers in the next generations are truly astounding. 
  I think people think it's just more javascript and so forth. But 
  they're doing APIs for file access in the local file system, web 
  sockets, audio APIs, video APIs; and they're turning it into a viable 
  application platform. You're going beyond the browser to where it is 
  an operating system in some cases. So it's important for folks to 
  realize this is where a lot of applications are going to be deployed 
  in the next couple of years. From an IETF perspective I put my hat on, 
  at heart I'm an intermediary guy, and I get concerned because I look 
  at things like web sockets and there's a lot less opportunity for 
  intermediation there. If you're a vendor, and you're used to doing 
  things like load balancing, that's easy when the protocol has a high 
  level of semantics. When it's web sockets, it's really hard, low 
  level.

  If I take all those hats off, I think one of the background things 
  that is happening here that has not been talked about is that this 
  architecture--and this is really just me talking personally, to make 
  that absolutely clear--this architecture is not being pushed by the 
  W3C. This architecture is not being pushed by the IETF. It's being 
  pushed by a group of browser vendors, the WHATWG [Web Hypertext 
  Application Technology Working Group, 
  http://wiki.whatwg.org/wiki/FAQ/]. And they are pushing a vision where 
  standards are not relevant anymore, where they want to do things 
  through open-source. So instead of going and talking to people about 
  this is my protocol, you come up with a javascript and then it goes 
  out and you can get acceptance that way.  That's a perfectly valid 
  model. I think it has pluses and minuses, but I think that's the 
  discussion that we need to have, and accounting for in the future work 
  that we do.  Also, you know, I heard a couple of people up there say 
  this is about HTTP or REST. Be very clear, these people don't care 
  about HTTP. They're pushing web sockets. They certainly don't care 
  about REST. They don't care about declarative mark up. They care about 
  javascript code. That's what we need to focus on.

Jon Peterson: Would anyone like to speak to that up here?

Henry Thompson:  Thank you, Mark. I'm going to just respond to the last 
  bit because I think it's the bit that is most immediately germane to 
  the W3C.  And I guess my perspective is slightly different. I agree 
  that the IETF isn't pushing this and the W3C didn't start out pushing 
  it.  But the browser as distributed application delivery platform, the 
  momentum for that pre-dates the WG. The momentum for that came from 
  the evident success of the democratization of application delivery 
  that was unsubstantiated by what was called for a while web 2.0. It 
  appeared to take, as I said, it democratized the possibility for 
  people to deliver applications although over the planet from their 
  garage. And people did it. The way the WG and standards body in 
  general have responded to that, has been to say, 'Gee, we need to 
  serve that constituency.' And, that's probably where I'll stop. So I 
  don't actually think that the WHATWG are the villains in this case. 
  The attempt to accommodate the push towards the distributed delivery 
  platform view of the browser is one that the standards bodies have to 
  respond to.  Because otherwise, we're going to lose interoperability. 
  And I'm sorry. I'll say one more thing and give it back to you. If 
  there's one thing I disagree with you about, it is that the problem 
  with saying no standards required, if software delivery centralized, 
  absolutely not. I don't agree with that at all. Because, that's, that 
  way silos. Facebook is not a good example of why it's a case that if 
  you deliver the software to the browser, you don't need standards. Of 
  course you need standards. I can't exchange any information of 
  relevant with my teenage children because they're inside the silo. We 
  can't even try. Because they're inside the silo and I choose not to 
  be.  That's the problem. That it seems to me, that there is, if I 
  understood you correctly. 

Mark Nottingham: So, Henry, I tried and maybe failed to not portray them 
  as villains.  Certainly some people have other interpretation.  There 
  certainly was momentum before they came along, but they strapped a 
  couple of jet packs to the back and are pushing along pretty quick. 
  Overall, the message is, there's a lot of change happening and we need 
  to have a look at it. It's got pluses and minuses. 

Sam Hartman: So first of all, Jon, IAB, great plenary. I figured there's 
  a 30 percent chance I was going to be really unhappy. That's not the 
  case, this is really well done.  Brief comment number 1: the Security 
  Area really should look at getting some of our technologies 
  componentized as building blocks in this new platform. I think there's 
  room for us to help the world out, and I would love to be part of 
  that. We should do it.  Comment number 2, I think it's really 
  important for us to look ways where we can take advantage, where we 
  can participate in these, producing building blocks like the real-time 
  web stuff, and basically, you know, adding to this platform and I 
  think that's going to be one of our goals.  I think, however, this 
  claim that standards aren't going to be needed, especially not in the 
  client server area, is just complete garbage. It's absolutely true 
  that standards have always only been needed when people are actually 
  going to deploy them.  I guess there's some cases where we do 
  standards where we know nobody is going to deploy it and some of them 
  I support. But that's a corner case.

  And it's absolutely true that probably in a qualitative way, this 
  changes when the trade-offs encourage standards deployment. But I'm 
  sitting here thinking what the world would be like if we didn't have 
  IMAP and we had, you know, that's an easy one to pick at. Everybody is 
  getting Gmail or Microsoft or one other providers, so clearly we don't 
  need a client server email standards.  If everyone is a user at a 
  browser, that's great. But, see, there are a lot of other programs, 
  and things that want to use e-mail. And you're going to have to 
  implement -- so let's say Google publishes their APIs and you 
  implement the Google and then the Microsoft API, and you implement 
  five or six different ways to read e-mail so so you can read the e-
  mail based on whatever provider they have.  I think that remains the 
  same. I've heard this argument, in many open-source conferences in the 
  past. It's about a ten-year-old argument, if not more, about how 
  standardization is going to go away as we improve app delivery. Open 
  source communities have been improving the app delivery, and in some 
  sense have native app delivery that are good enough that they've been 
  having the debate longer than the browsers. You know what they're 
  doing now, they're starting to realize they need standards. Why? 
  Because they've run across cases even within a platform, they run 
  across cases, where the app delivery, basically there are enough 
  consumers of an interface and enough people that want to contribute 
  that one of the criteria that Leslie came up with applies.  So there 
  are standards organizations, free standards organizations, various 
  other Linux things and other open-sources thing that are standardizing 
  the interfaces that you could handle through app delivery. Why? 
  Because they have enough consumers and providers that having everyone 
  consume everyone else's published-but-not-standardized API was not 
  working.  Finally, I really agree that we need to start anything about 
  APIs as well as protocols.

Harald Alvestrand:  Thank you, Sam. I think Leslie reiterated the point 
  that, when different people connect, they have to make an agreement. 
  And standards are just one very formal way of making an agreement.  
  One point I would want to add onto that, that file formats are 
  actually a special format of API, it's one where old versions never go 
  away. So they're extremely appropriate for standardization.

Jonathan Rosenberg: So, Sam, thanks for that, too. I think you make a 
  great point about e-mail, and this is this is why I think it's 
  important to understand it's not black or white. As I was saying in my 
  talk, there are in fact cases where you still want some of the old 
  models. I talked about hardware, where you don't have the ability to 
  distribute software, and I pointed out the other case, which is when 
  in fact you have a service that's homogeneous and broadly the same 
  across a large--say greater than ten or a hundred, whatever the number 
  is--people. And e-mail is clearly an example of that. The interesting 
  question to ask is, will there be more like that? Will there be a next 
  internet application that's homogeneous across a large number of 
  service providers and individual domains that requires standardization 
  of these interfaces? And what's interesting about the current trends 
  is heterogeneity, which is that they're not all the same. Because each 
  of these services actually does different things.  I'm not saying it 
  won't be possible. Maybe things with social networking will get 
  sufficiently commoditized that there are a common set of things that 
  all social networking sites do, but we don't seem to be there at the 
  moment. And e-mail has been around a while. Nothing I think would be 
  similar in scope and scale. SIP certainly never reached that point 
  either.  So that would be my response to you, I'm not sure we'll see 
  another one like e-mail.

Sam Hartman: Instant messaging.

Jonathan Rosenberg:  Yes, XMPP maybe.

Leslie Daigle: Oh, man, you said instant messaging. I briefly co-chaired 
  the IMPP working group. But I think that emphasizes the point. It's 
  not just a question of whether or not different services or service 
  providers are going to be running exactly the same service to users, 
  and that's where you need homogeneity. Are there certain key 
  functionalities and infrastructures that would be helpful to support 
  in an uniform way, so different services can be built and deployed to 
  be more concrete. For instance, there's a lot work going on in 
  identity management.

Jon Peterson:  Thank you. We've probably got about 15 or 20 minutes 
  left, so please be brief in what you say. 

John Brzozowski:  This year we experienced or witnessed a pretty 
  significant event. It was mentioned earlier with the IANA free pool 
  depleting. And there's been a lot more attention on things that people 
  are going to be working on to kind of facilitate the transition of v6. 
  There's also going to be a lot of work on things v6 related. So in the 
  spirit of briefness here, perhaps for Jonathan or Leslie, how do you 
  see these events, with out-with-the-old, in-with-the-new, affecting 
  some of the building blocks? Or Jonathan, some of the things you 
  mentioned, what made us successful over the years? How do you see 
  these events altering any of those? I'm looking for your perceptions 
  or opinions in this matter. 

Jonathan Rosenberg: I'll try and be brief. I'm not sure how to interpret 
  that. But I think there's certainly a need for standardization of 
  things on the lower layers. I think that's unchanged. And to Leslie's 
  point, enabling things like identity OAUTH and things that are not 
  specific to applications. I'm sure we'll see continuing need for those 
  components. As long as they're enablers for other things, I think 
  there will be a continuing need for that.

Phil Hallam-Baker: Going back to Henry's talk. I think one of the 
  dangers of an architecture board is there's always an assumption here 
  that the purpose of an architecture board is to protect the internet 
  or the web, from itself.  And the second assumption is that these 
  architecture boards are going to do things that are important. Both 
  assumptions are wrong, in that you can't protect the web from itself, 
  because the only people who are going to cause damage are the people 
  people who don't care and the people who don't listen. And neither of 
  them are going to take your advice. And the place where you can make 
  decisions, you can't make decisions that matter, because those will 
  affect the protocols that come out. So the only decisions that you can 
  you can make are two cases that do not matter. Like ASCII. It does not 
  matter what mapping of number to character you have.  All that matters 
  is that everybody does the same.  Now, looking at how web services and 
  so on are developed, I've developed a few. Every time I've had a 
  standards working group, we've spent the first year discussing the 
  same things. We spent a year discussing, how are we going to use URIs? 
  How are we going to use XML or layer on top of SOAP. There's a whole 
  list of our six questions that every one of these working groups has 
  rattled on in the same way, many cases with the same people. And if 
  you're going to add value, don't try and save us from ourselves. Look 
  at that list of things that every group has to do, time and time 
  again, and fix that, the stuff that really doesn't matter and isn't 
  going to break the internet. And don't worry about the stuff about 
  using semantic web or whatever, it's not relevant. 

Henry Thompson: Thanks, I think that's a very useful reminder, and I 
  agree. You know, people who don't want to be told, won't be told. 
  Getting definitions clear, making the ground rules clear, solving the 
  problems that get encountered over and over again, is a problem that 
  multiple working groups encounter is almost by definition an 
  architectural problem. So that's a very useful observation. Thank you.

Ted Hardie: I was going to say how much I loved the talks today and 
  appreciated everything.  I wanted to pick up on something that Leslie 
  had in her slides that I think actually tied into what Sam was saying.  
  In Leslie's slides, in addition to our usual talk about 
  interoperability, she mentioned something that I think is very 
  critical to understanding when we can add a lot of value here. That 
  is, she put up inter-networking as well as interoperability. I think 
  in the pointers to various protocols like e-mail or XMPP where 
  Jonathan, you are seeing value for standards of the type that the IETF 
  has historically done, inter-networking is a critical part of those. 
  It's not downloadable from a client to a server because you are 
  attempting to inter-network as well as have that one single 
  connection.

  And I think it's very important for us to understand that that style 
  of interoperability, where inter-networking is a critical part of it 
  is a big part of the application protocol space, that has historically 
  been part of the IETF.  But I also want to say, it's also a very 
  critical piece of what makes a good building block. Because if you 
  build something that's capable of inter-networking, generalizing it to 
  something which doesn't need to inter-network, is in fact much easier. 
  And I think in the web context, that's what happened. The web context 
  is a network of resources, and taking the capability of using that 
  inter-networking of resources, to build something that's purely client 
  server with downloadable code is much much easier than if you 
  started the other way and took a client server protocol and tried to 
  turn it into something capable of inter-networking, both among 
  multiple clients and multiple contexts. So I think it's very important 
  and I think all of you have alluded to it in different ways, to think 
  not just interoperable between client and server, because downloadable 
  code can solve your problem there, but how it fits into the inter-
  networking context in order to see when you are really going to have 
  to have to have standards, not necessarily more than the standards we 
  already have, but you have to have standards for making that inter-
  networking style of interoperability a success. Once you have those, 
  those tend to become our building blocks for all kinds of other 
  things, and I think it's important for us to realize that.

Dave Crocker: Hi. Henry, hello. I quite liked your opening ceremony 
  speech. I thought it was both a good introduction and a good 
  invitation. There were many things that you said that would be worth 
  talking about. But the most important part was suggesting lines of 
  work. And they all sounded pretty interesting to me. By the way your 
  DTD accessible look up problem is easy to solve. Just store it in the 
  DNS.

[Laughter.]

Henry Thompson: If that's an offer, I'll take I you up on it. 

Dave Crocker: Well, I do have the server, but I don't think it would 
  give quite the performance you'd need, and I'm sure your records 
  aren't too long or anything like that.

  Harald and Jonathan, the sorts of things you talked about seem to 
  divide into three categories. One of them was some discussion of what 
  I'm going to call standards process failures. Another was adoption 
  failures. And a third was areas of opportunity for doing new work.  
  Let me suggest to you the first two topics, in at least the form being 
  pursued right now, is not very productive. And the third one, could be 
  extremely productive.  I frankly took Leslie's talk on focusing on 
  that third topic, and I'd like to encourage that's the place to focus. 
  What kinds of work should we be doing, rather than what are we doing 
  that we should not be doing.  And I think that there's plenty of 
  opportunity here, probably the only critical path problem worth 
  pursuing is stopping calling APIs a protocol.  But in general, for a 
  lot of this space, we're dealing with complexity, and let me suggest 
  that any reference to complexity needs some paraphrasing of Menkin, so 
  I'll bring up two of them. For every complex architecture, there's a 
  simple improvement, and it's wrong. And for every complex failure 
  there's a simple analysis, and it's wrong.

Jon Peterson: We've got about six minutes left here. Thank you.

Linyi Tian (?): I have a question to Jonathan Rosenberg. So I appreciate 
  the presentation you made is quite interesting. My understanding on 
  the two innovation cycle, you mentioned that both were more focused on 
  enabling capabilities for, as standards in the future. But in terms of 
  application standards, I have a question. So, you mean in the 
  Internet, innovation cycle there were more, the service provider or 
  developer and deploy and publish work, that means more application 
  developers and other software companies were more focusing on 
  developing using existing infrastructure like HTTP or REST for 
  architecture, and develop their own application can be downloaded to 
  the client. But my question is, if that is the case, who are demanding 
  the standards? Who gives the requirements to the IETF to standardize?

Jonathan Rosenberg: So I think this goes back to what we've been saying 
  up here before, is that there's need for standardization of individual 
  enabling components.  As people have experience in doing these things, 
  they find it would be easier if there was a common way of solving it, 
  or if something is not working well, bidirectional, I think that will 
  be a big source of it.

Pete Resnick: So, a couple of things on Henry's talk: Henry, I was a 
  little surprised and frankly a little worried that there's this 
  perception out there--and a naive perception at that--that IETF thinks 
  that architecture is about all these hard edges you were talking 
  about. I mean, everybody sitting back here that I know doesn't believe 
  that.  It is about what Leslie was talking about, these building 
  blocks that we come up with that produce new things. To go to one of 
  Jonathan's comments, you know, e-mail was this big thing, except where 
  did that come from?  It came from file transfer. Right--it was FTP and 
  this was a new way to add on the top of the buildings block of FTP to 
  transfer messages around. That's what we do, is build these underlying 
  architectures and they go all the way from the bottom of networking 
  all the way up to applications, but they're not about the routers and 
  applications themselves. The architecture overlays that, and underlays 
  that, for that matter. The other thing, thinking that the DTD problem 
  was an architectural problem at all. It's a deployment problem and a 
  protocol problem. We may not have specified something tightly enough, 
  or maybe people didn't implement it the way we specified it. But 
  architecturally thinking, we did the right thing. This is something 
  that can be cached, can be gotten from somewhere else. It's a great 
  architecture; lousy deployment and protocol.

  So I guess what I'm getting at is, we're doing architecture in a way 
  that you're just not seeing. The other thing I wanted to point out to 
  Leslie's talk is that it occurs to me that this web socket stuff and 
  all of the stuff that these application are now doing to kind of route 
  through HTTP, to get to each other, eventually--and we've seen lots of 
  examples of peer to peer applications that want to talk to each 
  other--we're going to have slightly different implementations that are 
  going to want to talk over this stuff, and just like we routed around 
  PSTN to be able to communicate, because they didn't want to give us 
  packets. They wanted circuits; we just did an overlay network. I think 
  architecturally speaking, we just overlay this, and we're going to be 
  back in the place of producing new protocols. So I think it's a very 
  short view to think that those building blocks that we're building are 
  going to be erased by APIs.  I think it is protocol that we're 
  eventually going to be building anyway.

Henry Thompson: I absolutely agree with the last point. With respect to 
  the points about my failure to understand what the IETF means by 
  architecture, I'm sure you're right.  But I think that simply endorses 
  my point. The reason that I put that slide up, which is that we don't 
  mean the same things by architecture in the two communities, and we 
  better fix that. Not that we should end up meaning the same thing, but 
  we should understand what each community means by it, so we don't 
  screw up in the way that I just did.

Jon Peterson: We're almost out of time here.

[Unknown Speaker]: I have a little comment and then I have a question.  
  First of all my comment. It's Monday, so my brain is Monday night 
  philosophy brain. So I'll talk from philosophy.  I think that for a 
  diversity, we need both a standard and you also need something which 
  is not a standard. So what is a standard? The standard is not just 
  organizational dictate or some Request For Comments or something. A 
  standard is something which is accepted by the mass of the users.
  So, something dictated by, or something in a document published by an 
  organization can become a standard. At the same time, something not 
  published but accepted by the public or users can be also a standard.  
  Now, there is a moral value. The organization generally publishes to 
  everybody, to the people who are in the closed door also. The more 
  lasting or more [inaudible] the people who are indoors, and their
  application or their method has been accepted by many other people, or 
  users are using it. For them to come out and publish that, so that 
  innovation can keep ongoing.  Okay. [Inaudible.] That was my 
  philosophical argument. But my question now to Jonathan: Will Skype 
  use IPv6?

[Laughter and applause.] 

Jonathan Rosenberg: What a way to end the plenary. It's on the road map.

[Laughter and applause.]

Jon Peterson: All right. Thank you very much.  Ladies and gentlemen, I 
  think we're now going to go to the full IAB on the stage; is that 
  correct? So would the Internet Architecture Board please join us. 
  Thanks to our panelists. 

[Applause.]

5.  IAB Open Microphone Session

Bernard Aboba: So we're now entering the open mic portion of the 
  plenary. There's a few minutes left, so we haven't consumed the whole 
  thing. And so if people would like to ask questions of the IAB, you 
  can get up to the mic and if I can distinguish you from people milling 
  around, I'll call on you.  Oh, yes, and of course introducing the 
  members of the IAB:

[The IAB is introduced:

 - Bernard Aboba, IAB Chair
 - Marcelo Bagnulo, outgoing 
 - Ross Callon, continuing
 - Alissa Cooper, incoming 
 - Spencer Dawkins, continuing
 - Lars Eggert, IRTF Chair (ex officio)
 - Joel Halpern, incoming
 - Russ Housley, IETF Chair
 - David Kessens, incoming
 - John Klensin, aka "John in the box," outgoing (via phone)
 - Olaf Kolkman, continuing 
 - Danny McPherson, continuing 
 - Jon Peterson, continuing
 - Andrei Robachevsky, continuing 
 - Dave Thaler, continuing
 - Hannes Tschofenig, continuing]

Bernard Aboba: Okay. So, do we have any questions? Got you all that 
  tired? We're keeping you from dinner, I guess.  Okay. Oh, Pete, thank 
  you. 

Pete Resnick: You guys should be fully prepared for this. And I'll do a 
  fill in for the rest. I'd like to start by saying, this problem is 
  pretty much solved, at least for the immediate and then we've got some 
  issues that we as the IETF need to discuss.  So, a few weeks back, I 
  got a weird e-mail from some fellow employee at Qualcomm--we'll 
  refrain from characterizing this person--who was all in a tizzy 
  because, 'What is the IETF doing, making these comments about next 
  generation 911 to the FCC?' and I said, 'The IETF isn't making such 
  comments, what are you talking about?' And he pointed me at the FCC 
  site and I downloaded what was in question, and I explained to the 
  person that no, if you read the document, it doesn't say that the IETF 
  is making this comment. As a matter of fact, it says that this is just 
  a discussion of IETF protocols, but, I then went to the IAB and to 
  Russ Housley, because the authors had listed their credentials from 
  the IETF.  Working group chairs, and one member of the IAB, and the 
  FCC listed it on their web site, unfortunately, as chairs of IETF 
  working groups submitted these comments.

  And I said, 'I can understand how both the FCC and the outside world 
  might be confused because you listed IETF credentials and it seemed as 
  if you were speaking for the IETF--and for the IAB for that matter.'  
  So, subsequently--and I do thank the folks up front--there was a re-
  submission saying, 'We're not talking for the IETF; we're not talking 
  for the IAB,' which is great. But it does bring up this issue of how 
  we use that IETF credential, and there was evidently some discussion 
  in the IAB and I'd like to hear about it, that people were back-and-
  forth about what the appropriate level of disclosure is, whether you 
  had to disclose your home affiliation, your employer.  In this 
  particular case, the employer was never disclosed of any of the people 
  involved, and whether that's a problem, and how exactly we go about 
  doing this.  So I wanted to open up the topic tonight. I think it 
  starts as an IAB question, and may even become a question of working 
  groups, maybe an IESG question too. But I'd at least like to hear what 
  the IAB has to say. And others, if you have comments on this.

Bernard Aboba:  I guess the first thing we should say, probably as we 
  answer you, is that we are not speaking for the entire IAB. So, if 
  there are members of the IAB that want to give their opinion, do we 
  have some?

Hannes Tschofenig: Yes, Olaf mentioned already earlier in his 
  presentation that we discussed your request, and an amended version of 
  the filing was sent to the FCC on that topic.  We didn't discuss the 
  content of the submission itself. Which, many of you might have run 
  into that situation as well.  You are working group chair, author of 
  the a document, you speak on something on a specific topic, and you 
  mention that you are the chair of that group. So does that mean that 
  you speak on behalf of the group, is the slide set on behalf of the 
  group? So we didn't discuss that aspect. But we did discuss on whether 
  that would be appropriate in that specific context. And it was seen as 
  potentially misleading to some people, specifically since there are 
  two types of recipients in some specific case. Of course in this 
  specific case, the FCC was the intended recipient of that message, and 
  there could be misunderstanding on the side of the FCC.  Of course, 
  other people may also read that document and they may also get a 
  different impression.  Whether they have, and they may have totally 
  different reasons why they could misinterpret. So, in this specific 
  case, it was the second case rather than the former. We have informed 
  the FCC about that submission, so to link these two documents in a way 
  or to make them aware that we had clarified that specific aspect and 
  not the body of the submission itself.  We haven't come up with 
  guidelines yet on that specific topic. Specifically what you raised is 
  sort of the company affiliation.  In many cases, in IETF we work as 
  individuals, or not always you need to state your company 
  affiliations. In the amended filing we included the small CV; how far 
  do you need to go on that CV, what is relevant to the context to a 
  avoid misunderstanding? What do you need to say about the IETF process 
  itself? People may misunderstand what the meaning or the status of 
  specific documents are.  So, it can sometimes be tricky, and we 
  haven't come up with those guidelines yet. But we are going to, or we 
  had started this discussion already and have not come to a conclusion 
  yet in which circumstances, which specific boiler plate would be 
  useful to add. 

Bernard Aboba: I know we have drafted Danny to help write a document 
  that will explain some of this. I don't know if you want to say 
  anything more, Danny? 

Danny McPherson: So, the only thing I would say, yes, Pete had a valid 
  point and people addressed that, and oftentimes, many of us that 
  participate in the IETF, don't follow the proper guidelines for who 
  they're speaking for and making it clear from that perspective. I 
  think to have an IETF document that explains that, some RFC or 
  something, to provide guidance in that area is going to be of value. 
  So it's something that a few of us said should probably happen, and 
  certainly it will be made available for the community for comment and 
  input as well. 

Russ Housley: I've certainly faced this particular problem myself, 
  especially when a reporter calls me up.  And you know, they want to 
  talk to the IETF Chair. They don't want to talk to Russ Housley.  And 
  so, it's important to try and convey to your audience when you're 
  speaking about something that has consensus and when you're speaking 
  about something that is your personal opinion.  Some listeners will 
  misinterpret on purpose. At the same time, when there is an 
  opportunity to take a written statement before the group that it's 
  going to represent and get comment, that's always the preferred thing. 
  And when that is not available, I always post it and say, this is what 
  I have said.

Pete Resnick: And just to ask you about a distinction there, you talked 
  about talking to reporters.  In this case, it was talking to a public 
  policy body. Generally speaking, we like the IAB to liaise with public 
  policy bodies, maybe even through the ISOC sometimes, but we certainly 
  don't discourage people or individuals from talking to public policy 
  bodies. Can you talk about the distinction there if you think there is 
  one?

Russ Housley: There's definitely is one, because when you're reaching 
  out to a regulatory body like that, you do have some time, I think, to 
  run the content by the body you're representing.

Spencer Dawkins: So I just wanted to say, on this, and I was one of the 
  many people on the IAB who was taking this seriously. I think everyone 
  was. We're talking about a complicated situation. I spend a small part 
  of my time as a leader in another SDO which was also preparing input 
  for this. And my initial concern--well, I had two initial concerns. 
  One is that I agree with Pete: that if anybody at IETF should look 
  clean on the way we do things, it should be the IAB and the IESG. So 
  I'm kind of clear about that. My other concern was that I didn't read 
  all the submissions, but I read the one from the other SDO. And they 
  were a lot less shy about this, than maybe even the initial filing--
  certainly the amended filing--and I don't want to, you know, this can 
  go two ways. One is that the IAB member says, 'Oh, but I'm speaking 
  only as a humble, you know, possibly misguided individual,' for all of 
  their comments, and everybody else being a lot more assertive than 
  that. And you know, I'm concerned about that. I'm slightly concerned 
  about the possibility that IAB guys may learn to make their comments 
  through other SDOs.  Many of us have sponsors that are members of the 
  other SDOs as well. So I'm not trying to--the IAB is hearing what I'm 
  saying now for the first time, so, I'm carefully not looking left. And 
  you know, Ross can go over the table at me, but everybody else--
  anyway. But like I say, having said that the group has not heard me 
  say this, these are the kinds of things that I'm thinking about.  I'm 
  just saying I'm thinking this is going to be important for us to do a 
  good job. I'm thinking it will be a complicated conversation. I'm 
  going to be excited if the community is able to look at what we say 
  and what we do and feel good about that.  Because I think that's, like 
  I say, I think those are the two critical things, is that we don't 
  over and don't under, so, recognizing that this is a balancing act, 
  rather than just you know, 'Don't ever do X,' whatever X is. Thank 
  you. 

Bernard Aboba: I'd like to call on Brian. 

Brian Rosen: I do hope, following up on what you said, Spencer, that you 
  don't overdo it. In this case, I think the comments were very 
  valuable. I think the FCC really should have heard those comments. I 
  think they were important. I don't want to stifle them. I want to 
  point out that they were in a small area, in which those particular 
  people had probably a lot more expertise than the collective IAB could 
  have been, although you have some and you could have directed your 
  comments to them. I do think guidelines would be great. I mean, I'm 
  certainly not opposed to having guidelines. But I would like chairs 
  and other people to be able to make those comment to say what their 
  affiliation is, with the appropriate disclaimers, and I think you have 
  to realize even with the appropriate disclaimers, people will do the 
  wrong thing, summarize the wrong way, and get the wrong effect. That's 
  just part of the business. You can't control the reporters or the guy 
  who wrote the summary for the FCC. It was a worthwhile comment. We 
  should do more of it, not less of it, but certainly, let's have 
  guidelines. Thank you.

Thomas Narten: Just a couple of things. One is, this is actually not a 
  new problem. If you go back to other instances, maybe not in this 
  particular sort of context, but the issue of people making statements 
  and the receiving end hearing something stronger than maybe they 
  should have said has been a problem when individuals go to the SDOs 
  and make statements. I suggest the principle here is pretty simple. 
  Don't mislead. If there's a possibility that your message is going to 
  be misinterpreted as coming from a body when it's not, then you're in 
  an area you don't want to go. Don't get wrapped up in process and 
  formalities. It's straightforward. A working group chair, why are you 
  putting your working group chair affiliation on a statement unless you 
  have the backing of the working group? You know, by adding titles, 
  you're trying to provide some sort of authority or more weight.  You 
  can only do that if you've really got the backing, is the principle.

Cullen Jennings: I think the FCC is a very nuanced organization and very 
  clearly understands the difference in a liaison from a company, versus 
  an individual statement from somebody who works with that company, and 
  understands the difference between something that came from a 
  standards organization versus something that came from people that had 
  certain roles inside of that standards organization.  I read this, and 
  I saw nothing misleading about it. It was very normal. I speak to 
  press, analysts, various policy-making bodies all the time. I'm sure 
  many of you speak at conferences. When you speak about what's 
  happening in the IETF, that's a big part of what we all do, is talk 
  about it and bring ideas into new places. Our role in the IETF is 
  constantly mentioned. Okay. And it doesn't mean that we're saying the 
  opinion of that body. It means that, so people can understand the 
  context of where we're coming from, and why we might know something 
  about a given topic, is why our role gets mentioned. I agree that we 
  should not mislead, but that's very different from not mentioning what 
  your role is. It would be misleading not to mention your role. I 
  understand that the statements may not be in line with what Qualcomm 
  put in, but I don't think they were put in, in the slightest, to be 
  misleading anybody about the IETF position.

Pete Resnick: I'll make two quick comments. First, remember that if you 
  go to the FCC web site and look at the list of documents--and this is 
  probably a clerk that did this--it's listed as, 'Author, Chairs of 
  these IETF Working Groups.' So, yes, I agree, and you know, as I 
  started out with this, I don't think there's any reason for us to cut 
  down on saying, 'Look, my knowledge comes from the fact that I'm a 
  chair of this working group," or that I've been on the IAB or whatever 
  it is, or that I'm, working in the IETF. But in these circumstances, 
  and in this one in particular, the title page of this document listed 
  the affiliations.  That's what the FCC picked up on, even if it was a 
  clerk, and that's what got displayed to the public in the comments.  
  The second point, and I stress this to the IAB and I will repeat it, 
  this has nothing to do with the content of this document. Zero to do 
  with the content. I am sure there are people at Qualcomm who are 
  distressed or otherwise at the document. I did my best to say, 'Tough 
  noogies, right, this is the opinion of some folks and they're not 
  writing for the IETF and as a matter of fact, if you read further into 
  the document, it actually says, these are our opinions as informed 
  by.' So this has nothing to do with content, and I think most folks 
  know that I have disagreed with my company at this mic more times than 
  can be said. This has nothing to do with the content of the particular 
  filing. This is very much about the perception that we leave if we're 
  not careful.

Thomas Roessler: I'm W3C liaison to the IETF.  One of the things we do 
  when we, for example, send out a call for participation for workshops, 
  is to actually try to get relevant IAB or IESG members on our program 
  committees. I've several times recently deleted IESG and IAB 
  affiliations from calls for participation out of concern that arises 
  out of this conversation. And I wanted to call that out, because, we 
  are asking IESG members and IAB members to be on those program 
  committees, because we want to send a signal that the IETF community 
  has a stake in this work. And because we think that this very direct, 
  very hands-on and very lightweight liaison work is really important. 
  Right now, a piece of this discussion leads to a level of caution 
  where we are not actually able to really talk about that anymore, and 
  I think that's a little bit counter-productive. So I think it is 
  important from the perspective of other organizations that work with 
  the IETF, to actually be able to talk about it, not just the formal 
  liaison channel, not just whatever formal calls occur, but also be 
  able to talk about the sort of lightweight liaising to try to have the 
  right people in the right place. And right now, we're taking the 
  public visibility of that away, and we have the respective IESG and 
  IAB listed as individuals. We value their contributions hugely, and 
  are glad we have them. But I think it's in the interest of those 
  organizations to actually be able to say, 'By the way, the IETF has a 
  stake here, and we're involving them.'

Hannes Tschofenig: I just want to provide a comment back to Thomas, who 
  previously said you have to be careful to make sure that the recipient 
  doesn't misunderstand. And I fully agree with you, so obviously, the 
  assessment of what to put in there, what to write there was done with 
  that in mind, and the document itself basically references the work 
  that was done, documents that were done in the ECRIT and GEOPRIV 
  working groups. However, in this specific case, what I learned from 
  this discussion--the discussion we had internally, and also with 
  Pete--was not only think about the recipient who you actually talk to, 
  but also think, there's often open conversation, in this specific 
  case, it shows up at FCC but it also shows up to others.  And those 
  others may also, whoever reads that, he may misinterpret. And, they 
  will. So whatever you do, even if you give a presentation at the 
  specific conference, you are introduced as the working group chair or 
  IAB member or IESG member, and you say something, somebody will find 
  some sort of reasons why that was not appropriate.  So you have to be 
  really careful. So, for example, at the workshop last weekend, we 
  particularly stressed what the differences are on the different 
  documents that we produced, what the current status of IETF documents 
  is, because not everybody in the room knows. So that doesn't help by 
  itself. So if somebody picks up the documents from our web page, then 
  they can be misled. That will be difficult to deal with unless we add 
  disclaimers all over the place.

Bernard Aboba: Since we're already a bit late and we're keeping from you 
  dinner, we're only going to take two more. So, Eric, then Dave.

Eric Rescorla: So, as we learned from Olaf's slides, the Internet ended 
  on February 3rd, I guess, but I can still get my videos of cats so I'm 
  feeling good about that. So I understand it will be ending over the 
  next six months or so. Can I get some predictions from the IAB of what 
  I should be noticing as I can no longer get IP addresses?

Olaf Kolkman: I don't have a crystal ball.

Eric Rescorla: Okay.

Olaf Kolkman: I didn't get your question.

Eric Rescorla: Sure my question is, can I get some people on record 
  about what I should be expecting as we can no longer get IP addresses? 

David Kessens: Well, I guess the answer is no.

Eric Rescorla:  Okay.  So I'll still be able to get my cat videos.

Olaf Kolkman: I don't want to push that off, but, obviously, you have an 
  IP address now, and you'll probably have an IP address in a couple of 
  years--an IPv4 address--which means that at least all your buddies in 
  this hall will also have an IP address, at least on the current 
  machines will be able to see your cats.

Eric Rescorla: So, I mean, my question seriously is, we're issuing press 
  releases that say we're running out of IPv4 addresses; everybody 
  switch to IPv6, like, yesterday. So I think if you're going to do 
  that, you should be prepared to go on record with some negative 
  consequences of this.

Olaf Kolkman: Sure. Costs. Increased costs. It will be very hard for the 
  next 3 billion people to get IP addresses. 

Joel Halpern: To put it differently, we know there are lots of costs 
  that are going up as a consequence of this. Exactly when they will go 
  up and by how much, no, we don't know. Things will get more 
  complicated. The Internet always just works, so we will keep working.  
  But it's going to get harder. It's going to get trickier, and it will 
  get more expensive for various players, particularly for service 
  providers first, but the pain will get spread out. Exactly how you 
  will feel the pain, you may not. But people are feeling pain already 
  and will feel more. But I sure as heck don't know how much or exactly 
  when. 

Russ Housley: I'd like to point out something that Olaf said to the 
  press on the 3rd of February, because I think he got it just right. 
  Basically, he said that there was no urgency; this will all be 
  unnoticed for weeks and weeks. But that right now the Internet is 
  serving 2 billion people and there's 6 billion people to planet. Let's 
  get everybody included. 

Olaf Kolkman: And that statement to the press is actually printed in the 
  IETF Journal as the IAB chair's column.

Danny McPherson: One other thing on this, is that in April, or May I 
  guess it is, there are RIRs that are going to be out of addresses to 
  hand out to their constituents, and people will have to react and have 
  plans. So awareness of that is certainly important for the community. 
  I think we've had many, many v6 discussions and v4 exhaustion 
  discussions, but increasing that awareness, and that people need to be 
  prepared, and that this is coming very soon is extremely important. 

Bernard Aboba: Yes, I would just like to say that, just over the last 
  few months, I've seen an enormous ramp-up of interest in IPv6. It's 
  just straight up. So, I think your cats are safe, but they may be 
  delivered over IPv6.  Dave?

Dave Crocker: I don't know whether this question should be to the whole 
  IAB or just to Jon and Hannes, and I apologize if I missed the 
  information. The plenary as I understood it was to raise some issues, 
  open some doors for future discussions and ways forward. Where is this 
  going to take place?

Jon Peterson: That's a fair question. I mean, I think we're looking at a 
  set of activities that are evolving organically under their own 
  initiative right now. And one of the reasons why we tried to up-level, 
  was to say we've got things like HYBI and this proposed RTCWEB; is 
  there a need to look at this architecturally? Is there a need to break 
  this down into building blocks and re-use and think about it that way? 
  So I mean, the real work obviously is going to be done in these 
  individual efforts as they emerge, and we believe there will be more, 
  and we believe there are security related topics here, and we know 
  from the initial scope of RTCWEB that there are topics in that scope 
  that it does not yet encompass.  Where we will intervene, if at all, 
  would probably be in something like the forum of Hannes's document 
  today, that's trying to give an overview. You wrote a very long and 
  considered review of it, in which you pointed out several things which 
  we all acknowledge are defects in the initial document. And it's a -00 
  document, it's not yet an IAB work item. And we'd be refining it based 
  on the reflections that we got here and obviously, the continuing 
  state of that work going forward.  Would that ever result in a working 
  group specifically on these architectures and building blocks? I 
  wouldn't rule that out. That would be for somebody to propose in the 
  Apps Area if they wanted to. But if we continue to work for it, it 
  would be probably take the form a successor to Hannes's document that 
  would hopefully be better this time.

Dave Crocker: So if I understood you correctly, there are working groups 
  that are going to do specific things as they do, and with respect to 
  the higher-level issues, the only vehicle right now is a document that 
  you will take input into as you wish, and modify as you wish and get 
  more feedback. But there won't be a community discussion platform?

Jon Peterson: I'm certainly not trying to suggest that anyone in the 
  community cannot submit an internet-draft on the subject--

Dave Crocker: That's not what I said. I'm talking about a discussion. 
  Discussion forum, not a pronouncement form. Documents are 
  pronouncements.  And they're useful, but they're not discussion.

Jon Peterson: I understand. I mean, I'm just saying, if you, Dave, feel 
  that you have a scope for that kind of discussion that would be 
  profitable for us all to participate in, again, I would recommend you 
  to use the process to get a BOF started and we'll join the mailing 
  list and participate.

Dave Crocker: I'm not the one that opened the topic up. You guys are.

Bernard Aboba: I suggest a non-working group mailing list to discuss it.

Jon Peterson: Sure, we can do that.

Bernard Aboba: Any other questions? I think there was one person 
  remaining at the mic? Okay. So, I think we're done for the evening, 
  and you guys can go off and have dinner. Thank you.

[Applause.]

[The plenary adjourned at 1950 local time.]