5 December 2007 IAOC/IESG Plenary Welcome (Russ Housley) Host presentation (Dr. Stephen Wolff, Cisco) NOC Report (Morgan Sackett, VeriLAN) NomCom Chair (Lakshminath Dondeti) Recognition (Russ Housley and Internet Society) IETF Chair Report (Russ Housley) IAOC Chair Report (Kurtis Lindqvist) IAD Report (Ray Pelletier) AMS Secretariat Staff Introduction (Ray Pelletier) IAOC Q&A IESG Q&A 1. Welcome (Russ Housley) 2. Host presentation (Dr. Stephen Wolff, Cisco Research Center) 3. NOC Report (Morgan Sackett, VeriLAN) 4. NomCom Chair (Lakshminath Dondeti) 5. Recognition (Russ Housley and Internet Society) - sad news: Itojun [ Moment of silence in his memory. ] - Mark Foster Many thanks. Mark played a pivotal role in the Administrative Restructuring of the IETF. Without Mark’s assistance, the restructuring would have taken much longer and been more painful. - Postel Award (Lynn St.Amour, CEO, ISOC) Dr Nii Quaynor says he feels humbled by this award and by what it represents. Africa is thankful for this recognition and will be very pleased with this contribution. Nii also thanks his colleagues in Africa who were pushing him along all this time. The IETF community have helped a lot by the way the number and name resources have been defined. That has helped Africa's understanding and its self organisation. With the award money a new fund for young Internet engineers will be set up. It will be managed by AfriNIC and AfNOG. 6. IETF Chair Report (Russ Housley) 7. IAOC Chair Report (Kurtis Lindqvist) 8. IAD Report (Ray Pelletier) 9. AMS Secretariat Staff Introduction (Ray Pelletier) 10. IAOC Q&A Joel: would like to hear where the tools development is going and how the transition will be done. Traditionally this was the task of the IETF secretariat. Ray: anticipates that the I-D tracker will keep running. AMS has a vibrant tool set. We will look to see whether we should take that on board. NeuStar is doing tools development. There was an RFP on the Django port of the IESG I-D Tracker development. NeuStar won the bid. Russ: volunteer development is important. It is a way to save money. At the moment, we are defining a process to take on tools that will be operated and maintained by the Secretariat. Non-Profit Open Source License (NPOSL) version 3.0 was developed for this situation. Dave Crocker: frequently interesting things happen at IETF meetings. When it is of technical nature, it might be interesting to give a summary of what took place and why. As an example: the pecularities that took place with the audio stream this week. would be interesting to hear the cause for that. Joel: high availability equipment failure is responsible for most of the outages. Leslie: Russ said tools from the tools team is a way to save money. But it is much more than that. This is a community that is very much hands on. Need to understand what the long-term plan is to support ourselves. Would like to see a plan on how we might move forward, and how the tools process will support our community. Russ agrees: As an example: XML2RFC is a tool we all depend on. Harald: every tool we develop will be supported on a best effort basis for the next 1000 years? ;-) Harald: how is the RFC licence agreement going? Ray: on the website is information on how to contribute their documents to the IETF Trust. Harald: how many of the first 2000 RFCs have you gotten signed over. Ray: we don't have such an inventory. But the names are all on the web site. Maybe a 1000 or so. Russ: went through the process and it was a fairly painful only because the part of Xerox that I worked for at the time I wrote the RFC no longer exists. Needed to get VP approval. Ray: also corporations signed it, e.g. IBM (all the docs by IBM employees are signed over to the Trust) Harald: has a question about wether or not people can take code from RFCs and use them in implementations, in particular modified versions of that code. Has the IETF Trust made a statement that people can do this? Kurtis: no. This is a point well taken and will be addressed. Paul Hofmann: 'code' is an interesting choice of words. He has written code that appears in RFCs (not yet signed to the Trust, but will do tomorrow). Often those modules are not really code. There are very few real code-programs in RFCs. It is more 'chunks of non-english text that might be useful'. Suggests to be very lenient in the IAOC statement about that. Steve Castner : thanks VeriLan for the quality of the network. No glitches! 11. IESG Q&A Pete Resnick: years ago IAB and IESG switched plenary nights. That stopped. Why? Would it make more sense if the IESG would be on Thursday and the IAB on Wednesday? Spencer Dawkins: has the feeling that we gotten to the point that opening a connection to the Internet on a computer is becoming a challenge. Seems we reached a new level of insanity. Most what is driving application protocols seems to be NAT traversal these days. Magnus said in the tsvarea meeting: we end up having hosts hanging on different NAT levels. We need to continue trying to dig ourselves out of this hole, but it will take a long time. We can continue to improve things. Keith Moore: was surprised to see that in the behave WG that what they are doing are piece-meal solutions, adding complexity to the network. Was for instance told that the client server problem is solved with NATs. Magnus: it is on the behave WG charter to specify how NATs can behave more reasonable. He hopes that we can have NATs in the future that behave better and according to spec. Keith: making multiple incremental changes to NAT is a failure. Will not work. Lars Eggert: Keith, which part of the work in the behave WG do you have problems about? Keith: it is the punching holes part of the work. It is not general enough. Sam Hartman: there is a discussion in STUN and ICE where it is decribed why a general solution is not good. If you have concerns with that, suggests to respond to that in a constructive way. Keith: fair comment, will do that. Bob Hinden: went to tictoc BOF. I believe that it would be a mistake to work on time related protocols before ntp WG is finished. Mark Townsley: The ntp WG will be done with the IPv4 part real soon. Agrees that there should be only one time-related WG. Has been delaying enhancements, because the v4 part wasn't done. But this cannot be delayed any longer. Bob: suggests new people work in the existing WG Mark: yes, that has been done for the last few years. Believes it is now time to start new WG. Yakov Stein: true, this topic is almost done in ntp. This is a no longer an issue. Jonathan Rosenberg: in response to Keith Moore: one of the properties in behave is incremental deployability. Happy to discuss more offline. Kevin Fall: question about RFCs that reference older RFC. The older ones were informational or experiemental. The newer ones were STD track, but did not obsolete the older ones. I asked the RFC Editor and was told that this was up to the IESG. What is the process to obsolete an old RFC? Russ: This is not as simple as you think. We have to look at specific case. Often there are 3 or 4 generations of documents. Need to look at the whole picture. The RFC Editor has asked the IESG about the one that you reported. Spencer: didn't see discussion IPv6 deployment on the agenda? We talked a lot about it last time. What happened to it in the meantime? Russ: There was a huge amount of talk about it this week and before. Ross Callon: hears a lot of talk about NATs and address exhaustion. He is afraid that it is always easier to do a short time fix even if that adds complexity. At some point it might just be easier to move to new version of IP. He hopes that the pain will be high enough to deploy IPv6. Wonders what else we can do to encourage the move over to IPv6. Sam: suggests that this is the wrong answer. IPv6 is catching on where it has value. IPv6 is being incrementally deployed. Often inside closed organisations and networks. Starting to see networking effect. Wonders if the idea that we should all switch over to IPv6 makes that much sense. ??: deployment is not that straight forward (involves tunnels, administrative work etc.). All this needs to be better documented. People in this room can help with that. Ross: people in general are not real good at moving to where they need to be in 5 years, but they are good at moving to where they need to be in 5 days. What can we do to help with where we need to be in 8 or 10 years and not have this same disussion then again. Jari: the pain will increase. That is clear. What can we do as IETF? We can make sure all the pieces are in place so that users can deploy. Do we have all transition mechanisms in place? Tomorrow this will be discussed in v6ops WG. Outside the IETF education needs to be done. ISOC is for instance working on that. Much of the work now needs to be done outside the IETF. Ted Hardie: happy to hear from Sam, who talked about adoption and not transition. We have a fundamental problem if we talk about transition. IPv4 and IPv6 are disjoint address spaces. There will never be a transition. Jari: agrees. The point is that we need to provide good mechanisms to move between IPv4 and IPv6. Ted: question than is if 'leadershhip through pain' really works. He is afraid it doesn't. If we are still talking about this now, how can we expect the industry to use the right terminology. We need to get people to understand what is happening in deployment. Tony Li: people upgrade because they want features or because the pain is too high. The only thing we can do is to add features. Sam: The critical feature is the network itself. We need to keep the network efect in mind. We can make things easier. Some vendors are now working to do that. Philip Matthews: even transition to IPv6 will not get rid of ICE stuff. Magnus: agrees. Firewalls will not go away. However, hopes that we will have a good solution that works and will improve the situation. Philip: what is the incentive to deploy a better solution if ICE works in such situations. Robert Sparks: runs an interop testing for SIP, and works very hard to have global routable address space. At a recent meeting. at a university campus there was one router that only worked with IPv4 and NAT. They ended up savaging the network by setting 6-over-4 tunnels. Sam: did they implemented v6 to v6 NAT? Robert: Yes Gregory Lebovitz: A killer application is needed Geoff Mulligan: yes, but only if the killer application is available on IPv6 and not available on IPv4. Sam: if I only accept IPv6 connections, I can still talk to people through IPv4. Alain Durand: this discussion is surrealistic. This has nothing to do with features. The motto has been for many years: bandwidth, bandwidth, bandwidth. The motto has changed to: address space, address space, address space. It is as simple as that. Joel: addresses are about end points not about applications. When you want to reach an end point, you need an address. It is not about killer applications. Margaret: We are the IETF, and we are pretty much done with IPv6. The single biggest barrier to deployment is unavailability of needed equipment. There aren't enough test tools etc. There is not much the IETF can do beyond encouragement and educatation. Jari: very good point. There are bugs and problems with existing equipment. This is because not many people use IPv6 yet, so bugs don't get detected and fixed. We need more users to fix all those. Believes it is a matter of time. Jonathan Rosenberg: there is no killer application. Why would a vendor build an application that only works on a platform that is unavailable to most users/customers. Application developers will build on a platform that many people use, not one that most people don't use. Fred Templin: submitted RFC4214bis to RFC Editor as an independent submission. What happened to it? Mark Townsley: it was decided that any submission that would conflict with the softwires WG would be blocked for now. Fred: but this has already been published as an experimental RFC and been implemented. Mark: believes that the charter item in softwire is almost done and then the road will be clear for that document. Will continue the discussion offline. Keith Moore: does anyone have a good list of things that are not in place yet for IPv6 deployment? This would be useful for us and others. Ron Bonica: for things that are not specified yet, this can be done in the v6ops WG. For things that are specified but not impelemented yet is outside the IETF. Keith: would still be good to know about those. Jari: there are various lists in the operators fora, can send links to the list. Jordi Pallet: 80% of his time is dedicated to deploying IPv6 with real customers. Most problems are out of scope of IETF. Mostly education related. One open issue is translation between IPv4 and IPv6. There is actually much more IPv6 traffic than people think. Only 5% of IPv6 traffic is native; the rest is through tunnels. Peter Koch (?): it is quite clear what is happening: we came up with this huge address space, but immediate shortage problem was fixed by NAT. At some point we will see IPv6 on the backbone, but people will still use IPv4 on the edges. This is almost not problem. ??: RoI has not been mentioned before. Really sad that operators are under-represented at the IETF. The ops community is still unaware of the necessity of depolying IPv6. If the IETF can talk to the ops community that could help. However, the IETF is not to blame for slow deployment if IPv6. Tim Sheppard: has been using 6to4 for many years. In some sense it is easy. Has been watching to see if IPv6 is really used. Has been using dig on some of the TLDs. There are quite a lot of IPv6 out there, but not for com and not for dot. The view that IPv6 isn't already here, is only true for people who live in US and other countries where the native language is English. If your native language is something else, people see much more IPv6. Mark Townsley: how about we challenge Google to offer native IPv6 before the IETF they are hosting. Adiel: yes, IPv6 is happening. Yes, the IETF has been doing a lot in that area. Agree that many issues are with the operators. He knows that all the RIRs are working with their communities on these topics. Maybe the IETF can come out with clear messages about IPv6 readiness. Geoff Mulligan: yes, it is a matter of addresses, addresses, addresses. His company will need millions of addresses, hence we will use IPv6. Problem is that we spend so much time fixing things in IPv4, that we don't have resources to fix things in IPv6. ??: some question related to SIP related WGs. How can we address this problem and avoid having the wild west or a detailed 5 year plan? Jon Peterson: it is going to take a long time to do these things. Dave Ward: The IESG spends a lot of time on RAI and SIP documents. We need more people reviewing these documents. The volume is enormous. ??: Problem is not the IESG. Henning Schulzrinne: there was general agreement that we can provide useful auto-configuration for SIP devices, but we cannot do it because the protocols were developed elsewhere. Now we are stuck. Sam: suggests to get concensus on the needed reference in the WG and get your AD to agree. Mark Townsley: ACD documents have been adopted in the INT area. The whole zeroconf effort is important and has a lot of history. It is important to get it right. Pete ??: in terms of information: specification was too restrictive at the time it was written. In terms of process: everything is slow in the IETF. There are reasons. One reason is speed of authors to turn around drafts. Other documents start off as experimental RFCs, it is often difficult to bring to the standards track. Cullen Jennings: need to look at what points were right and which ones where wrong. Trying to reduce latency of drafts and increase throughput. Lars Eggert: WG chair has the option to replace authors or add co-authors. |