IETF 82 Technical Plenary Taipei, Taiwan Monday, 14 November 2011 SESSION AGENDA 1. Welcome - Bernard Aboba 2. IRTF Chair's Report - Lars Eggert 3. RSOC Report - Fred Baker 4. IAB Chair's Report - Bernard Aboba 5. Technical Session: "Interconnecting Smart Objects with the Internet" - Introduction - Hannes Tschofenig - Smart Objects Workshop Report - Jari Arkko - Panel (moderated by Hannes Tschofenig) + Fred Baker + Robert Assimiti + Zach Shelby + Carsten Bormann 6. IAB Open Microphone Session MINUTES 1. Welcome - Bernard Aboba [See slides: "Agenda," http://www.ietf.org/proceedings/82/slides/plenaryt-0.ppt] BERNARD ABOBA: Welcome to the IETF 82 technical plenary. I'd like to advise you of the Note Well, which you've seen many times: > 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: The agenda today is we will take a half an hour for preliminaries, providing you with a series of reports on the IRTF, the IAB, and the RSOC. Then, from 5:00 to 7:15, we'll talk about interconnecting smart objects with the internet, and Hannes will introduce and lead the panel discussion with Jari talking about the IAB smart object workshop report. From 7:15 to 7:30 we'll have the IAB open microphone discussion, and then we'll let you go to dinner. So, welcome to IETF 82 in Taipei. I'd now like to turn over the floor to the IRTF Chair, Lars Eggert, for his report. 2. IRTF Chair's Report - Lars Eggert [See slides: "IRTF Update," http://www.ietf.org/proceedings/82/slides/plenaryt-2.pdf] LARS EGGERT: Hi, my name is Lars Eggert; I chair the IRTF. This is a quick status update; the longer one will be at the IRTF Open Meeting later in the week. We have a much less busy agenda than normal. We have two Research Groups meeting; normally we have between six and eight. The groups meeting are the Host Identity Protocol Research Group (HIPRG) and the Scalable Adaptive Multicast Research Group (SAMRG). There's some other IRTF-related meetings during the week. I already mentioned the IRTF Open Meeting, which happens tomorrow at 1:00 PM. This is sort of our Area meeting, if you will, where we're going to have a discussion as the entire IRTF. On Thursday morning, we traditionally review one of the research groups with the IAB. This time we will be reviewing the Anti-Spam Research Group (ASRG). And then there are three side meetings organized by folks who want to propose new Research Groups. One is Cross-Stratum Optimization (CSO), one is Information-Centric Networking (ICN), and one is Learning Capable Communication Networks (LCCN). I'll send a pointer to when those meetings happen to the IRTF-discuss list [http://www.ietf.org/mail-archive/web/irtf-discuss/]. Quick status of what's going on: This is my personal take of where we are in the activities. Roughly two-thirds of the Research Groups are active. We have a new Research Group, the Network Complexity Research Group (NCRG), that we chartered after the last IETF. They're not meeting this week, but Michael Behringer and Geoff Huston say that they are going to meet in Paris. So if that topic is interesting to you, keep that in mind going forward for IETF 83. Four of the Research Groups have little activity; many of them are currently discussing whether to recharter or whether they close. We did close one Research Group since the last meeting. The Transport Modeling Research Group (TMRG) spun out of the Internet Congestion Control Research Group (ICCRG) a while ago, and the chairs decided since there is only one item left that they're working on, it makes sense to simply eliminate the overhead and merge them back into the ICCRG to wrap that up. Our [document] stream is rather small compared to the IRTF. We had a big burst just before the last IETF. The DTNRG published lots of documents, but we've had zero document published since then. There are two or three with the RFC Editor at the moment, so you'll see a bump there in Paris. And then, finally the Applied Networking Research Prize. This is something we're doing together with the Internet Society, who is graciously providing support for this. This is the second time we're handing these prizes out. Basically, the intent is to award academic researchers this prize for recently-published applied networking research results that we believe are interesting to discuss here, and it may be to influence IETF or IRTF work. We had 13 nominations this time. We had a selection committee of IRTF and IETF members, and if you go to the URL [http://irtf.org/anrp], you can see who the folks are. We have two prize winners. That's a coincidence; we had two last time and we have two this time. We are handing them out as they are deserved--we are not limited to two. We might not hand out two always. Michio Honda and Nasif Ekiz are getting the two prizes this time, and they're going to talk during the Open Meeting tomorrow. Last time, both of the talks were routing related. This time both of the talks are TCP talks. So if that interests you, attend that meeting. And that's it. Any questions? [No.] Thank you. BERNARD ABOBA: Now I'd like to invite Fred Baker, the chair of the RSOC. 3. RSOC Report - Fred Baker [See slides: "RSOC Plenary," http://www.ietf.org/proceedings/82/slides/plenaryt-9.pptx] FRED BAKER: Thank you. So, reporting on our status, we started the process of looking for an RFC Series Editor (RSE) at IETF 80 in Prague, and we've been busily hunting and talked actually with 36 people. We are down to just a few of candidates left. I won't say how many, but those candidates are in fact here [in Taipei]. We expect to make a selection and recommend that to the IAB this week, and then the IAB will start deliberating and eventually white smoke will come out. So that's where we stand. 4. IAB Chair's Report - Bernard Aboba [See slides: "IAB Report," http://www.ietf.org/proceedings/82/slides/plenaryt-1.ppt] BERNARD ABOBA: An update on recent IPv6 issues in the news. [Shows slide 2 of http://www.ietf.org/proceedings/82/slides/plenaryt-1.ppt.] Thank you, Jari, for capturing the essence of the recent Occupy IPv4 demonstrations for posterity. About the IAB: The charter is in RFC 2850. We have a nice new website (thanks to Olaf and NLnet Labs) that lists all the Programs and Initiatives. (And all this material [i.e., slides] is online on the meeting materials site.) And we have up-to-date minutes, thanks to Cindy Morgan. IAB responsibilities listed in 2850: - IESG Appointment - Architectural Oversight - Standards Process Oversight and Appeal - RFC Series and IANA (and Fred has given you an update on the RFC Series) - ISOC Liaison - External Liaison Here are a few of the recent IAB activities on the website: [http://www.iab.org/]. I'm not going to go over all of these, but if you download the presentation, you can click on them. We've had a bunch of activities relating to documents. We put out a Call for Comment on "Architectural Considerations of IP Anycast." We appointed some liaisons; Call for Comment on the Independent Submission Editor Model, as well as the RFC Editor Model v2. We recently adopted a draft on privacy considerations. We appointed Joel Halpern as liaison to the IESG, and we sent a letter to the European Commission on global interoperability and emergency services. So you can look through these and get a sense of what the IAB has been up to. In terms of document status, we are working on a bunch of things. We have recently approved the privacy workshop document, so that's in the RFC Editor Queue. We have a Call for Approval on the Smart Object workshop document, which we'll be talking about at this plenary. And we have a Call for Comment on a bunch of other things, including the RFC Editor. And we have a document in Call for Comments which is the ISE model, and we have a bunch of work items. We had no appeals. With respect to the ICANN liaison, there are several updates. We appointed Peter Koch as liaison to the Root Server System Advisory Committee (RSSAC). We re-appointed Thomas Narten as IETF liaison to the ICANN Board of Directors, and we appointed Ole Jacobsen as the IETF representative for the 2012 ICANN NomCom. I would like to thank the outgoing RSSAC liaison, Rob Austein for his service to the community. We've also appointed a new IESG liaison, Joel Halpern, who replaces the previous liaison, Hannes Tschofenig. Thank you Hannes. We've had a discussion with the IESG about the appropriate role of Area Directors as liaison managers. [http://www.iab.org/2011/07/25/iab-responds-to-some-iesg-thoughts-on-liaisons/]. The article includes links to the IESG's thoughts on liaisons, as well as the IAB response. At IETF 82 the IAB and IESG had a discussion of the IAB role in new work, and Spencer Dawkins will be developing a statement relating to that. I won't present all the Program Report slides since we'd like to provide more time for the plenary. However, you can download the IAB Report from the materials management site. The remainder of the slide set provides a report on the activities of IAB Programs and Initiatives, including the Privacy Program, Internationalization Program, RFC Editor Program (also covered in Fred's RSOC Report), IANA Evolution Program, ITU-T Coordination Program and Liaison Oversight Program. In terms of recent developments within the IANA Evolution Program, on Thursday, November 10, NTIA issued the RFP/SoW for the IANA function, and a link to that is provided. [https://www.fbo.gov/index?s=opportunity&mode=form&tab=core&id=e134b8a2ede4f7901dceb5ce855f0062&_cview=0]. Initiatives are the shorter term activities of the IAB; these include the DNS, HTTP/Web, IP Evolution and IPv6 for Business Initiatives, as well as a proposed Emergency Services Initiative which is currently under review. We will have our open mic session at the end where you ask questions about the IAB and recent activities. I'll now turn the microphone Hannes, who will introduce the technical plenary topic. Any questions? 5. Technical Session: "Interconnecting Smart Objects with the Internet" - Introduction - Hannes Tschofenig [See slides: "Smart Object Introduction," http://www.ietf.org/proceedings/82/slides/plenaryt-3.pptx] HANNES TSCHOFENIG: My name is Hannes Tschofenig, and I'm here today to moderate the discussion about interconnecting smart objects with the Internet. I have gotten a couple of IETF participants to talk about that topic and to share their views with you, and then to use that as a discussion trigger to get your input on the topic of what the IETF should be doing, or what we shouldn't be doing. So, how did we actually come up with this topic to begin with? Choosing a topic for the IAB technical plenary is always difficult, because you guys are working in a various different layers in the protocol stacks, so your interest is spread all over the place. So, this specific topic goes through the entire protocol stack. There were some IETF activities ongoing already, and I included three working groups [ROLL, 6LoWPAN, CORE] here that are now working on this problem area. We will hear about those efforts a little later. Earlier this year, in March, the IAB together with the Internet Area organized a workshop. Some of you have attended either the workshop or the tutorial. Bernard already mentioned the workshop report, which you can take a look at and hopefully give some feedback. To the members on the panel here, Jari is going to give a presentation on the workshop, with some additional thoughts on what the tussles are in that specific space. Jari is one of the Internet Area Directors, as many of you know. Fred has written one RFC that is quite inspiring and relevant for this type of work, namely RFC 6272, "Internet Protocols for the Smart Grid." We had discussions earlier about the smart grid and its relationship to IETF work in past meetings, and he will touch on that aspect. Fred has had many different roles [in the IETF] and I wouldn't even try to describe them all. Robert is active in the industrial automation space and has contributed to different working groups in that space, so he will look into what are some of the requirements, like what does the landscape there look like? For those communities, the IP protocol and some of the work they're doing is fairly new, so he will touch on those. Zach is active in a few of those groups, in 6LOWPAN and in CORE, and he has written a couple of RFCs, and is also co-authoring a book on the topic. Carsten is the co-chair of 6LOWPAN and CORE and has a strong background in another area, namely Voice over IP. So some of you who work in the RAI Area should already know him. Before I let the others provide you with some content, one remark on what the scope of the topic is. In case you have never looked into any of those groups or you haven't looked at the workshop report either, then what is a smart object? And that's a difficult question, to come up with a precise definition. Specifically, since things have always been running IP. So there's nothing new there. But now, over the last couple of years, we have been trying to scale down to very small devices, and I borrowed one [Hannes showing an Arduino to the audience] from guys at the hacking event on Sunday. This is one of those small objects, and Jari has even smaller ones here [Hannes showing Jari's Mbed device to the audience). It's a part that's used by many developers in the community for experiments. We also tried to scale up to a large number of small devices in networks, so not only the device aspect but also the network aspect fits in there as well. The typical constraints you see with those devices are related to energy consumption; the small amount of bandwidth and limited amount of memory, both on main memory as well as memory on a flash card. Carsten will provide more details on some of those classifications, and the implications of those. And a few remarks: We were thinking about going through all the presentations, and they should give you some food for thought. Then we'll have a quick round of questions through the panel, and then hopefully, you will also share your thoughts with us and ask questions to the panel members or raise some open issues or give us your experience in that topic. For the mics, if you use the mics in the front for new questions, and if it's something related to something said in ongoing discussion, please use the mics in the back so it makes it easier for me to manage the discussion. - Smart Objects Workshop Report - Jari Arkko JARI ARKKO: [See slides: "Overview (Arkko)," http://www.ietf.org/proceedings/82/slides/plenaryt-4.pdf] - Panel (moderated by Hannes Tschofenig) CARSTEN BORMANN: [See slides: "Panel (Bormann)," http://www.ietf.org/proceedings/82/slides/plenaryt-7.ppt] FRED BAKER: [See slides: "Panel (Baker)," http://www.ietf.org/proceedings/82/slides/plenaryt-6.pptx] ROBERT ASSIMITI: [See slides: "Panel (Assimiti)," http://www.ietf.org/proceedings/82/slides/plenaryt-5.pptx] ZACH SHELBY: [See slides: "Panel (Shelby)," http://www.ietf.org/proceedings/82/slides/plenaryt-8.ppt] HANNES TSCHOFENIG: We have finished now the first part of the plenary with the presentations, and those should have given you some ideas on the space and also some of the challenges. Now I would like to turn over to questions from the audience, and while some of you go to the microphone, I will start with a first question to our panelists. As you may have recognized, our speakers obviously don't have a lined- up perspective on this topic. When it comes to what the IETF should be doing, we had Zach Shelby in his presentation arguing that we should develop building blocks and then let others, developers as well as other organizations, work out the whole architecture and get everything to work in an interoperable way. Jari, with his example of sensors and sleeping nodes was arguing for at least having an architectural description of the communication model which involves more than one initial building block to work. So what's the right approach? Should we do both, or should we do either/or? JARI ARKKO: Yes, I enjoyed Zach's presentation very much, and I agree with almost everything you said, but I have to say that the part about SDOs and how the IETF feeds material to SDOs--that gets me a little bit depressed. The reason is that, I think we should actually feed our results not just through SDOs, but also to developers like yourself who actually work in the space and can build the stuff. You guys know how to do this, and you will run into the practical problems. Without understanding of those practical problems, you can't actually detect that you have some issue with the COAP thing, and you have to go and fix that. So if you're just producing these small pieces and somebody else is putting them together, I don't think that's going to work. We do need the system-level expertise; that's my opinion. FRED BAKER: I really am bothered by the model that says we produce building blocks and other SDOs then produce architectures, and on two scores. One of them is that the term SDOs is plural. If you said you wanted one, and it would be interoperable everywhere, then plural doesn't help. So, I think we wind up needing to--and this is the other half of it--I think we need to understand our own architecture, use it effectively, and make sure that it meets the needs of those other SDOs. Now, if they want to tweak it in some way that they understand is specific to themselves, then fine. I understand that perfectly well. But, if you want to have things common and interoperable, having too many cooks in the kitchen really does spoil the soup. ZACH SHELBY: Yes, I'll actually respond first to Fred's observation about building blocks and architecture. Actually, the point of my slides was to actually say that we do have a great architecture at the IETF, and that's the web. But I think we actually have to go to the application layer and really just talk about that. But I think we have to go beyond that even, and provide building blocks with mechanisms and how to use that web architecture. Discovery, directories, et cetera. Because just the architecture alone isn't going to be enough. We have to go further. FRED BAKER: So, what I was getting at is that the web is an application, not an architecture. But the Internet architecture has several layers and actually has a variety of applications that build on it. If I was to go redesign firewall traversal at this point, I would probably find myself thinking in terms of delay-tolerant networks and building on a model that supports e-mail. I would approach something actually quite a bit different. It would be well within the Internet architecture, but it might not be exactly what you call the web. ZACH SHELBY: Now the second thing I wanted to bring up is that I disagree with Jari strongly on his claim that we need to solve, for example, every sleeping node problem with a web transfer protocol. The web transfer protocol is not a design pattern necessarily. I think there's different levels we should solve the problems at. Yes, we need a web transfer protocol. You can have any kind of design interaction you can imagine with that. Some of them will work great with sleeping nodes and some of them won't. But in addition to that, we might want a device, different design patterns, that we advise people that this is a great pattern to use. Why separate those two things? Maybe it's an IETF sleeping node issue. HANNES TSCHOFENIG: So what Jari calls a protocol specification, a profile, where he puts a couple of things together, you would call that advice. So in some sense, you probably all agree, you just call it different. But let us switch over, because I see the mic lines. BARRY LEIBA: Robert talked about a goal of eliminating middleboxes, and I would like to have the whole panel talk about what the design trade- offs are and what we learned or have not learned from other attempts to use middleboxes for things like this. JARI ARKKO: So, I think it's a good thing. I know what Robert means when he says he wants to eliminate middleboxes, and I think it's those nasty ones where you have to translate pretty much everything. But I think there are some useful middleboxes as well. If we go with this web model, for instance, having a network where your request has some nodes that stores sensor measurements, like I had that in my network--I think that's a good thing. The end-to-end model of going all the way towards the user of the information is not the only way to do this. Sometimes you do need storage service. CARSTEN BORMANN: Yes, I think the interesting thing here is what are protocols and what are dangers? Middleboxes usually do things that are very specific to some kind of application, so when you invent a new application the middlebox gets in the way. That's really the amount of pain we have. When we design middleboxes for architecture, we want to make sure they carry data for different applications without necessarily understanding all the details. HANNES TSCHOFENIG: So, like we did in SIP? [Laughter] HANNES TSCHOFENIG: A joke. IETFer: My name is [inaudible]. I have to say all the presentation are quite interesting, thank you very much. I have a question to Jari and Zach: do you really believe that all the smart objects will have IP addresses in the future? And also we talked a lot about constrained devices for the smart objects, but we forget the one point that some of the smart objects may be really intelligent and smart. How about the current devices that have strong capability and also the current investment, not only on IP transport? So shall we consider something else? Maybe some other organization has already started discussions about profiling existing technology to use, together with IETF technologies. So maybe not from the IETF? JARI ARKKO: So, I have a lot of experience with that personally, because I have been running non-IP networks and gatewaying them towards the Internet and connecting them to all kinds of applications. And that works too. I know a lot of the world is coming from that angle today, so we have to live with that. There's no way around that. That being said, I do like the IP model. Right now, I'm converting my network to run on IP and IPv6 because currently, maybe I'm using the same wires, but I have very special hubs and switches and protocols. I don't have the same tools; I can't do a TCPdump on the non-IP things, for instance, and I can't use just one ethernet switch to connect all of this and manage the VLANs and all that. So it's a big benefit for me personally. I believe the same thing would apply for the large commercial buildings. They only have one networking technology, and they can do everything with that. The commercial benefits are there. We will get there. Obviously, we're not there today, but we will get there. And yes, we will see some interconnections between these different types of things, but I think we are at the stage in the world where we are ready to say, pretty much everything new has to be on IP; otherwise, it doesn't make sense. ROBERT ASSIMITI: I think IPv6 connectivity is a mandatory prerequisite to even qualify as a smart object. We've seen so many proprietary technologies for the last ten years or so, and I don't think at this point anybody in their right mind can argue that IPv6 is not the way to go for constrained devices. I think that's pretty much been adopted by most standards bodies, hopefully. So even the ones that I projected up on the screen earlier: we're talking about process automation. The ones that have not adopted IPv6 are currently revising the standards. They're going back and introducing IPv6. A good example of that's Zigbee [http://www.zigbee.org/]. Zigbee went through the same evolutionary path. A few years ago, they said no to IP, but now due to pushes from Smart Grid--them being feasible in the home area network--they have to go back and revise standards and introduce IPv6 connectivity. FRED BAKER: Now, coming at this from the perspective of the chair of IPv6 Operations, and therefore proponent of IPv6, I note that some of the very popular and widely-used building automation protocols are in fact Pub/Sub and that the ICN architecture has some of those characteristics, and [it] doesn't necessarily depend on addresses; it depends on data content. So, yes, I think IPv6 is pretty important, but to say that it's the only way to do things, I think, is a little narrow. JEFF HODGES: So this is all very interesting, but I guess I'm curious about what the IAB might think about this? HANNES TSCHOFENIG: Yes, in the IAB, we had talked about whether we should work out a position statement on that document. We have tried to do that and didn't finish in time. But look around in some of the documents that we have produced so far, and a couple of speakers have already mentioned that we have lots of different building blocks, and of course lots of architectural documents as well. Many working groups produced those, so we essentially have both. Like if you think of more recent developments, like WebRTC, mostly about documenting architectural aspects for the specific real-time web. We also have, as some of the speakers had asked for, guidance for various different communities: lots of guidance for those of you who work in IETF on security, privacy, internationalization, management. Not so much guidance when it comes to broader aspects, not for one specific protocol or how to extend it; but broader guidance for those using our technology in the way that Carsten and Fred have mentioned. That's probably an area this where one needs to spend some additional thoughts on, and it will be topic-dependent, if you look at some of the things that Jari mentioned regarding security. So what specific guidance would you give people in designing a security solution? Fred has a couple of paragraphs in his documents. But what do you have to say more about those constrained devices when you have security protocols at all layers in the stack. So we'll hopefully come up with some write-up that we can share with the community, but nothing is ready yet at this point in time. CHARLIE PERKINS: I saw in Jari's presentation that he believes that a spoke architecture would be sufficient. And I found that to be very surprising, because a lot of the sensor applications really all seem to be multi-hop. And then, in the Robert's presentation, I saw that the three organizations that are vying for world domination all believe in mesh-under, and yet the feeling in the IAB workshop was that really, route-over is preferable. I was wondering, how can it be that the more industrial organizations are all believing in mesh-under as opposed to route-over? Finally, I was very curious why during none of the presentations was mobility mentioned. I think smart objects may be mobile. And I was also wondering whether it's typically larger modular construction of IETF protocols would be in addition because of packet size? JARI ARKKO: I did not mean to say we don't need the multi-hop. But if you have a situation where one hop is enough, I actually prefer that because it's so much simpler. And some practical things as well. As an example, I have a weight scale from a friend's company that runs on wireless LAN, and it just works on the regular architecture. I don't need multi-hop in that case. But of course there are situations where you do need that, so I support that model for those situations. The only comment was, don't put it where it's not absolutely needed. ROBERT ASSIMITI: I don't think it's a matter of belief that mesh-under is the right way to go. It's just that until about six months ago, most of the people in these organizations didn't understand the difference between mesh-under and route-over. So mesh-under became the de facto running methodology because it was the old way of sneaking in somewhat proprietary solutions into these protocols. CHARLIE PERKINS: So you're saying that mesh-under is more amenable to proprietary solutions than route-over? ROBET ASSIMITI: Right. So I think that in the evolutionary path of wireless sensor networks, all proprietary solutions follow the mesh- under paradigm, and we see that it involves a lot of standards in the market today. And as I said earlier, when ISA100.11a was architected, RPL was not around. So we just started learning about mesh-under and route-over months ago. If you talk to most people in this industry, they have a hard time discerning between mesh-under and route-over. CHARLIE PERKINS: Thank you. Any thoughts about mobility? FRED BAKER: In bringing up the car manufacturers, I certainly was bringing up the instance of mobility. One solution to that would be usable mobile IP. It's not the only possible solution, but it's one. Coming back to the mesh-under and route-over, frankly, I think that particular argument looms much larger than it should. Both of them are talking about some variation of routing. The question is, how does that relate to the IP protocol? Is there a place for something underneath? And I don't buy the argument that mesh-under makes something proprietary or makes it easier to be proprietary. As far as the IP architecture is concerned, 802.11 is a mesh-under protocol. It just happens to be routing at a layer below IP. And that's the standard. So, it's doable. The question is, do you choose to do it that way? ZACH SHELBY: I'll address the mobility questions. If you think about what we're doing at the application layer with the web architecture, you know, we don't really care. I think our design assumption is that IP addresses are not going to be the same, they are going to change. We're not even going to attempt to keep the same IPv6 address with mobility. And I think that's part of the reason why I didn't mention it. We tend to design these systems in a way that we can deal with that. LIU HONG: I think the problem of the internet of things is that it is a huge market, but it consists of a large number of markets that are relatively small. For example, the smart house and smart grid are two different models, and if I agree with the vision of one Internet for all of those smart objects, but if we are going to support all these applications--all these verticals, all these protocols--with one set of optimized protocols, I assume that set of protocol needs to support different profiles so that it can work with different applications, since they have different requirements. One may not be sensible to the battery life, and the other may be sensible for the delay or packet loss, like mobile house. CARSTEN BORMANN: In the Internet we have a lot of areas where we have different requirements. So the server that is sitting at my university and has different requirements from the network in front of me. But we happen to be able to define scalable protocols that can cover a range of requirements, because there are some requirements that are just out there and cannot be covered by the same kind of protocol. But generally, I would think that, when we can come up with something that is scalable for a range of applications, we should try to do that. KERRY LYNN: As Zach said, I think those of us who are trying to build things like this are finding that the engineering challenges are pretty significant. It's like building a spacecraft. You have a fundamental constraint which is weight and everything else is driven by that. So this is the general question for the panel: Is it even correct to think about these systems as building blocks, like bricks that are stuck together with mortar? It seems to me that it's very difficult to make a decision in one area without considering the impacts on adjacent areas. So I guess my general question for the panel would be: do you feel that the way that we are organized now as a body, where we've got people who focus on security, other people who focus on other elements, is sufficient? It seems to me that we need almost another level of documentation to help people with the deployment, because we many times lose a lot of the rationale when we produce work products like RFCs and so forth. It just seems like it would be very difficult for folks to pick up a bunch of RFCs and understand how to put together one of these systems. Comments? JARI ARKKO: That is an issue. One answer to that might be that we rely on people like Zach who go to all of the working groups to get it all aligned, and that may be joking a little bit, but that's actually how we work. It's not that we send liaison statements or organize ourselves in different ways; we actually have the same people doing work over there and over here. I think some of that has to happen for this. And I would say most of the people who work in this space do go to many of these working groups, even across areas. So I think it's happening in some natural fashion. We don't have a lot of documentation about it. Maybe we should. But I think people are trying to pay attention. ZACH SHELBY: You know how they have these LEGO building sets, you have the jungle cars that has the pieces that all come together. I think those are the kinds of building blocks we need. Sets of building blocks, maybe for different market segments. I have no idea how we should do that in the IETF. In practice, that's what we need. FRED BAKER: Well, we do that to some extent. We run ethernet over IP, or IP over ethernet. We even have RFCs saying not to do that. IETFer: I'm a bit concerned about this attitude. Even the SDO is missing the beautiful building blocks of the good SDO. So, first of all, I think it's largely the same companies in most SDOs anyway. Second, take the example in Fred's presentation about the car manufacturer. There seems to be a pressing need to name those devices uniquely. And so they are using something for that which we know is wrong. So perhaps there is no better solution for them. I think we need to work on that and help those guys. Second, I think it's just not sufficient to really maintain this view of, say, our IETF technologies only. You need to understand also the economic factors. I mean, we know that in the internet of things, the machine is not only a billion devices, it's also a billion dollars, and so that also explains that people that are building platforms need to inter-operate. I think those factors need to be taken into consideration when doing the technical work. CARSTEN BORMANN: So, the evil SDOs over there--this is about the evil people in the same company. But, in reality, where we have success getting our technology accepted and integrated by another SDO always has been through people. They haven't been through documents that we send around. And while I believe it's a good idea to document things so we can give these documents to students so they can learn the stuff, the actual progress is done by people who work in these different spaces. So it is not that important whether they are in the same company. It's much more important that the same person who understands the technology that's emerging here in the IETF also understands the technology that's emerging in other SDOs and is in a position to bring these things together. The economic aspect of course is interesting. Sometimes, it's a question whether you standardize things in a way that favors one economic community and takes away from another economic community, or whether you try to build things in a way that provides the largest amount of choice and largest number of possibilities. I think we are pretty much on that side, and sometimes, that brings us into a losing position, because the industry forces really want to make money and succeed. ZACH SHELBY: I want to mention on the SDO thing that actually the reason I had all those SDOs on my slide is that those are the good guys. Those are the guys that are going to bring IP smart object technology to market. And I think Carsten answered my question marks. It might be the question marks of that double arrow might be people. We need to encourage people to participate in both of those, and that might be the way we make this succeed. CULLEN JENNINGS: I'm going to ask a question about which other SDOs we should be working with, because I've seen a long list. But, before I ask that question, let me go back 10-15 years ago when we were starting to get into the unified communication space. We had a very clear vision of the type of communications we wanted to enable. But at the same time, many of us believed there was no way we could possibly be successful in achieving that goal unless we can get the full buy-in of a system architecture that was going to ship on many billions of mobile phones. So we decided to build tools and partner carefully with 3GPP to go and build a system architecture and at the same time be able to re-purpose the tools and weapons that were built in that for other purposes. Now, you can argue, but I think from both sides that's viewed as a large success, right? I think 3GPP views IMS as a success and I view the re-purposing of those tools as a success. The question, though, is that we had to very carefully identify which SDOs we were going to put that level of effort into working with. It was incredibly painful; it took so many people going back and forth. And same thing, there were 20-30 SDOs that wanted to be in that space. But we focused on which was the one or two that we could put that level of energy into collaborating with, and it took far more energy than anyone thought. So my question for you guys is which are the SDOs that we cannot possibly--I think we're at the phase of we have a vision of where we'd like this to go. Which are the SDOs we positively have to have that very high level of partnership with, or we're going to fail in this space? I would love to hear from the panel or people in the room. FRED BAKER: I don't think it's limited to one SDO. I think it is plural. One of them will be the IEEE. IETFer: I just want to jump in here. People are always asking, so in the terms of opportunity that I see in the Chinese market, so I see more than 10 million machines, mobile terminals are using IP-based communication. So, they may not use same protocol here, but I really encourage you that we need more guidance from the IETF, to guide them to use the IPv6 IP solution for them for the future of the mobile market. That's very important. ZACH SHELBY: I'll actually make a comment on exactly that. There's something pretty big happening in the cellular industry, and that's something a little bit like what was happening with 3GPP. So there's a kind of end-to-end PP being formed right now which hopefully will put together ETSI and TIA and many others into one body that's easier to work with. That might be one answer. I would name one other, and I think that's Zigbee. Zigbee Alliance provides a pretty interesting opportunity for IETF, because they cover multiple market segments in one body, and it's mostly the same people. JARI ARKKO: I think the counter-question is, which of these SDOs are actually succeeding? A lot of the real business activity that I see in the world is mostly running on some link layer, which is defined through IP, and then run event protocols on top of that, and that just works. It can be deployed; no need for additional standardization. In some cases you get XML or other nice things. I'm drawn back to Cullen's analogy through IMS and 3GPP and all of that. It might also be the case that there are SDOs that developed a lot of system-level specifications, but in the real world action it's described and so forth. So developing the components and letting them take over the world might also be one answer. But I do think we need to work with the Zigbee Alliance and IEEE in particular. DAVE CROCKER: This has been an interesting mixture of presentations and perspectives. I wanted to focus on Carsten's talk because overall, the talks are about our helping an activity. I think the observations in Carsten's presentation, actually besides having that potential, have the potential of helping us do better work. The presentation had bullets with keyword references or terse references to some things that we need to think about doing differently. And for a presentation, they have to be in those bullets, things like less chatty and so on. The earlier days of this community's work, we had more constrained networks, and one of the things that I ended up noticing was that it was very straightforward and always successful to take a wide area network protocol, which had to deal with high latency and low bandwidth, and move it into a local area network. Every time we tried to take a LAN protocol, it failed because it was expecting high bandwidth and low latency and people wrote protocols according to that. Carsten's set of issues could cause us to start being far more disciplined in our use of the channels that we have than we currently are, because we've gotten fat and lazy. The catch is, I don't know how to take those key words and translate them into some kind of procedure or discipline that we can apply with some regularity to our protocol design work. And while I didn't phrase it that way, that's a question. I don't expect an answer now, but it's a direction of activity that I hope we can figure out how to pursue. IETFer: Carsten's presentation basically describes that Moore's Law has lost validity in this field and therefore we can always have this limited results and computing power gone. But for Robert, I saw you want to basically turn the application and all the capability all the way into the end. So to me, this is a conflict field. I want to understand what is about this opinion. Are we going to have more hierarchical architecture or are we trying to extend this application and everything all the way into the end? ROBERT ASSIMITI: Ideally I would like to see the application go all the way to the end but in reality, we'll end up with hierarchical systems. I think that's pretty much my answer on that. CARSTEN BORMANN: We have a very long history of coping with layers in our design. Software engineering during the '60s invented layering as a technique for generating separation of concern in the design. If you design a complex system, you want to chop it up into different parts, and layers are very good way to get the separation of concern. So when I started in the '70s, people thought we cannot really do open systems interconnection; that's way too much work. Let's carve it up into different layers. We are carrying around those layers in our heads, those layers that were defined in '78. We are talking about things that are L2, L3, L7 and so on. On the other hand, we have these wonderful Internet over IP over another IP, Internet over something else, architectures that show that layers maybe don't have the same meaning anymore that they had in 1978. I think sometimes we need to be creative and look at where do layers help us, and where is it useful to actually redefine layers, or combine layers. When we started designing COAP, we had the problem that there is no transport protocol that does very much that is useful for us. TCP is too complex. UDP doesn't do much. So, the obvious thing, if you come from an OSI thinking is, let's define another transport protocol and then we will put our application protocol on top. But it turned out it was much more useful for us to define a little hierarchy of two sub-protocols. The lower one probably does a lot of what is usually called transport and the other one does more of what is called application, without being bound to those layers. I think we can reinvent protocols without being bound by old thinking, but of course as with all architectural changes, there has to be a reason for doing that. And the reason in this case was there is no transport protocol available that would have solved that. JARI ARKKO: I actually do believe in the end-to-end model that devices will do interesting things, and that the constraints in code are not that relevant. I mean, the communication spending in its transmissions and listening--that's really crucial actually. I think they will see differences from the current models mostly because you have small things that don't have a user interface where you can actually configure something, so it will be a functional separation that you do certain things in this device and the rest you do in the server and that will probably affect some things. Also I wanted to make some comment that 250 K memory that Carsten was pointing, as a lowest class device, I think that's a horrible amount of space to add bloatware. ROBERT ASSIMITI: I would like to also add something. You saw throughout our presentations that we're dealing with different levels of constraints, right? Yes, there's computing problems you can solve. You can run on Moore's Law and they will be solved. But batteries, and physics, they don't follow Moore's Law. As long as batteries are not evolving proportionally with computing power, if you are trying to bring into this ecosystem a severely constrained device from a power supply point of view, you will have to deal with that. S. MOONESAMY: Are we using the web to create state? REST, JavaScript to solve a problem? ZACH SHELBY: I've experimented a lot. Practically, theoretically, in different standards, to use the web to make all kinds of small devices. And what I found to be most useful is to model small devices as collections of very simple web resources, REST resources that have a little bit of state controlled by the server and manipulate those resources. We're talking about things like /temperature where the payload is "22.3" in text/plain. Very simple thing. So that's the kind of model I think of when I talk about REST. There's more complex things, but I think if we follow the REST architecture, in doing that, we can take advantage of a lot of very nice things, like proxies in between where we can do caching, et cetera. S. MOONESAMY: So everything will go over port 80? ZACH SHELBY: I don't know if I make the connection between what I just said and port 80. I think some of this has to come down to discovery as well. We have to do a lot more work on discovering where web end- points are. They may be on all different kinds of ports, and I think it's a good thing. I don't think machine-to-machine should be as limited as we are on the web, with assuming that people are going to identify a web site by www.google.com. And thus, it must be on port 80 because that's the default. HANNES TSCHOFENIG: But some of the success from the web is not only because of the way the resources are managed; it's also because of other features it provides, like the JavaScript components. Obviously, those do not help a lot with caching and proxies and many of the real-time extensions that people work on here. But they have nevertheless helped to increase the speed of innovation considerably, as we discussed it at the March IETF plenary. So you [Zach] seem to focus on one aspect, but you haven't touched on any of the other aspects because you find them irrelevant, or because the they're not applicable? ZACH SHELBY: So I think they'll come. I think we have to move one step at a time. I know of people working on, for example, running JavaScript on little sensor nodes to make it easier to install new functionality on those nodes. But at this point, it's research sandbox type of work. Sensor networks people have been doing that for a long time. Again, mostly research, but it will come to the sensor space as well. JARI ARKKO: So I think we'll see JavaScript on other things like that. Probably not in the sensors themselves--I don't actually believe in that particular model--but the system as a whole, when you put everything together and how users control it and everything, we'll see different aspects of the web technology being used. PASCAL THUBERT: I'm reacting to Robert's slides on the grail that you define. When I look at it in the middle-term, it looks more like a goal that we really need to achieve, as opposed to a grail that is always forever too far away from us. You can ask many people, and you will get a hundred different definitions of what the Holy Grail is. There's one I find interesting from some work at ETSI and AFI. It's what they call automatic networks. Basically, the first step is you take the newborn device, you give it a name and now you throw it into the network. It has to discover that there is a network. How to join this network. It has to join the network, participate with the network and if possible, make the network operate better. If you can reach that, that's already a very nice grail. But, what I'm looking at is going further and that the device should also discover what the network is for. The device should discover how it can help the network do what it's for. And that's basically some trade-off between what the device is very good at doing, and what the network really needs to be done. MEHMET ERSUE: During the smart object workshop in Prague, we did not have sufficient time to discuss network management aspects. I think this is an interesting and important area, as IETF has not developed yet specific technologies for the management of constrained devices. I think this is something which also relates to the larger question of how to do software updates or how to do self-configuration of small devices. How do you think on this? Is it good enough if we use COAP for everything? Or what do you think IETF should be doing to address the problem space? JARI ARKKO: Yes, so, as you know, we did not have enough time. I think the next step on that is actually to organize some more time for ourselves to get into that discussion, and I think it will be interesting if we can get together a meeting, maybe around the next IETF or something like that. I think it's more complicated than just using COAP. It could be the transport protocol, but obviously there's more to it. ZACH SHELBY: Yes, I would agree, and I probably should have listed management and firmware update on that list of identity and discovery things, because they're extremely important and difficult problems. But it's not really just about COAP. It's about doing management over HTTP. It's doing management over COAP. Maybe using, hopefully, the same REST design. It's about using SNMP in all the places we can, and maybe it's about making abstract MIBs that can be used in all of those in the same way. So that might be a goal in the future. Could we have a way to make MIBs that we can use over everything and still make it efficient. MEHMET ERSUE: Actually we have already something better than SNMP using XML. CARSTEN BORMANN: We usually see nails, and we have these hammers which are called protocol designers. So if we have a new problem, we design a new protocol. But often, the problem really is one of data modeling. And it's nice to see that the management community has started working on advances in data modeling. I'm looking forward to ways to use this in our space. HANNES TSCHOFENIG: Maybe at the next IETF meeting we need to get together and discuss some of those network management, node management or software update mechanisms which actually come from fairly different communities, in some sense. I'm sure Dan and others are happy to socialize something. ALEX MAYRHOFER: I started to look at smart objects only the last IETF meeting in Quebec. However, I think that the work that's going on there is really valuable for the IETF and the whole community as an organizational perspective. Because what I started to see in the last couple of years is that protocols tend to get even more complex, and we are all drawn a little bit to feature creep. Which means that the constraints that we usually think about when we design new protocols are definitely completely different than they exist here. Sometimes I wish for the time back when an IP address was easy to remember, and I didn't need software to get the response from the DNS server and so on. I understand the time for that is over, but I think that all the approaches that you make in creating the protocols could be very valuable in our working groups as well. Because it looks like to me, that we have at least encryption, XML and whatever in protocol. So, it's actually more impressed to the other people here to look at the work and also consider that KISS is a nice principle and it could be applied to other things as well, which in turn would be help those protocols to be much more useful. CARSTEN BORMANN: Most of us agree, maybe with the exception of encryption, in your statement. It's really hard to get that. FRED BAKER: Yes, but we periodically hear about people who would like to have encryption in the application, and then can we have it in TCP and IPsec. Oh, did you know we need it in 802.11. Sometimes it gets a bit much. IETFer: From my understanding of what IETF is doing is designing some network protocols for the constrained devices. But considering the other end of the communication, they may use just HTTP, TCP and stuff. So we inevitably run into a situation that we have to place some intermediate box on the network to do proxying. So there is always another trend in the industry that what they are doing is that they are just using the fully capable IP stack and TCP HTTP, but they do some compression and payload compression. Anyway, in Jari's presentation, we see that communication is the key part for the constrained devices. And I don't know if you have also investigated these trends in the industry and how the IETF works with this, to act on that? JARI ARKKO: Well, certainly, introducing a new protocol that is more lightweight will also cause problems as then you need some way for those to interwork. In the case of COAP and HTTP, it's easy. I don't see a lot of practical problems there. The real-world deployments a lot of the time, like the weight scale I mentioned earlier--it does HTTP and whatever inside, mostly because that is currently to work in any network and go through any firewalls. It's like usual other application problems that you'll do what works. I agree with what you were saying about the power usage issues. Those graphs are basically pointing to a situation where you don't care so much how much code you have on your box, but you care how many bits you send. That means you implement compression so you can get down the number of bits and maybe you want to get rid of TCP and replace it with UDP so you don't have as many round trips. But the compression part is important. ZACH SHELBY: I just want to make a couple of short comments on that. So, A, especially on the web, intermediate boxes that were designed properly and used properly are not bad things; they actually can be very good things. All of you who are using the web today are using a lot more intermediate boxes than you know. This is something that's a little bit deceptive. You don't even know how many middleboxes you're going through. Secondly, I think in the Applications Area community we have to think of our protocols that we have as web transfer protocols as generic things and concentrate on designing REST patterns and principles that can work over both. That will make things a lot easier for people in the industry that sometimes they have a device that's HTTP and you say, "Hey, we have a design that works over there." And sometimes they have a constrained environment and they want to use COAP and I say, "Hey, the same design pattern works for that." That's something we should strive for. HANNES TSCHOFENIG: It's also fair to say there are problems. Nobody here at least had the intent to design middleboxes that prevent you from introducing new features at the end points. ZACH SHELBY: You do. It's called firewalls. HANNES TSCHOFENIG: We can argue about that. At least the IAB has a nice recommendation document--not yet finished, we are soliciting feedback--but it actually touches on that aspect and as you see, for example, we touched on the SIP aspect already, like making sure that these devices actually really do what they are supposed to be doing with regard to extensions, not to essentially block some future usage. You may have to think hard and actually check all these different extensibility mechanisms you have thought about. CARSTEN BORMANN: Traditionally we have been pretty bad at designing our protocols in a way that somebody who taps the wire can find out what's going on. Generally, it's a good thing if protocols are as self- describing as possible. Of course, you cannot send the whole context of the communication with every packet. But sometimes it's better to design a protocol, not as a set of incremental little steps that depend on lots of context, but design them in a way that you have relatively freestanding representations in the web architecture that are interchanged and where intermediaries can make reasonable decisions, instead of something that should be transmitted or not. So the whole design approach of making things transfer invisible, actionable for somebody who is sitting in the middle, I think that's important. DAVID CULLER: It's been interesting listening to this discussion here at the IETF. I guess it's about 15 years since this set of issues became a hot research topic more or less everywhere in the world. That's not a bad thing. Our job here is to codify existing practice, rather than to break new ground. But it does mean that most of the established wisdom is outside the IETF. So I think that if there's a single message here, it's read beyond the RFC. I would point to two documents. 1999 paper by Deborah Estrin [http://research.cens.ucla.edu/people/estrin/publications/] on 21st century networking challenges. Part of why that's nice is it lays out why it is that we have to abandon the IP architecture and so forth. Remember too, we talked about a hundred kilobytes. No, no. When we were at eight kilobytes a code and half a kilobyte of memory, then it was hard. The other would be Jonathan Hui's Ph.D. thesis, which walks through the entire aspect of the architecture. But there's a 2008 paper entitled "IP is dead, Long Live IP for Wireless Sensor Networks" [http://www.cs.berkeley.edu/~jwhui/pubs/jhui-sensys08-ipv6.pdf]. And what quite nice is that after another decade of changes, it really did make sense within the architecture, once we had the opportunity to explore the solution space without the constraints of architecture. But it does mean that a lot of the key pieces are what you don't do, not what you do. The discussion here is always exactly where do you put the bit and how about transmit? And going back to the 1999 paper, the idle listening problem dominates all. It's not a matter of what you send or what you receive, it's everything you do in between. But there's basically three different solutions to that. And it's too bad that 802.15.4 failed. But 802.15.4e finally did last week standardize on the three solutions. So, it is time to go, those are sample listening, scheduled listening and listening after send. So it is time to go do this and it's not that hard. But it does mean that we have to look beyond the IETF for most of the answers. CARSTEN BORMANN: I think one comment that David made is really requiring some amplification. Architecture is about leaving things out. I think that's a very important thing. So when we talk about architectural styles, it's really a set of constraints on what you can do in your system. With this engineering thinking, I can do more and more and more. And this is the inverse of architecture. LARS EGGERT: Wearing my IRTF Chair hat: Zach, a long time ago you mentioned during your presentation that you would love the IRTF to have a group that will give you the building blocks that you need down the road. And I would love to have a Research Group to do that as well. The reason we don't have it is so far there hasn't been sort of a kernel of people that felt interested and energetic enough to make it happen. So I want to turn this back to you guys specifically who are sitting up there. If you're talking about having another workshop in some form in the next IETF meeting, it starts to look a lot like a Research Group. And that doesn't necessarily need to be an academic Research Group, but it can be something practical. It can be something like where folks like the gentleman who spoke before me could bring up that stuff and we can talk about it longer. But Research Groups need energy to start, and clearly there is energy in the space; it just has not culminated yet. So if you [audience] are interested in participating in one of those groups, talk to these guys [panelists] after the session. LI CHENG: I have a question about the design principle for the lightweight end-to-end protocol. There is already some very interesting debate in terms of lightweight terminology. So, is there lightweight protocol for all the devices, or a protocol for only lightweight devices? People are wondering, for example, is COAP only designed for very constrained devices, or whether it can also be used for addressing intelligent strong capability devices. I believe the IETF should give the clear impression to the other industries how we are going to use these kind of protocols, because now people are confused outside. Maybe we are debating one use case how to control the camera using switch on, switch off. People believe that the camera is always in a fixed location with very wide bandwidth; why do we need to use COAP? We are already using HTTP or some other protocol to do it. So I think you better give guidance from IETF to the external industry, our protocol can also be used by some strong capability devices. We are supporting transfer and data and also protocol itself is also intelligent. Lightweight doesn't mean limited capabilities. CARSTEN BORMANN: This work, each time you say "lightweight," my hairs go up again. The term "lightweight" was misused in the late '80s/early '90s for trying to do new protocols where new protocols were not needed. So I have this knee-jerk reaction to "lightweight." COAP is the abbreviation for COnstrained Application Protocol, so it's really meant to be used in a constrained space. If your space isn't constrained, we probably already have protocols that would work very well for that. That doesn't mean that next week somebody will not find maybe another great way to use COAP as a protocol in a space that we haven't even been thinking about, but as protocol designers, we are not trying to widen our space of application; we are trying to focus on the constrained space. If you are leaving class two on my slide, then probably you should use HTTP. One example we discussed was security cameras, which already have all this stuff in them to do the processing. Those are easily able to talk HTTP too; they are recording devices and so on. But they might want to talk to a motion sensor or some other device, maybe a light that can be switched on to improve the visibility of the view. And so the security camera might want to use COAP as an additional protocol to talk to those devices as well. ZACH SHELBY: Just something really quick to add to that: It's not only about the fashion RAM, it's also about the network. There are applications where you might have fairly powerful devices but really limited networks where something like COAP can be useful. ROBERT ASSIMITI: Right, so I wanted to point out lightweight does not necessarily mean limited. That's the message here. I was having a discussion with my colleagues a few weeks ago where we were trying to define smart object, and we said from our background embedded tiny footprint, but how smart can a smart object get. And my colleague said it's going to be smart enough when it can sell itself on eBay. We had a discussion, I believe that's achievable with embedded processors and the computing power available in embedded processors these days. Especially with like efforts like COAP, I think it will be achievable fairly soon, if not already. HANNES: Okay. So we are running a little bit over time already, so Markus, and then we wrap up. MARKUS ISOMAKI: The IETF has so far built a lot of great protocols for internet of things and enabling these constrained devices to be connected to the internet and doing interesting applications. But how much new work do you actually see in IETF is still critical in this area? Or is it already that once we have delivered these building blocks that we are already building, like COAP and a few associated extension and so on, is it then actually up to the hardware guys, the radio guys, the application developers, the companies, these other SDOs working on the vertical industries to put this into reality? Or is there still some critical work beyond these things that the IETF must absolutely do before we get to where we want to be? CARSTEN BORMANN: Let me answer this with a simple parallel. The HTTP standard that we're using all the time is from 1999. Of course, there has been new work, but it was not about redesigning HTTP all the time. It was about filling the gaps for making it more useful, getting some form of authentication, and so on. The base protocol really worked well. What we are trying to do is build building blocks that actually can last for decades. On the other hand, the world around us changes. So, we are trying to shut down the 6LOWPAN Working Group, and Markus is coming up with low energy and other people are coming with some ultra low energy, and so on. So there will be new work, just because the world changes around us. MARKUS ISOMAKI: It's more like, offer maintenance and extension type of nature, right? Not like that some really fundamentally new protocol. The action has to be more on the applications themselves and all that kind of things and the protocol side has to be--not many people know that there's been that much development in that space. They see Facebook and these kinds of things happening. HANNES TSCHOFENIG: Since you brought up the Facebook example: we actually do some protocol work, not in the HTTP area, but in OAuth and JOSE and some other work that is related, but not immediately attached to HTTP as such, although it will probably be used mostly over HTTP. In any case, I would like to thank you all for the discussion and the feedback you've provided. I'm not trying to even remotely summarize the discussion, because that's difficult. I've heard persons from the audience suggesting that we get in touch with the sensor community and hear what they have investigated; to talk to other organizations, send people there and help them to get their things along and solve their problems; but also to provide guidance within the IETF itself when it comes to sleeping nodes, efficiency of protocols with regard to energy and so on. Lots of other technology and challenges with the protocols that we have been working on. With that, I switch over to Bernard for the open mic session. Let us thank the panel members for their presentations and the discussion. [Applause.] 6. IAB Open Microphone Session BERNARD ABOBA: We'd now like to ask the members of the IAB to come up and we'll open up to questions from the community. [IAB Members 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] PETER SAINT-ANDRE: One thing that came up this morning in the APPS Area Open Meeting was the identifier comparison document that Dave Thaler stopped by to talk with us about. It's not quite clear, to all these people, how those kind of documents would get used--what their status is, in terms of if they're a BCP, is that then supposed to be driving work in the Applications Area? Dave, maybe you could talk about your perspective on that topic, how that can came up and what we do with some of the output from the IAB? DAVE THALER: Sure. There was a question that was asked in the APPS Area Working Group and for the benefit of the rest of the community, I'll repeat the answer I gave there. I gave a heads-up to the IAB earlier today. The question is about when the IAB writes a document, what's the formal status that it has? That's part of the question, right? The rest of the question is, for a particular case, what do you want the status to be? I gave an analogy and said, "How do we get to where we are today, what's our current practice?" We can talk about that. I gave an analogy to the documents at the IAB has done such as the UNSAF work, where the IAB did a document, and at that point, the document is just an IAB consensus document. It doesn't immediately have a impact on the community, but it makes recommendations to the community (that community being the IETF and/or the IESG, or potentially other organizations for other documents). Then, in that particular case, the IESG picked it up and said, "Okay. We like this and we are going to enforce it," and at that point, it became something that was solid, as opposed to something that was IAB consensus. It became an IETF thing. So that's the path that some documents go through. We haven't had a discussion within the IAB on what the actual status should be and so on. I gave that as my observation of what has happened in the past, but we haven't actually had a discussion, so I can't give you an official IAB answer. At this point, I don't know if anybody else wants to add anything. But so far, the IAB writes documents that are recommendations, and people take them as recommendations. If they're good recommendations then they tend to have effect, and if not, they get ignored. RUSS HOUSLEY: The IAB doesn't write BCPs. DAVE THALER: So, the other part of the question that came up in the APPS Area was about that document in particular, and whether that document or another document should in fact be a BCP. That's the other part of the question. So I was trying to first answer the question in the more generic fashion, and not for the very specific document. DAVE CROCKER: Russ, thank you for saying that, because that's sort of exactly what I think is not true. The reality of the process with IAB documents that declare themselves recommendations is that they do in fact take on the BCP force in the way decisions are made in the IETF. I actually think that's okay, as a principle. It's a question of how things are done to make that happen, and how we know about it. So, the concern I had was not that the document was being developed--I think it's actually really important. It's that first of all, out of the gate, it didn't have a discussion venue. That's being corrected, which is great. But in fact, the pattern of these documents has been that they haven't had discussion back at the venues and the process of getting them approved is, it's just the IAB that approves it. There isn't actually a community consensus process. That might or might not be okay. It certainly isn't something that's been discussed. What I would really love is for this to engender some discussion and process, that makes things more regular, rather than having the IAB dump stuff on us, which is actually been what the pattern has been. RUSS HOUSLEY: I couldn't disagree with you more. DAVE CROCKER Oh, I bet you could. I'll bet you could. [Laughter.] RUSS HOUSLEY: The IAB hasn't recently published a document that it didn't first ask for community comment. And second, BCPs require consensus and the IAB stream is not used for that. DAVE CROCKER: So, I said equivalent to; I'm not trying to nuance the word. I'm saying that there is an effect of a best current practice for the topic that that document is covering, with respect to producing work out of the IETF. BCPs typically are about best practices out there in the world. This has to do with best practices in this world. And so I meant it as a structural equivalence, not the term itself. The term gets used in lots of environments. My point was, when I said dumped on, I mean that, yeah, the IAB got some feedback, but we don't typically have a real conversation; we don't know what the IAB does with those comments. But at some point, the IAB is done and the document is then put out and it carries quite a lot of force. My suggestion is there needs to be real dialogue, and there needs to be a process that really entails more like community consensus than IAB consensus. ROSS CALLON: Just to make sure I'm clearly understanding what you're saying: I think what I heard you say is that if the IAB produces an Informational document, the clout of that document may be greater than some other Informational document produced by five people from the community who just got together and wrote a document? DAVE CROCKER: At its core, yes, but let's try to ignore what the RFC label says. A document from the IAB that says "recommendations" or has anything that looks even slightly normative in it definitely has way more leverage than if I wrote it--and it should. It's a group of people, in a position that has been assessed by the community, and that part is fine. Taking the initiative to create these documents is really good. It's a question of what the process is of developing it, and the process of getting the community to support it that I'm suggesting could be done differently. DAVE THALER: I just want to add that in this specific case (and I think the same is true for other documents that we've done to make recommendations), the intent is to bring the community into the discussion early. In this particular case, both when I presented the document in the Security Area last time and the APPS area this time, I mentioned quite explicitly this is a draft -00, and it did not contain recommendations yet, and here's the sorts of recommendations we might make, and if the community has input on those recommendations then tell us now so that we have that as we get into deliberations. I think in this case, we've been specifically trying to involve the community in that input as we're coming up with the recommendations. I took the comment here at the mic now as being a more general process question about how the IAB does documents, rather than this one in particular. But at least for this one in particular, we have been trying to do that. BERNARD ABOBA: As described in RFC 4845, Standards Track or Experimental documents are not published in the IAB stream, so most documents in the IAB stream are Informational. If a document is intended as a BCP it needs to use the approval process of the IETF stream. So there is currently no way to indicate that an IAB stream document is "of Dubious Value" (below Informational) where skepticism is actively encouraged (a "Disinformational RFC"). As an example, within the Privacy the Privacy Considerations document will discuss how to write a privacy considerations section. This document is Informational, not a BCP or Standards Track, intentionally. The idea is to provide guidance on how to write such a section, and to encourage experimentation and feedback on the guidelines. The decision to require such a section in any document is a separate step, and one outside the IAB's authority. It is important that just because members of the IAB are respected, that an Informational document not carry such enormous weight that a suggestion automatically becomes a mandate. Otherwise it would not be possible to try something out or suggest anything. OLAF KOLKMAN: I'm actually wondering, Dave [Crocker], how many documents over the last few years have come out of nowhere and came as a surprise? Because I believe that in all the updates we did over the last few years, we provided the document activity, including the "draft-iab-" with version numbers that went far beyond zero. I'm wondering, as if, it feels like, you're missing things that fall out of the air without Call for Comments and so on. DAVE CROCKER: But I didn't say anything like that. You're invoking the reference to surprise as if I was saying that you had surprised us. OLAF KOLKMAN: Then I misheard you. DAVE CROCKER: It's about the process of developing it and the fact that drafts show up. We'll take the current one for example, just because it's the one in front of us. It comes out and says "Issues." The presentation is made to the Security group, and it's great that Dave has now come to the APPS area, but this is only now. This is quite a few months later. What wasn't clear from the current document, and isn't in the current document--in its title or its content--is that the intention is it will be a set of recommendations. There was no way to know that unless you happened to be in the Security presentation that was made. That constitutes six months of duration of life in which the goal wasn't known. It was to you guys. It wasn't to us. Now, I wasn't actually trying to say that what the IAB was doing was a surprise. I said that the process of developing it was such that it doesn't actually engage a serious dialogue in the community. It's one thing to say, "Oh, we want comments." It's another thing to have no venue for it and not actually conduct a conversation. DAVE THALER: I just want to comment on one thing, because one of the things that the IAB has talked about is the purpose of the IAB stream in terms of when we decide to accept a document or not accept a document, how do we decide whether it should be in the IAB stream or some other stream? What things are actually appropriate to be in the IAB stream? There's at least two categories of things on the IAB stream--probably more--but two main ones. The first one is things that are not IAB consensus documents. Workshop reports are the primary example of that. When the IAB hosts a workshop and then we report on that, it's not an IAB consensus document. That's a workshop participants' consensus document, and it's reporting that out. That's why the list of workshop participants are in the RFC and the list of IAB members is not in such an RFC. The other category of things is things that are IAB consensus documents, and all of those sorts of documents, we ask why should this be an IAB document as opposed to an IETF document or an individual document or AD-sponsored document. The most common reason for something to be an IAB document is that the IAB may want to make recommendations. If it's not a case where the IAB is going to have any recommendations, then we have a lot tougher time saying this should become an IAB document. So to Olaf's point about when the IAB puts documents up there: other than workshop reports, you should expect there to be recommendations for any document other than a workshop report, or it wouldn't have been in the stream in the first place. Those are the two major categories, and there might be some exceptions for a document here or there. But that's typical. If it's an IAB document and not a workshop report, you should expect there to be recommendations in it. BERNARD ABOBA: I just would like to cover a point of information that may help. For each IAB document, we have moved to the TRAC system [http://wiki.tools.ietf.org/group/iab/] for tracking issues. If people want to know the status of a particular issue, or a list of all open issues, it can be found on TRAC. When a Call for Comment is announced, comments can be sent to the IAB or filed in TRAC. If you file an issue in TRAC and the status changes, you should receive an email. You may not be satisfied with the disposition of your issue, but if it is filed in TRAC, it won't be lost or ignored, and it should eventually be resolved one way or the other. The IAB has public mailing lists on which IAB items can be discussed. By default there is the architecture-discuss@ietf.org mailing list [https://www1.ietf.org/mailman/listinfo/architecture-discuss] as well as public mailing lists for specific programs. For example, ietf-privacy@ietf.org is the list for discussion of Privacy Program documents [https://www.ietf.org/mailman/listinfo/ietf-privacy], rfc-interest@rfc-editor.org is the list for RFC Editor or ISE-related documents [https://www.rfc-editor.org/mailman/listinfo/rfc-interest]. We'll take a look at the public mailing lists for the programs and initiatives to make sure that there is an appropriate place for discussion for each of them. Thanks for that input. IETFer: I have one question. Dave [Thaler] said relationships with other standard organizations. I just came from the Open Mobile Alliance (OMA) meeting, and in the meeting, there were some complaints about the late response for the liaison. They complained that for some liaisons with the IETF, that they didn't receive the response back, or that the response takes a very long time. I'm just wondering if we can do something better to improve the impression of the IETF? Because the other standards organization will think that they never receive the response from the IETF about that liaison. HANNES TSCHOFENIG: The IAB appoints liaison persons. In the case of the OMA, the Open Mobile Alliance, Murray Kucheraway is the liaison person from the IETF side to the OMA side. When we get those liaisons, he then forwards those to the respective group. For example, during the summer we had received one liaison about OAUTH, to the OAUTH working group. We responded to that, and send it back to Murray and he forwarded it to the right person. So the IAB only appoints the liaison person; it doesn't do the liaison work itself. On that specific requests, OMA is a big organization so I don't know which request that was, but we should definitely talk to track it back and see where that item got dropped on the floor. I should add, the most effective way actually to figure something out is to talk to the persons directly. In the OMA case, we have persons doing OMA and OAUTH work; we actually have persons who participate both in OMA and in the OAUTH working group, so it's so much easier to post a message to the mailing list and to ask some other members to get feedback, or have a conversation here to get some feedback, rather than sending these complicated document exchanges just to get an answer that says, "We don't exactly know when our documents will be finished." ZHEN CAO: I have a question regarding the IAB's connectivity with the other architecture groups. We know these days in Europe or Asia Pacific, we have the different conferences and we have some architecture groups working on the future internet architecture. So I don't know if IAB has some connectivity with those organizations, and if not, do you have a plan to do that? BERNARD ABOBA: Yes, we had a conversation in the last quarter with W3C Technical Architecture Group which is up on the website. There are regular liaison meetings between IETF and W3C as well. HANNES TSCHOFENIG: I think that comment is more in relationship to some of the, for example, European Commission's Future Internet Architecture Group [http://ec.europa.eu/information_society/ activities/foi/research/fiarch/index_en.htm] and some of those groups that are more geared towards research. Or are you referring to, everything relates somehow to architecture? The talk we had earlier about NIST's smart grid: there's a lot of architectural work in there. To which specific effort are you referring? ZHEN CAO: I'm actually referring to in the United States we have the FIA working group. Some projects supported by FIA, and in Europe we have AP7. HANNES TSCHOFENIG: Those are research initiatives. The IAB doesn't maintain any relationship to those. But that would be more from an IRTF perspective, that some members of that community actually work with those as part of their research activities. But that's a question probably to Lars to explain that relationship. I hope that answers your question. JOHN KLENSIN: I'd like to follow up on both the comments which were just made and one of your comments earlier, so I'll take them in that order. There's actually a long history of IETF maintaining liaisons with various research activities and it is certainly within the IAB's authority to sort that out in an arbitrary number of ways, of which deciding that it's an IRTF problem is one, should the IAB decide to do that. Bernard, with regard to your notion of Disinformational RFCs: I find it rather charming, but would point out that we've got a 25 year old history of doing that, and it ought to be well within the IAB's authority to negotiate with the RFC Editor about having as many April 1sts a year as you discovered that you needed. HANNES TSCHOFENIG: At the moment, in the IAB we do not maintain a liaison relationship to these efforts, at least not that I'm aware. However, some of the members in the IAB are actually actively participating in those communities, but as individuals. They provide information back, so for example, speaking for myself, I participate in the European Commission Future Internet Architecture reference group and share my personal wisdom there. Others do similar things in other research groups, but it doesn't have a formal character. I think there's a lot of value in having these informal channels. JOHN KLENSIN: I certainly agree there's value in having informal channels. It seems to me that parts of this issue touch on the long- term question about what the IAB is about, and the degree to which the IAB should be acting in some but probably not all of these situations as a board, rather than having individuals wander off and do things and report back. It's a fundamental question of what the IAB is about that we've been debating in one way or another since 1994 at least. All I was trying to point out was that if the IAB decided that a more formalized and concerted activity was appropriate to any one situation or any cluster of situations, that it certainly within the IAB's authority and scope to do that. I'm hoping that the IAB is discussing those questions at regular intervals where that's appropriate. I deliberately did not ask that as a question, in the interest of time. But I'm certainly hoping. LESLIE DAIGLE: I got up to push back on Dave Thaler's characterization that the IAB publishes documents with recommendations, and if there are no recommendations they're not clearly an IAB document. That may be representative of what this IAB does or does not do with its documents. But it's not quite a fair characterization of what the IAB in the large has done. In fact, from the streams document, IAB stream documents are representing information that the IAB has deemed valuable to provide for permanent record. There have been occasions where it has been valuable to publish, and so I think it's important to keep that in mind. From there, I'd like to pivot to the whole question of the IAB providing recommendations. I think you heard a little bit of push back this morning in the APPS Area Working Group when you were presenting the IAB document on security considerations and identifiers. I think, to be well understood, the stream system of RFCs does scope that eventual document to being a recommendation of the IAB to be taken as something that this particular group of 12 or 13 people agreed on, which is fine, and I am confident it will be interesting. If you want something that is going to be actually normative or directive to IAB work, there is nothing stopping you from making it an IETF document, and indeed it's better to make it an IETF document so the IETF can recommend to itself what should be done. It is a longer process, that consultation thing and keeping people in the loop can be messy, but at the end of the day it produces something that everybody has buy-in to and understands where they're going with, rather than surprises or something visited from on high. OLAF KOLKMAN: And, in fact, this is a discussion that we regularly have. We had one on the privacy document this week, in fact, about whether it goes on the IETF stream as BCP or Informational. It is one of the things that is often discussed. Probably with most documents. And yes, the IAB does publish other things, like IANA requirements, and other layer eight and nine stuff. BERNARD ABOBA: Very often, there's a specific desire to make it non- normative. So it gets published on the IAB stream and it's out there, and you do with it what you will. DAVE THALER: I just want to follow up and clarify what I meant was, my response before was in the context of what the expectation is for an IAB document that might contain the word "issues." My point was that the typical expectation should be, at least from this IAB, that it contains recommendations. Now, there are lots of things the IAB could take on as documents. We only have so many cycles, so we tend to take on things that we think would have a larger impact and actually have some benefit to being published on the IAB stream as opposed to another stream. Now, we've had the same discussion for things like terminology documents, which we're talking about right now, and in the privacy case. We've had this in the peer-to-peer architecture document that we did. We chose to publish the peer-to-peer architecture document in the IAB stream even though it contained no recommendations in it. But that was the conversation we had: Does this make sense as an IAB document, or is this something we can let somebody else do? Those are the conversations we go through, and we tend to concentrate on ones that have recommendations in it, just to optimize the time here. So that was primarily, yes, the IAB does documents that don't, and that's what I meant by saying it's more than just those two categories; there are other exceptions. But in the current way that we're working with programs and so on, we tend to be focusing on things that have recommendations and so as far as doing expectation- setting, if you see a document coming from the IAB that's not a workshop report, your first expectation now is that it's probably going to contain recommendations. I understand the rest of your comments are not on that; it's about the particular case here, and thanks and we'll talk about that. Good points. BERNARD ABOBA: We should mention that there are two IAB documents that are in Call for Comment now. One is Danny's "Architectural Considerations of IP Anycast"; another is "Independent Submission Editor Model," which is a description of the model for the ISE. SPENCER DAWKINS: I wanted to back up twice on a couple of things. One is the idea that if we're doing something in the IAB stream that looks to the community like it should be in the IETF stream, tell us. Our job is not to not listen to people. The idea that we would be engaged in conversation with the IETF community, I think that's something that everybody needs to keep in mind. The second point: I've stood in line at plenaries more than once where somebody got up and asked the IAB basically, "So what do you guys do? You know, what does the IAB really do?" I'm still first-term on the IAB, but I think even in the time that I've been on the IAB, it's gotten a lot easier to figure out what we do, and a lot easier to talk to us. We tend to have very well-prepared, up-to-date minutes that are available pretty quickly after things that we do. We now have a program structure--and this is new within the past 18 months. Most of the programs have public mailing lists that you can participate in conversations with and things like that. These are things that are new that the IAB is doing, especially in the program stuff. This is new that we were not doing two years ago. So, if you are used to looking at the IAB and saying, "What the heck to those guys do?" I understand that. But now I think it is easier for people to engage with the IAB, and I would encourage you to do that. BERNARD ABOBA: I would also mention a little known fact. There is actually an architecture discuss mailing list [https://www.ietf.org/mailman/listinfo/architecture-discuss]. It hasn't had a message posted in two years. But it exists; you can use it. SPENCER DAWKINS: At least some of us are still subscribed to that. BERNARD ABOBA: If no one steps up to the mic soon, we're going to let you go to dinner. Okay. Enjoy.