IAB Plenary - IETF 79 Session Agenda: 1. Welcome - Olaf Kolkman 2. IRTF Chair's Report - Aaron Falk 3. IAB Chair's Report - Olaf Kolkman 4. Technical Session: "IPv6 Operations and Transitional Issues " Presentations and panel discussion. (See Below) 5. IAB Open Microphone Session 6. RFC Editor Model version 2 (draft-kowack-rfc-editor-model-v2-00) - Presentation by Glenn Kowack - Q&A and Discussion 1. Welcome (Olaf Kolkman) Welcome to the plenary. Monday is a new time for us to meet. There are presentations on the data tracker, and on the meeting translation. There is a live English translation - the transcriber is best effort. We are doing the best we can with the transcription, but success is not guaranteed. When you come to the mic it is important you state your name clearly. There are many non-english speakers in the IETF, so keep it short and keep it to the point. The Agenda for the Day starts a little late. It starts with the IRTF Chair's Report, then the IAB Chair's Report, and then a technical session on "IPv6 Operations and Transitional Issues ". Danny McPherson will be moderation this discussion, and then have a short open mic session. We will then have a short discussion of the RFC Editor point of view. Now I would like to introduce Aaron. 1. IRFT Chairs report (Aaron Falk) I will give a shorter brief. There are four research groups meeting. The DTN RG met today, the Host Identity Protocol RG (HIP) will be meeting tomorrow morning, and the Scalable Multicast group (SAM) on Thursday. The Virtual Networks RG meets on Friday. A little more of an internal IRTF topic - the Peer-2-Peer Research Group published the RFCs. There are two drafts that are in review by the IESG, and here is another draft awaiting review. There is a discuss list for the ITRF. I suggest people send their research ideas to the IETF. The IAB is conducting evaluations for the next IRTF chair. The IRTF chair will be in place before the next IETF meeting. These are groups that are running the end of the IETF. The CAIN research group may be doing a reboot. The other IRTF groups are meeting regularly or meeting. Active groups are the machine learning and the communation systems. There are also folks interested in the Internet of Tings. The Bar-Bof for this is on Wednesday evening I'll pause a moment for questions. 2. IAB Report (Olaf Kolkman) The charter is on the IAB home page, and documents and correspondence. The minutes are also on the page. We are trying to get minutes published more quickly. These are the RFC 2850 responsibilities: IESG appointment confirmation - this is not yet done for the last year. In document activity, there are several IAB documents: IAB Thoughts for the Encoding for International Domain Names (draft-ieab-idfr-encoding), Architectural Considerations of IP Anycast (Call for comments soon). That document has not seen a lot of development lately, but it's still an active document and we expect to publish that. Danny McPherson here is laughing and I know why. That said, there are two documents that we are doing final IAB review on before doing a call for input from the community: Evolution of the IP model, and Design Considerations for Protocol Extensions. If you track the IETF list and you will see the call for comments - please read the documents and provide feedback. We posted a draft of Architectural considerations in the Application Features in the DNS. This is in context of our 2010 work plan on which I reported the last plenary meeting. Ee are trying to organize our according to programs and initiatives, programs being long term efforts that the IAB is interested in tracking and developing. Initiatives are a a more short term project, like a draft or a piece of work. This is one of these initiatives. It's a version -00 draft, and we're taking input from the community as discussion happens. As mentioned, the privacy program is one of those, a work program that we have. The goal of that program is to work towards consciously considering privacy in architecture and protocol development - make you guys aware of what you need to know about privacy, what you have to take into account when developing protocols. But there is a lot of work that needs to be done in order to get at that place. For instance, defining a common language. And we have set up a list, which is privacy@ietf.org And the drafts that are discussed therein, that context of defining the language and understanding the considerations are listed here. In addition to that, we are organizing a workshop in December, where participation is based on position papers. The call for position papers has closed, and I believe that we received over 50 very valuable contributions. I have very high hopes of this workshop being a success. Obviously, we will post the position papers, and make a report of the workshop available to the community. We had a joint IESG/IAB workshop held at George Mason University in Fairfax Virginia, US Oct 12-14 about OAM. There will be an ID soon with a report, I'm told, so this is a heads up that that's coming too. There's more info on the tools, the tracker WIKI on the IETF site. Another responsibility of the IAB is standards process oversight and appeals. We are one of the entities that handles appeals, and we received an appeal in the last period. I won't go into the details of the appeal but all the information, again, can be found on the web site. Mr. Morfin appealed seven points, we identified seven points and you can read the responses to them on the web site. RFC series and IANA oversight is another responsibility of the IAB. Lots of activity there in the RFC editor model, but I won't go into the details here because that is the last session of today, where we are going to discuss recommendations made by the transitional RFC Series Editor. The goal of the discussion later today is assess if the proposed modifications to the current model are supported by the community, and we have a fairly ambitious schedule to meet a March deadline, so we are in need of something if the plan fails. As far as the ISOC relation is concerned, we have nothing to report except there is a constant information flow. I'm likely to give the same report to the ISOC board of trustees. And of course, we have Lynn StAmour as a liaison in the IAB. I have the IAOC selection in here because it hooks onto those kinds of responsibilities. This is a responsibility that fell to the IAB after it was chartered - the IAB selects an IAOC member every two years. The documentation regarding that is in RFC 4701 and 4333. There is a defined selection process which we started at the beginning of this month. There is a call for nominations for people who want to serve on the IAOC - he IETF Administrative Oversight Committee. It's essential, the guys that manage the contracts. As an IAOC member, you're also a member of the IETF trust. If you're interested in this, the call for nominations is still ongoing, please send mail. In relations, external relations and liaisons, we are responsible for maintaining the contacts with external organizations, as, and in that context we had a meeting with the ITU leadership on August 2. We took the bus from Maastricht and ended up in Geneva. The meeting covered all areas of mutual interest, and the importance of maintaining good collaboration between the two bodies was recognized. We will have a high level meeting between members of the IETF leadership and members of the European Commission Director General on the Technology and Society on December 14. That meeting we're preparing for this week. Other business that I want to mention is that Vijay Gill resigned from the IAB, and we will not be looking for a person to replace him. His term ended March 2011 and we will continue on with one person less on the board. The open mic session is not now - we will have that later. At this point I invite Danny McPherson and the panelists to the podium. Danny will moderate the session on IP v6 operational and transitional issues. IPv6 Operations and Transitional Issues - Introduction (Danny McPherson) Just a moment, while we wait for all the panelists. I'm Danny McPherson, I'm on the IAB. We pulled this panel together, actually in very short order, as a matter of fact. About a week, week and a half ago, we decided we needed to pick another topics because of the density or quality of some of the other topics we were looking at. So I'm very thankful that the everybody on the stage had the ability to respond and participate in very short order. With that said, we're going to talk about a topic that's certainly not new to the IETF. We're going to talk about IPv6 transitional issues and co-existence. We knew this when we originally designed IPv6, that the deployment model was dual stack, which sort of inherently involves co-existence. With that we would learn a lot and adjust tactics and that's sort of where are at now. I will give an overview and then our panelists will presentation. After their presentations, we will have 20-30 minutes of the presentation. Moderator & Panelists: Bill Huang (China Mobile) Jari Arkko (Ericsson) - IESG/INT AD John Jason Brzozowski (Comcast) Matsuzaki Yoshinobu (IIJ) Xiaodong Lee (CNNIC) Ms. Huiling Zhao (China Telecom BRI) Danny McPherson (VeriSign) - IAB/Moderator And Tina Tsou from Huawei provided some deployment experience, and her slides are actually available now and posted in the proceedings, so we're thankful that she was able to participate as well. You have seen different graphics, Geoff pulled these together. The take here, the only thing that matters, is that in six months or so the IANA free pool is exhausted, and six months after that APNic is expected to be the first regional registry to run out of IPv4, to actually exhaust their pool. Anything after that is a crap shoot. Basically this means that if you have an internet presence, or you intend to have one, these are the operational deployment and budgeting time frames, and if you're not thinking about this or have not began deployment or analysis of IPv6 already, you're behind. The IPv6 base spec has been done for a very long time, or quite a while I should say. Most of the work in the IETF now is about transition and co-existence, you know, models, and some of the issues arising in deployment. There are deployment guys with experience, how we can modify maintenance and operations with IPv6 as a result. And then there are co-existence issues - they are certainly searching for feature parity, other things we need to consider. The v6 meetings on Wednesday morning are going to cover some more deployment issues, operational experience. It is certainly valuable to learn from each other - that is pretty much the intention of this. One more side here - as I mentioned the deployment model was dual-stack, which sort of inherently requires transitional co-existence, and then moving to IPv6 only in a quite a while. So we're going to have a very long transitional co-existence period. There's a lot of work going on still, some of the transitional strategies, or strategies of v4 only devices speaking to IPv6 networks where you don't have dual stack as an option. With no further ado, I'll welcome John Brzozowski to talk about his experience. So John, thanks. Panel Presentation #1 - John Brzozowski (Comcast) I want to provide a brief background of what we've been up to. Our deployment at Comcast started over 5 years ago, and the current state of our deployment is our network is largely dual stack capable. We've gone through the effort of upgrading our back offices, particularly those critical for residential broad band, and our access network is largely v6 capable as well. Something we can configure, upgrade via software, or we can simply enable with configurations to support IP v6. This last piece is one of the pieces that will probably take a fair bit of time, but it certainly is something that we've been planning for many years. When we originally started the program, the goal was to ready ourselves, at a bare minimum, to facilitate expansion. We came to the conclusion sometime ago was that we could incrementally extend that, and we could use, leverage the same work that we've done to extend v6 to subscribers. So, with that said, what we had done is, earlier this year, in the January time frame, we had announced our public IP v6 trials where we take them to subscribers. We were very pleased to find that we had over 7,000 people sign up to participate in those trials. What I'd like to do here is tell you more about each of those trials, particularly those where we've been active, and share some of the experiences that we've seen. So, based on some preparations that we had done earlier in the year, in the late winter, early spring time frame, we noticed that there was a non trivial volume of 6-to-4 traffic on the network. And perhaps that's stating the obvious, but for us, it was to the extent where we decided to do something about it. Given the fact that 6-to-4 is supported on a number of platforms by default, we thought this made a great deal of sense for us to really look at 6-to-4 as part of our program. As I'm sure you're all aware, there are a number of public relays that are available today. One of the one's that was receiving the vast majority of our traffic was one that was based at the University of Wisconsin - it was a major egress point for all six to four traffic. Clearly, when we took a look at the experience that these users were having, in that scenario, it was clearly not ideal. So we decided to put in our own relays, based on an open source Linux based platform. For this year, we decided to deploy a total of five, four which are deployed already, and we expect the last one before the end of the year. One of the most important things we noticed about this is it dramatically reduced the latency that was associated with six to four. A lot of people, including myself were generally not pleased with how six to four performed. Honestly at times felt that we couldn't do anything about it. But given that we've deployed these relays, I can now share with you and safely and tell you that this made a big difference in using six to four to get to IPv6 resources on the internet. The other thing we had certainly taken notice of is to track the traffic that was previously off-net was now on-net or trying to go off net - and it was certainly not trivial. It was a positive on many fronts. It allowed us to continue to exercise our infrastructure, all while improving the experience for people who were actually trying to use six to four. So moving on... the next trial technology that we had enabled was 6RD, which is, like, but not exactly analogous to - we're still encapsulating packets and it offers several benefits compared to its predecessor which is six to four. Based on our experience with the 6-to-4, we deployed six 6RD relays, they were very similar to the relays for 6-to-4. They were really simple to deploy. For people who are deploying the 6RD, we encourage you to do that. Our feedback thus far is it's straightforward. Your access networks cannot support native IP v6, this definitely feels like something that folks should look at. The one thing that we like to kind of just mention as part of some well rounded feedback here is where you place them is actually very important. We deliberately put them in certain parts of the networks so we can exercise and understand better how this might affect folks in the long run. We found that depending on where your subscribers are latency could still be a factor. So I think that's something that folks need to understand. As well as, you know, cost. The more you have to put out there, to subscribers, the more the investment will be for you. The other thing that we found is that, we actually had to kind of find our own CP or CEs to use for the trial. And unfortunately, that resulted in us having to manually configure all of the devices that we used as part of the trial. So with just shy of 300 some odd devices, we had to manually configure each and every one of them before we shipped them out to the trial users. That's clearly not going to be scaleable long term. So one of the things we feel that's very important for those of you considering this, is making sure that your CPE infrastructure supports the options. You know, there are some environments where that might not be universally true but for most of us it's that case. In our 6RD trial, we were only able to offer slash 64 on the land side, with the exception of a handful of scenarios, that wasn't adversely received. We got a lot of positive feedback with what we were able to do with 6RD. From the dual stack point of view, something that we at Comcast feel is central for our strategy for IP v6 moving forward, we have feel that this is going to offer our subscribers the best overall experience. No translation, no tunneling, no encapsulation, direct end to end routing or activity. At a bare minimum, when we first turned up our first couple of trial users, we minimally offered a slash 64. I know there's been a great deal of debate on some lists about the length or default nature of the prefix. But for our point of view, in the crawl, walk, run model it works, and we felt this was a reasonable place to start, and we can make adjustments as needed. But again, something that we felt was a good place to start. From a CPE point of view, if we had this session two years ago, I think it would be pretty safe to say that support would be lacking across the CPE space. I can tell you from personal experience, as part of the trial, that this space is optimistically growing. We're finding more and more CPEs that are supporting native IPv6. We find this encouraging. And we hope to introduce this variety of CPEs into our trials over an extended period of time. So the one challenge here is that this may not address the case where existing CPE in people's homes may not be upgradeable, or may require replacement to support IPv6. So trying to wrap up here, some of the observations we found, and this is one of the most significant ones for us, we obviously have a severe lack of content. We hear a lot of people talking about their plan to support v6 on the content side and we're active on that front, and I would encourage folks to do more of that work. While solutions are very straightforward to deploy, we found some latency concerns there, depending on what type of service you're trying to offer. And folks really do need to understand that there are non-trivial volumes of 6-to-4 traffic today. And we think it's very important for operators out there to seriously consider deploying their own 6-to-4 relays. And in the spirit of getting things ready, operators should go with what's available to them now. Get started. Really - don't wait until it's perfect. The advice here is, start now, start early, get your experience, find the bugs, get it fixed. You'll find that this is an invaluable experience and will help your v6 programs long term. Danny, thank you very much. Moderator - Danny McPherson The intent of this panel is to continue to increase awareness of the pending IANA IPv4 free pool exhaustion, and share operator preparedness experiences directly with the IETF and broader Internet engineering community. With a group of panelists representing commercial organizations from mobile, Internet registry, ISP and Internet access providers from around the world, and an express focus on constraints and challenges with IPv6 preparedness, deployment, IPv6-only experiences, successes, and constraints, the objective is simply to further inform protocol architects, implementers, and network operators on operational issues related to IPv6 deployment and coexistence with IPv4. Panel Presentation #2 - Matsuzaki Yoshinobu (IIJ) Hi, this is Yoshinobu Matsuzaki from IIJ. That's mostly based in Japan IIJ is one of the first commercial ISPs in the world, and today I share my operational issues more from a network operators point of view. This is mostly about routers. I like configuration routers of IPv4, based on longest (prefix) model, because it's reasonably simple. And I expect it the is same scenario for IP v6. But there are some routers that only support slash 64 or lower prefixes, and there are some limits on the PDU MTU limit. The IPv6 extension headers cannot be filtered based on protocol numbers - most packet filter implementations assume there will be only one header in the packet, otherwise the box cannot filter. This fact was unexpected for me. I was in a conference in Mongolia talking about IPv6 connectivity. There were questions on how to get IPv6 connectivity in that area. ISP cannot get native IPv6 transit in this country. On path MTU discovery, there is a great problem. Most routers have a limit of the packet size on the ICMP MTU discovery, and cannot forward because the packet is larger than the outgoing link. This is used as part of the discovery process, but most routers have a limit for ICMP generation, because the cost is still high for routers. And so this breaks path MTU discovery. In the IPv4 mode, the TCP MSS is widely deployed, mostly at broadband routers. I suggest router vendors consider TCP MSS for IPv6 as well. And of course, operators should check parameters about generation late to support passing discovery messages. I am not aware of users of IPv6 specs - u/g bit of interface identifiers are not on the menus, but the users can easily configure interface IDs by hand. It's another special bit of Internet IDs - I like to walk through the useless stuff to minimize the cost of network design. There is no use case for IPv6 subnet Anycast address that we can find. And finally, link local is a must, but in some cases I'd like to disable this on specific interfaces, like the Internet or inter-ISP links, to minimize the security risk. Moderator - Danny McPherson Thank you very much, maz, for that. So I think next we have Madam Zhao from China telecom, very own Beijing. And then actually because of the short order of this, Mr. Chin from the same organization is going to join us on the panel for the Q and A side, but she's going to do the presentation part. Thank you. Panel Presentation #3 - Madam Zhao (China Telecom BRI) I'm very happy to have this opportunity to talk about IPv6 operation and transition issues. Broadband service is really developing very fast in China, following China Telecom, we have 64 million broadband subscribers in operation. So we are facing a lot of challenges right now, especially in quality of service and security issues, but most importantly is the lack of addresses. We think for wireline broadband service we have 1 million, and 21 million for the mobile. By the end of 2010 we need 30 million, and so we face a gap of 20 million addresses. For a lot of new service, new applications, will still need several billion new addresses in the next five years. So facing this issue, with China Telecom and the University, we jointly established a lab to study the current existing IPv4 network will transition to the future IPv6 network. There are a lot of technical issues. For IP address issues, we think there are 4 options. One is for IPv4 optimization - how to raise the efficiency to use the IPv4 addresses. The second is using private IPv4 addresses, but we don't think the NAT solution is a good one, but it's a temporary solution. And one option is IPv4 address purchasing, but it is not a good solution to do that. We think IPv6 is the best solution in the future. So actually, for China telecom, we have already done a lot of practice on IPv6. We joined China CNGI, the big national project trial. We also did two provincial trials, one in Hunan and another in Jiangsu, to do the end-to-end IPv6 trials and make the network ready. Network operation system, billing system, service platform terminals, and evaluated the transition technology, like stacks and also tunneling and translation. Also, we provided IPv6 services in the Shanghai Expo, and we are going to provide it to Shenzehn for (upcoming) meetings. And we think there are several option in technology to do the transition. The transition technology is a pretty important one. So first is two-stack, that's a classic one, the mature technology, but the performance is facing challenges. But for NAT 44 we think it's a lack of Carrier Grade NAT and also challenging for large scale deployment. And this slide is one of the options. We have a lot of discussion and study on that. Right now we have Hunan province already have this slide technology tested, and successful completion. We think there is still a need for some private IPv4 address, and the gateways need to be upgraded. But we think this one, positive solutions, but it's a complicated one also. But there are some other ones we are paying much attention also, like IV I (?) we jointly study with the University, and 6RD and some new ones. So actually, perhaps we finally need a cocktail method, combining several tunneling and protocol transition methods, in order to meet our market requirements. So some options and some consideration is that one is using the private IP v4 address dual stack, and the other option is we use transition policy, deployment in some mature, especially for what we call MAN - Mature player Area Network. So, gradually to make a pure IPv6 addressing. So we think IPv6 network evolution technology will depend on the application and the requirement from the market. So, we really hope that, especially in the IETF studies, to make a good progress in the IPv6 transition. Like to help the carrier and operator, and give some reference for the network transition from the IPv4 to IPv6 successfully. Okay. Thank you, for your attention. Moderator - Danny McPherson Thank you very much. For those of you that saw the earlier slide I put up with APNic running out of address space first, I'm sure her numbers for 30 million addresses within 18 months or so are right, and that they only have about 10 million, so they're going to be 20 million short. Do the math. That's not hard. Next, I believe, Xiaodong Lee. And if you would come up next, I think the order is slightly reversed so if you would please come up. Panel Presentation # 4 - Dr. Xiaodon Lee (CNNIC) IPv6 Operations and transitional Issues � from NIR and ccTLD Operator This talk is about IPv6 deployment. This picture shows that interest in IPv6 allocation in China is very slow. I thank Madam Zhou and China Telecom because they took the lead for the trial system. You know, because we are facing the Ipv4 exhaustion and deadline, so we are doing many promotions and propaganda in China to let people, let carriers and users promote this issue. So we also give very strong strength to government to coordinate the deployment of IPv6. So, I'm very happy to see this picture. I hope next year or in the year after next, that some v6 address application in China. But, even if more globally. But the exact number of IPv6 address is also very low in China. So, I want to share with you some experience about .cn and four IP v6 allocations. As NIR and ccTLC operator, CNNIC provides IPv67 services to Internet community, not only for China but also globally. In six years ago, I still remember the date, in December 23rd, they provided IPv6 resolution. We enabled two nodes about .cn to support IPv6 resolution. And among the .cn and .china, three of them support IPv4 and v6, which are located in Beijing, Hong Kong and California. But, it's a pity that even though we enable IPv6 resolution, the number is very low. In two years ago, we enabled the registration for who is serious for IPv6 transition. We opened registration, we saw for over two years, but the current number is very low. Even though we open the IP name resolution, we only saw 1 allcoation in 2008. For the whois, you know, the whois very important for registration, they only less and than 20 per hour. Even for the home page it's 15 queries per hour. I guess many of those queries are from machines, not from human beings. I think that what's the story behind this? I think that that means that no strong requirements for the v6, for users to use v6. And maybe we can all, we can see that almost no requirement for user to use IP v6. I think, it's very depressed. But, I think, the reason for this is because the user, they don't care what is IPv4 or IPv6. They only care the application. They don't care what kind of internet protocol they are based on - whether it is IPv4 or IPv6. So the key point is that, the killer issue is the applications. This picture shows you the IPv6 DNS resolution for .cn. You can see that according to the blue line, it's the curve for IP v4. But the green line is for the pure IPv6. Up to now, there are over 1.6 queries per day for IP v4, but less than 6 million queries per day for IPv6. It doesn't mean that the queries are from the network, so it's less than 6 million. You can see there's two curves. The blue one, in the early morning, it's lower. But in the afternoon, it's higher. I think that is because the query is from the human beings. But you can see the green line, the green line is much more flat than the blue one. I think that even though there's 6 million queries from the pure IP v6 network, but I guess that so many queries are from the machine for testing it, for trial system or other reasons. It's not from the real queries of human beings. So I think that is very interesting. This slide shows the rate analysis - you can see the first picture in the left side, for the current population, here, for IP v4, there's so many client population from Asia. But for IP v6, we are not, from the analysis for IP v6 queries, they are most of the queries are from America and Europe. You know in China, we have a very big IP v6 network. Also, the China government issued national product for next generation internet, is based on IP v6. But, for the current client population, the client population for IP v6 is distributed in America and Europe mostly. That means that, that so many users and so many IPv6 applications in Europe and America compared to China. The analysis of the IPv4 queries of DNS are approximately 80 million. The host and client software has 41,000 IPv4 You know that compared to the IPv4 servers, the IPv6 are much lower. We also ping the IP v6 service to find what kind of service they are providing. Mostly it's based on HTTP, but you know, there's so many fantastic applications in the internet, but they cannot find more interesting applications in IP v6 networks. This is the last slide, but I want to give you a conclusion about my transition. I think that even we have so many promotions for IPv6 networks, and to tell them that IP v4 address will be running out in the next year, but no people pay more attention about this issue. So, now I have strong opinion for carriers and stakeholders of internet. We need more IPv6 applications - if no applications, I think there will be no IPv6. Thank you. Moderator - Danny McPherson Thank you very much, Doctor Lee for that. Absolutely, I think that the fact that IPv6 doesn't benefit from those sort of network externalities, lower layer and higher layer, are certainly one of the challenges. So I'd now like to welcome Bill Huang from China mobile, to talk about their experiences with IPv6. Panel Presentation #5 - Bill Huang (China Mobile) I will use just 10 minutes for our IPv6 activities. As has been discussed earlier by a number of colleagues before me, IPv6 has been a long and multi-year plan, but never seems to have materialized into deployment. Just looking at 2010, a number of activities that we have set up, including hand set trials, backbone, service network layer, core network, including directly on the IMS, as well as a number of tests on hand set. So our view is, based on the result that we have seen, the fact that many people are talking about IPv6, doesn't really mean that we are ready. Unfortunately, there has not been a very wide deployment in general, so a lot of problems are only starting to be uncovered. And that, in fact, reflects the reluctance by operators from moving forward with deployment. One of the biggest issues is application compatibility. No one can say for certain that if we provide an IPv6 application enabled hand set to some customers, that this customer will be happy. And that I think is the reality of the problem. So, in some ways, the IP v6 problem is becoming a very pressing issue. But the pressing issue is not addresses, and that is kind of sidelines of the grand vision set forth originally by IETF for migrating to IP v6. I mean, we're talking about solving address problem with IPv6. But in reality, IPv6 transition has a lot more to it. But what is that? And, they're seeing not being able to get that confidence that we can migrate. If you look at some of the detail issues, one of the issues that is associated with it is, when you perform testing on many different routers, and some of the routing, just couldn't run without having IP v4 as a foundation routing protocol. In other words, if you configure a pure IPv6 network, in reality, you couldn't configure it. You have to have IP v4 kind of at the bottom. And then, there are issues with packet filtering, to be supported, you know, you have relatively uniform way. And then there are protocol issues, you know, detail protocol issues that have been mentioned, the fact that the equipment has not been used in end-to-end situation. And then, the service platforms, in some ways, if we are to migrate on the network, that is actually the easy part. The more complicated part is, the service platform that have been built for many years, how do we migrate the application code, how do we migrate the platforms and servers which have been you know, running essentially IPv4 environment? And last, you know, if they are requirements with which we'll have to come back to IPv4 environment, it's not enough testing to provide a certification or a guarantee that the 6-to-4 translation can be done in all applications, can be done correctly. See, it has a lot to do with the issues of certification. And how do we find a way to pre-determine that? And when that happens, what would be the process by which to resolve it? So, then of course, on top of that, there is a very large transition with which we will be migrating to new types of the real network. So the timing with which to conduct the evolution is very critical. And we feel, you know, on the 2G and 3G networks today, most of the networks today in the world the time of the evolution of the network (2G and 3G) is short, and including China mobile are already operating on top of IPv4. But there's a very strong opportunity for us to move to the next generation network. In LT, with IPv6, we have a very strong opportunity, and we hope to use that opportunity. Another very important issue, one I'm bringing forth is, over the next three to five years, the network is going to undergo maybe 50 to a hundred times of growth from a mobile communication point of view. And that represents a very big opportunity. Now, most of the operators that we talk to are planning to offer two stacks. But, the question is: Is dual stack enough to provide the migration force to IP v6? From the analysis, we will know that users really do not care what network they're running on. So, if a dual stack network is provided, more likely than not, the users will be defaulted to IPv4 operation to avoid complaints from the user. So as a result, even if you offer new terminals that have the ability to provide IPv6, more often than not the majority of the users will be continuing to run their applications on IPv4. So a dual stack network, in reality, will be operating primarily by default as IPv4. Which actually reduces the dual stack network into a single stack network that we do not wish to keep over time. So the idea set forth by tell mobile and along with a number of other partners, in March this year, we meet in San Francisco, is to promote traffic steering, is we need to develop protocols proactively within IETF, to either translate or tunnel traffic from IPv4 networks to IPv6 networks. And operating the IP v6 network as the primary transport network for the internet traffic. So this effort we call steering. And there may be other mechanisms, PIH or using DSlight, as the primary mechanism and protocols for doing that. And the result is that we be will be able to see more and more traffic being steered towards a pure IPv6 network. And if we equipped new generation of terminals with these types of technology, then it is very likely we can set that as a default so that, by default the traffic will be steered. Applications are completely invisible. So, whatever applications the customer is willing to run, whatever applications customer is used to be running, they can keep it. They can even restore it from their back up. You know, which is more often than not, what the people will probably be doing. They can re install applications that they previously ran, and then, in the new platform they will continue to run. I think that is the very important strategy to create a dual stack network, but with a bias to steer traffic. And then of course combining the effort in IPv6 together with the development and deployment of LT, we feel now it comes to the point where we have to move fast, and quickly, to get the IPv6 issue to be on top of the agenda for the LTE, and for the emerging flat architecture of next generation mobile network. So if you look at that area, then, clearly, the 3GPP and IETF should work together to find a way so that we can promote the IPv6 deployment in LT network. Moderator - Danny McPherson Thank you very much for your comments Mr. Huang. I think one of the things that I appreciate in this presentation is the the recognition of end-to-end, and the notion that as Madam Zhao put it, it's going to have to be realized during deployment and transitional co-existence, and at the end of the day, end-to-end is ideal from an application perspective - otherwise it's extremely complex. That said, to end this bit of the presentation, Jari who many of you know is the Internet Area AD, is going to share 134 remarks on IPv6 only experiences, as opposed to the transitional co-existence model. So with that, Jari, if you want to come up, then we'll step into the Q and A in just a moment. Panel Presentation #6 - Jari Arkko (Ericsson) So I wanted to talk about state of IPv6 only networking. And this is based on some experiments, or trials, or network deployment that we did at Ericsson. It's of course not the only deployment of this kind or trial. As you know, like Mark Blanchard has been doing some tests at the different IETFs. If you haven't tested the iet.nat64 network, you should probably give it a try this week. So what did we do and why did we do it? So the motivation... Our sites had been in dual stack for a long time, over ten years, actually. And very clearly, we had to do something else. And seriously, though, it's obvious at least to me that at some point someone will have to move to IPv6 only networking. And we also had some customers, and they were talking about this in very serious manner, so we figure we would like to understand what's going on and what are the impacts, and then it will be possible to tell others as well, provide guidance on what the impacts are. So we had several goals. Work out what actually is running well, and what is not running well in this IPv6 environment. We also wanted to build an understanding so that we can actually recommend IPv6 only in these type of situations, or dual stack in other types of situations. Of course, we had some products implementation efforts going on so we wanted to test those. And before going into the actual experience I just wanted to do a small detour, because I guess I didn't want to give the impression here since I work in the industry, that that is only about IPv6-only. This is actually multiple different deployment models as noted by Bill, there's not that much deployment today, although it is starting and we actually see a number of operators, big operators doing fairly serious efforts that are probably going to be more visible in the year or two to come. But, so what they are doing, is basically - the base has had both standards and products, at least on the network side, up and running for a long time - from like 2003 or 2005. It's been working in the phones, but some phones do and as long as you're not going to a v6-only model - dual stack or something like that, you could actually start today. And in most of the work, there's no imagine I can to it. You just have to set up all the peering and networking and all kinds of things and operational issues have to be taken care of. Of course, some of the operators are looking at various types of improvements. We've added prefix delegation and other products in recent months for enabling home routers for instance. The IETF has nat 64 which makes it possible to do IPv6-only. And of course, there's multiple different use cases, so different operators are looking at different things. Some look at traffic to the internet from the end user to the internet. Some are looking at traffic for the some of their own services, which of course it's easier to change because you're in charge of both ends of the communication, and some look at the signaling network which has nothing to do with end user traffic. So different use cases and you can do multiple things as well. We had three sites. We did not have thousands of users. Only a handful. We involved a network, our home users, and Jari's home. We actually built networks and retained the v4 networks for tyhis. We did a nat v4/v6. We did do a permanent change rather than day or week experiment. And, we are involved with mobile users, we involved part of our lab network. At Ericsson research in Finland. I converted my home to IP v6 only. What we said, we basically built dual networks for this. In all cases we need to retain the dual stack. Some devices that were not capable of doing this yet, but we added nat64, didn't 64 behave specifications, and it turned out pretty well. Lots of things work extremely well. I left the IP v4 internet Browsing works very well. There's a theoretical possibility of running into IPv4 literals in the net, but in practice I have, in six months, have only run into two that mattered. And even they did not matter that much. So, it's really good experience. E-mail, software updates, test systems, streaming music services, lots of things worked. So, it's, actually we didn't see a lot of difference. Some hand sets you can get to a hundred percent functional, because they're a little bit more general-purpose computing environments. Some internal environments though, so not many people have done this before, so, there's some, you know, we've seen issues where the operating system was not tested well enough. Usability was not perfect. Mac for instance, you have to do a manual transition. Some applications fail. I'll talk about that in a moment. Some appliances do not have IPv6. We had firewall issues. Even if the firewall supported IPv6, maybe not all features. So just to give you an example in issues of in applications the two areas are messaging or VoIP and then gaming. We did some testing. Messaging for instance, anything on the web, or XMPP, it works. No problems. It's all great. A few other systems are a bit more problematic. Skype was actually the main issue for some of our users who could not enter the trial or the arrangement because they need to use Skype and it doesn't support it, at least directly. All six of these things can be bypassed by proxy configurations but we did not do that. Gaming -I was doing some testing at the beginning of summer when my kids were out of school, so I connected their computers to the v6-only network and had them test everything that they had. And it wasn't a very positive outcome actually, because like most web based things do work, but then other games that have this network mode or LAN mode don't do anything in v6-only. So anyway - some high level observations at the end, from a point of view of the end user or application OS on the host, I think we should still keep on recommending dual stack as the preferred mode, it has the least amount of problems. We can recommend IPv6-only as well. particularly for early adopters, mobile networks. We see pretty good results with hand sets - anything where you have lots of control. Tomorrow you can do that perhaps for everyone, all kinds of environments, but some work is needed. I would actually like to make a call for action. We need to do this, you know, it's not a continuous effort. It's mostly a one time effort. We need to fix bugs and applications, and we need to do a better job at DNS discovery. And, you know, I think there's lots of people in this room that could help, maybe Stuart can help with some of the Mac issues. I don't know if Jonathan Rosenburg is here, he should fix Skype. We've done some work with Android. This phone has support for v6-only and discovery. There's things to do, but we really need to go and do it. Thank you. Moderator - Danny McPherson Thank you very much for that. I think a couple of applications I didn't see there were the IETF data trackers, for those of you that haven't heard from Jari in six months or so. That might explain it. So actually, I'm pretty impressed with the content of the folks that are sitting up here and you know, they pulled this together in just a couple of days to share their operational experience. I would ask if Mr. Chin from China telecom would like to come up to the stage too, if he's here, to join us. If you'd like to join us, you're welcome to do so. We're going to move into the Q and A session. Since I'm moderator I get to ask the first question and then I'll open the lines again. I would observe, I guess, that the internet is at an inflection point - I guess it's always at an inflection point - but right now a particularly critical one, where we have DNSsec, and internationalization, and IDNs and you know, some secure routing work occurring, and certainly, you know, IPv6 deployment and transitional co-existence with IP v4, and it's important that the feedback from the operations community is did duly considered, and that we adapt to accommodate requirements from those folks. Q & A session. Q1. Danny: So given that most of their presentations were very much on point and exactly what I asked for, I'm going to ask a question of each panelist, and we can go down the row here. But rather than being a technical one, from where you sit in your organization, what do you believe is the most impressive discussion you can have with management to encourage them to take notice of IPv6 when there may be no direct, top line revenue opportunities that they can use to qualify return on investment for IP v6? Basically, many of you early adopters are certainly leading the pack with regards to IPv6 deployment, and preparedness and experience. So how did you, how would you recommend if you were giving advice to other operators, network operators or enterprises and so forth, to encourage their management to take note - and sort-of the time window and urgency of that. So I'll go right down the line starting with John - if you'd like to comment on that? John: So, Danny, from our point of view, one of the main things to point out and note is the business continuity aspect of IPv6. For us, we've been at this for over five years, and we've been able to do this over time and minimize disruption, and see the cost and effort over extended period of time. So we've been able to deploy and support v6 from that point of view and make it less painful. But after the day is done, it orients around making sure that we can continue to support the business moving forward. Danny: Okay. Thank you, John. I know Jari, you're on the lab side, and you get to do things that don't have as much of an operational impact, but what's your view? Jari: I work for a vendor so it's easy for me to motivate my management. Because basically the customers are asking for this. They are asking for the v6 support and our advice on how to get it deployed, you know, everything they're screening for this. So it's very easy for me. Danny: Okay. Mr. Huang? Huang: Well, I talked about this a little bit earlier. Engineering side of operations are very much into migration, because we see the danger of exhausting addresses. And as well as, I mean, even if we are using private IP addresses we have a huge problem in managing the scale of the network, especially if you consider the number of users that we have, and the size of the network. But the issue has and will continue to rest on what types of guarantee that we can properly provide to the management that this migration will be smooth. It's very much like inter-operability between 2G mobile 3G mobile networks. So, I continue to see that problem, and I continue to believe that we need to do more at IETF, to drive home that message. Danny: Okay. Thank you. Dr. Lee? Lee: I mentioned in my presentation, my concern includes two issues. One is the business models of v6 transition. Another one is about the application of IPv6. So the first one, for example, in some years ago, so many people switched to internet phone instead of the traditional one, because it's cheap, and it's very cheap, it's also free. But, so many people ask me that, why I use v6? Why do I need transfer my application from v4 to v6? What's the benefit for us? So, I had no exact answer for this problem. So, there are no perfect model for this. Another one is, I don't know so many leading companies have v6 applications and provided so much application content in the applications network. But, even I think they have no motivation to use the v6 network, because they don't care what kind of network they are using. So, I think the application or content is the best model for the concern. Danny: Thank you very much. Maz, what about your perspective? Maza: As we are hear in IETF, I like to emphasize about a simple and useful spec. So, that's it. Danny: What is your Concern Mr. Chin? Chin: My concerns, there are several issues that we must face. One is, which service should be first migrated to that IP v6 network? Perhaps IP VPN for v6 is a first service. Another is ITC, and, we still have some CDMA and wifi combination service. So, another issue is how to provide a seamless user experience for the customers. And the issue is how to upgrade our large network. But we have both a channel for my state public users, and enterprise network after CN-2. Which service should be located, which network must fit? Danny: Thank you, Thank you very much speakers. I see a couple of folks standing at the microphone. So if you want to make a statement or ask a question, please be fairly succinct, we do have another session after this, but I welcome any comments from the floor. We're going to start over here - state your name and question or statement please. Q2. Dave Harrington: I am an AD in the Transport Area. My background is in network management and I'm curious about whether the network management applications are working for IPv6. Somebody, one of the presentations mentioned that the different vendors have their own IPv6 MIBs and they're not in operable. And I'm curious whether there are standard MIBs for the things you're trying to manage or whether they're using proprietary MIBs even though we have standards. Or whether they're using them because we don't have standards. I would be interested in understanding whether the network management applications that are frequently used that are based on standards are working properly or not. I'm seeing lots of discussion of gaming and Skype but I'm not seeing a discussion of the network management tools that are going to be so useful, I would think, to the operator trying to manage the transition. Danny: Excellent question Dave. Anyone? John: So this is John Brzozowski, from our point of view, we've seen that there's deployable support from a network management point of view. All of our NMS and management support are IPv6. We find areas where we find bugs, or little nuances is in docs. Different implementations in the outer most edge of the network is where we find opportunities to make improvements. But otherwise we wouldn't be able to roll out in production if we didn't have our items ironed out. ??: It all happens when you take the routers for testing, and you will see that from vendor to vendor, implementations are different. They are different to the point where you cannot use a standard set of procedures to operate them. In other words, a single script would not work. Danny: Yes, I think that's certainly an important take away. To find parity and certainly to employ standards in a way that it eases deployment is critical. Excellent question. Q3. Peter Resnick: Danny's question went to the carrot and I'm looking for the stick. It's one thing to ask, you know, how do you make this palateable to folks? How do you make not switching painful? As much as I love Jonathan, it is just absurd that Skype doesn't support v6. How do we cause Skype pain for not supporting v6? It sounds like nat 64 and a couple of other tools would make this pretty reasonable, if folks on the other end, folks on the server end were made to have some pain. How do we generate that pain? Danny: Thanks Pete. Peter Resnick: Break it. I guess is the best way to do it. I hate to put it that way, but as much as I don't, I don't really want to do that, but I think what will happen naturally, and I think folks here in the room agree, things like NAT, or one of the other things, they're going to pop up sooner rather than later if they have not already - some places, and as those things do, applications will break. And I think one of them may be something like Skype. It's inevitable... Jari: Just to kind of stick in a comment there. Yeah, but all of you sat up there and said, we're doing everything we cannot to break anything. I actually do agree with John, that, sort of causing pain or breaking their applications, or some particular application is the way to go, and I mean, for instance I contacted Jonathan about this Skype issue, but I'm just a researcher, an IETF guy, but maybe my colleagues here from some large operators would have a bigger say in that, because obviously, they want users. ??: Well, I think it's a very interesting view, but I would say that's a little bit more academic, because if we cause pain to applications, what that simply implies we cause pain to our customer. We have total number of complaints, just think about that. Imagine. Specifically on the Skype issue, I think we have to realize that Skype is peer-to-peer protocol. So, there's absolutely no way that a Skype can do an IPv6 change by themselves. Their peers have to do it. If the peers do not change it's not going to happen. Danny: I heard the challenge for Skype. We're going to close the microphone lines now and we have a number of folks lined up. If we can keep comments and responses fairly short. Q4. Dave Crocker: Jari mentioned a list of problems. The convenient one people are mentioning is Skype, but there was a list there. Another list got added with operational issues and MIBs. It could be very helpful to the community to keep track of these, we maintain issues that, for work activities on a WIKI. Change control, or problem bug tracking is a common tool. It seems to me that, and it had not occurred to me when I got up to say this, but it may also be responsive to Pete, that if we start keeping track of systems level issues that are not working properly, that need to be corrected and identify them, just in a straightforward fashion, there's a public record of what work needs to be done. I was intrigued to notice last year when we put up the outcomes WIKI, how quickly I was contacted by the press. Danny: Fine observation, Dave. I think shining a light on brokenness is motivator. Q5. Dave Harrington: I would like to understand what the IETF can do to help solve the operational management problem. If there are IPv6 being done in a standardized way, do we need to modify our standard to make it better for the vendors to utilize our MIBs, or are they simply not doing it because they are using such a different approach that our stuff doesn't work well? ??: First I would like to reply to how we can improve the network management. I think one of the best ways is to have more operators to test or deploy, and understand what the network is missing, and then they can come back here to standardize now. So that's one recommendation. So that's just that operators need to do something, and then we can do follow up. And I come here with two questions, to Jari, especially. Jari says he has deployed it for a long time and then he turned on today he goes to IPv6 only. So he has done a lot of things. So the first question is, what's your conclusion? Do you think, do you think it's a better way, or is the old way better? Second question is, I guess the experiment, what's the difference between what you did compared with T-Mobile? Thank you. Jari: So, T-Mobile indeed has been running some experiments or trials, and their trial, it's a slightly bigger scale, and it's particularly on the mobile environment. We had other environments as well, but their tests parallel out efforts, we're not trying to differentiate ours from that. That's a major effort that they're looking at, and then on the dual stack versus IPv6-only, I think we need to go to IPv6-only. The question is only exactly when. So I wanted to go there early so I can understand the problems. I'm still personally recommending to people that in general computer environments that they should probably still stay a while in dual stack, because just by counting the number of problems - it's not that we don't have any with dual stack, that too has some issues - but I think there's a little bit more now on v6-only. But hopefully if we execute this action plan, then a year from now, or whatever it is, there will be less issues and then we can actually all switch. Q6. ??: So I think we had 3GPP channel gnaw in March. And so, in that workshop, in the second week, discussed you need run dual stack, but that means they have to, that's kind of a slow proposal. Right? So you are saying IPv6 only depends on timing. If you want to do IPv6 only that's one solution. But it seems like we are getting around signaling? Q7. Fred Templin: One thing I didn't hear is anybody talk about provider independent versus provider aggregated IPv6 prefixes. If I get a prefix, I'd like to represent it to my cable and cellular service provider or ISPs that I have. But I have to convince my providers to advertise that prefix in the routing system, which is not likely or scaleable, or to tunnel across the provider. That being the case, that suggests that tunnels, if we're going to have provider independent addressing, are going to be long term service. Which means that tunnels should be done well and properly the first time. Are there any comments about provider independent addressing? John: So, Fred, the only comment for now that I can offer is that the vast amount of our trials are still on provider-provided address base. And so as things evolve, perhaps we can talk offline and get some more feedback, but at this time the vast majority of our activities are based on address space we provide. Keith: Jari had a presentation where it contains basically a number of applications. And the comment that I have is that what he didn't tell you is that most of those on the gaming side are using exactly the same engine. Another thing that is on a comment level - if anyone thinks that IPv6 is roaming in that particular area today, I disagree, because I'm doing it just as we stand here and speak. I'm running basically everything on 3G here in China, roaming over to Sweden. So everything that people are discussing here are special applications, and there was a suggestions for a list, and we can call that list whatever we want. Put the applications on that type of list publicly, so the application providers are forced to write applications in the right way. That means IP independent. Use naming, no addresses, as an example. SIP has the same problem. Sorry to say. So we need to act a little bit faster. Get the list up, get it publicly published, and we can get the guys over. And I'm testing also Chinese applications as it is, to get this list running as fast as possible. So, question mark over to you, can you by yourself, or together, put the pressure towards the application providers, then we will get the result. We haven't able to, ditching their total infrastructure. So, question mark again. Can you help in this progress, I would call it, the work, that would be very beneficial. Danny: So, I think again, that's a great observation, and certainly not to speak for Jari here, but I think that list was not meant to be conclusive by any means. It was his experience, but I believe that highlighting applications that need work is extremely important. I think ISOC has done some work on that. And if you have ideas about the right venue for that, we certainly welcome them. Any protocol issues is IETF, and beyond that it's ISOC. And I welcome your input on that discussion. Olaf is telling me to close down. Jari: Just a quick comment on the applications issue. So, it is indeed true that there are classes of applications that are based on the same pieces of software libraries and tool kits and such. And as we are addressing these problems, then you know, fixing the tool kit is the fastest way to get there. So obviously we would go there first. Tina Tsou: Okay. In my slides, I talk about the propose of errors, to some of these questions. The proposals are for different scenarios - about whether your access network is L2 or L3, whether you are lacking of IP addresses. Before you make your selection, you have to make sure to understand yourself, to operators, whether you want to protect existing investment, or you want to guarantee the existing users experience, and you want to push the development of existing service, or push and encourage v6 deployment. You have to draw a list on paper, see which is the most urgent and important part. Danny: Thank you. That is Tina Tsou - her presentation is on the web site with the rest of proceedings. We didn't have her on the panel. John: Do you have question? Tina: I am just trying to answer the earlier question. In my slides there is also some P2P applications. ??? (from Cisco in China): So I have one comment - since I work with content provider in China, we all know it's very important for them to start to move to IPv6. I find one of the frustrations they have, basically, they don't have a lot of knowledge about the protocol, the network, and how it's going to work. And they normally depend on the network provider - what kind of solution or what's the current status - they depend on that to make a decision. So, often the people here, or the service provider from China telecom or China mobile, they value a lot of technology, IPv6 RD, NAT, all of those kinds of technology. Really confusing. They're thinking, we all know, you know, but it's very complicated from the access part, right? We need a lot of variation. But my point is, when we talk with the content provider, we need to decouple the dependency, otherwise it's very confusing. So I think it's very clear, we should streamline the action items for them. You know, do IPv6 right. So now, we should have a solution to sort of solve all the access problems. Once they do that for IPv6, doesn't matter v4, v6, dual stack, whatever. We should make their access work. That's all we need to do. All right. We have confused them, it's not that they don't want to move, they just don't know how to do it. Too complicated. So that's my suggestion. Danny: Last question. ???: It's rather a proposal, or a suggestion. Seriously speaking, I understand the problem. I understand that we do need to move to IPv6, and seriously speaking I can say that the solution for this movement, or change to v6, is very difficult. It's an outrageous proposal - I would like to define IP certification procedure. Danny: All right. So, I had intended to exhaust my Chinese vocabulary and open up with knee how, so I can certainly finish with she she, so, thank you all very much for your efforts in pulling this together quickly. And I think we're on time. So I I'd like to thank you and now the IAB members can step up for the IAB session. Thank you very much. Olaf: We now have the IAB open mic session. As I requested on the mailing list, we, I asked for questions so that we could prepare answers and you could prepare your questions in a succinct way. I have not received any, but that doesn't mean that the mic lines are closed. If anybody has something to bring up at this moment, you're most welcome to step up to the mic. If not, we're going to keep this extremely short. That means one of two things, either you're not paying attention to what we do, or we do it very well. That's a joke. It means that the IAB members can leave the stage. It also means that we are going to enter in a session that is about the RFC editor model. This is a presentation about the model, and a Q&A session at the end. I would like to invite Glenn Kowack to the stage. People who are not very involved in this have the opportunity to leave the room now. And people who are more involved in this, please move forward. While people are moving out and Glenn is walking to the stage, I will give a small introduction about the context of this discussion. This is about the RFC editor model. The RFC editor, which is a conglomerate function, it's basically everything that we need to produce RFCs, is an IAB oversight responsibility. That means that we are, we're managing the sort of processes that lead to improvements, and so on, and so forth. About two years ago we started a re-organization of the RFC organizational structure. As basically as one of the final stages in the restructuring is the relations that the IETF has with its 'service providers'. We had a long process in which we defined a model. That model was published in RFC 5620. In December of 2009 that RFC came out, consensus was found a little bit earlier than that. The RFC editor - the model makes up for four components, what we previously used to call the RFC editor, which was basically one function. Those four components are a publication house, a production center, I mean, a publisher - the production center are the people who edit your documents. The production center is the body that publishes those documents online and maintains an archive. Then there is the independent stream editor person who maintains oversight and manages the contributions made on the independent stream, which is one of the streams that result in RFC publications. The other three streams by the way are the IETF stream, the IAB stream and the IRTF stream. And then there is a leading component in this conglomerate that is called the RFC Series Editor. So this is all in RFC 5620. We implemented this model a year ago and I've been reporting on this process a couple of times before. The production center was hired and the publisher was hired, and these functions are housed within AMS. It's the same service provider that does the secretariat services for the IETF. That went through in a fairly timely fashion, except that for the third component. Also, we appointed Nevil Brownlee for the Independent Stream editor. But the timely hiring of an RFC Editor failed for several reasons. We went back to discuss this among the IAB and decided that we wanted to have a Transitional RFC Series Editor, and the main reason for doing that is to get running code - to actually understand what are the needs, how do we make a job description that will make the job attractive for the people we're looking for, so we can actually find people. So, the assignment for the Transitional RFC series Editor was to do the job, and in the meantime, document experiences and come to a recommendation with possible changes to the RFC series, and to the RFC editor model in RFC 5620, and make recommendations about the job description. And there by clarifying relation, authority, responsibility and the hiring process so that we would have a better chance of filling this position for the long-term the next time around, which is coming very quickly. Where are we now? Well, there are recommendations today. The recommendations have been posted in an internet draft that appeared shortly after the deadline, after the internet draft cut off. Apologies for that. And Glenn will present those recommendations today. The next weeks, and the time is clicking, is ticking, Glenn will collect input and feedback and will facilitate work towards the consensus. It is the intention of the IAB to determine whether a consensus is emerging around this. In that consensus is there a direction, and it's clear that things are making progress? If we are probably on track. If not, we work on alternative timelines with respect to fulfilling a permanent position, which we have targeted for March of next year. So if no consensus is emerging, then we'll look for alternative timelines - and we have plan A, we need a back-up plan, a plan B. I will give Glenn the microphone in a minute and he will provide motivations for his recommendations. After that, we'll have an open microphone, with questions and answers, clarifications, and a discussion of the model itself. I will be moderating the discussion. And Glenn's role in this part of the process is very specific. He is here to explain his recommendations, and give his motivations for those recommendations. But it is also his task to record your suggestions and the reasons for changes and improvements that you make. So, this is creating an inventory of your opinions, about the recommendations that Glenn has made. And so, after having said that, without further a do, it's time for Glenn to come up to the mic. Glenn Kowack So, on March 1st I came onboard to act as transitional RFC series editor. Preceding me by two months were members of the AMS and the publisher, and Nevil Brownlee as Independent Submission Editor. So I came on board a little bit after the model started running. But now I've been onboard for over eight months and see all 360 degrees of the operation of the model, and that's model version one in RFC 5620. Now I've attended this is the third IETF meeting, and I mention that because it's quite important to be able to see the cycles of the editorial process that tend to be punctuated by the IETF meetings. And I've been involved in the escalation process, a lot of queries coming up from the publication center staff. I have fielded many questions, and have interviewed probably around 50 or 60 people directly, at various IETF meetings and over the phone, and talked to many dozens more in e-mails and otherwise. So at this point I'd say I've had a chance to do a good survey of the overall scene of the RFC editor, as well as participate in discussions with other members of the editorial team - in particular, Sandy, Alice and Nevil Brownlee. Before going into my recommendations, I'd like to step back and give you a report about what I've seen in the last eight months for the actual operation of the model version 1. And the answer is it works pretty well. The division of labor into the different functions of the RFC editor is effective. People seem to know where their job starts and stops, and where the other person's begins. They seem to understand what their jobs are, and in particular, the people in the production center and technical staff supporting all the activities, web site and so on, at AMS are doing a very solid job. They have great expertise, and their dedication and focus, in fact, are quite a mazing. In fact, I find it stunning that the staff is out at the RFC editor desk during these IETFs, and when they're not talking to people, they're editing documents - they waste no time. It's quite impressive. I think you're going to find that I'm making very modest and very few recommendations to 5620, and in fact I'm doing almost nothing that's actually new. Nearly everything fits under the heading of clarifications, adjustments and the like. In fact one of the things that's interesting - 5620 has ambiguities, and very often I'm selecting one particular location within the range of possibilities in 5620 because of the observations I made - that this one makes sense, and these other ones are problems. In other cases I made choices to disambiguate something because I wanted to force an issue. I will show one in a few minutes that's quite important. Finally, nearly all my focus has to do with getting the RFC series editor job right - the leading component of the model. My major observations are three, and the first one is that the actual day-to-day and long term role of the RFC editor demand expertise in technical publication and in the management. This is genuinely an editorial and technical writing expertise job. Number two, the RFC editor, the series editor, must listen to the community, and in fact must be responsible for getting that right. And three, the RFC editor, which is a set of functions - and by the way - the RFC series editor is a role within the RFC editor - just to make sure that's clear. The RFC editor 'set of functions' must be managed by a single person. And with no further a do. I'm going to go through each one of those bullets with more detail. Skill requirement. RFC editor - they need knowledge and experience in three areas. Technical writing, technical publishing, and technical series development. Technical writing is largely related around the area of how do you develop a document. How do you edit that document? How do you make sure the technical ideas are transmitted cleanly on the page? Secondarily, technical publishing - what does it mean to wrap all the other processes around that event. To make sure people can receive your work and understand it clearly, and understand the body of work as well. And finally number three, technical series development. Once you've started to get a few documents, say, 6,000, they start to take on these characteristics of their own, and they provide some advantages for the community, and end user, and those need to be developed within their own concept. Now, I point out these skills in the area of technical writing, publishing, and series development - and there's been quite a bit of debate around the question of 'does this person need to be a computer scientist?' Does he or she need to be a Jon Postel or a fraction. They need to have familiarity with the concepts and vocabulary of computer science and networking, because that's what we work with. And it's something our editors have a reasonable amount of expertise in, and the most senior manager in the organization must have insight into their work, but that is the extent of it. And I can say with a degree of confidence during my eight months as transitional RFC series editor, I don't think I've used my computer science degree from the University of Illinois once. I have had to know how the web works, and how networks work, and understand technical phrases in a document or a sentence or paragraph, but I haven't had to understand really the details of how a router works, and comparing BGP to OSPF or something like that. It just has not come up. It may come up among the staff - how to read and edit a particular line - but there's an important item that I'm going to mention briefly again. The RFC editor has nothing to do with the specific technical content of any single RFC. It's none of our business. We don't do it and we don't want to do it. So that means computer scientific skills are not required. They have a very... in other words, it's unnecessary, let's keep it out of the way. Second one, and I'm doing these out of order. Managing the RFC editor function must be one person. Right now, 5620 is a bit ambiguous, and it can make it look like different members of the model are reporting in different ways, or splitting overall responsibilities for the series. My observation for this function - it has to be done by one person because it has various interacting components that must be managed by one person to develop a consistent vision, optimize the parts, understand the different parts and make each individual one work. To have multiple cooks in this stew would be very, very problematic. For the community this is important, because this means you have one person to point to and say, yes, you're doing your job or no, you're not doing your job. There's great sensitivity I discovered in my interviews that we make sure the person genuinely represents the interest of the community, and that starts with knowing where their job starts, what it is, and where it ends, and a single manager is critical. They own the problem, they own the solution, we give them the resources and expect them to deliver. Furthermore, they're involved in the day-to-day work of the series, and it's a necessity for them to understand how to respond to changes as they occur. I want to make a point here. Every manager in every organization has their own level of day-to-day work. That generally doesn't include the level below them. That's also true in this case. The RFC series editor manages their work and delegates below. Let's go to the reporting structures - editor reports upwards to the IAB, and they work at the pleasure of IAB. That's a code word, what that means, IAB hires them, if they're not happy, they fire them. It's accountability. The production center and publisher, or entities and structures, will report to the RFC series editor finally, because there are some contracts that have been let, there's effectively a contracts department, and the RFC series editor has to coordinate to keep it moving smoothly. One point to be extended a little bit later - the independent submissions editor and the independent submissions area is not under the RFC series editor. They work independently. I'd like to touch on that more later. As I said, nearly all the work is delegated to the contractors at AMS, and the production center and the publisher. So, here we are. We, let us turn the clock forward, let's pretend the recommendations are accepted and we have an RFC in place. They are professional staff. They have the interest of the community and internet in mind, but they also have their interest in mind. How do we insure they put the interest of the organization first? How do we make sure that they don't distort the interests of the organization, even with the best of intentions, distort them in their favor and not the greater IETF and internet? Well, the answer is they are responsible for finding a balance between professional initiative and listening to the community. What I mean by that is that, they, day-to-day, as they make decisions about an element in the style guide, handling a question that comes up, talking to a member of the community, resolving an issue with outside organizations, in a very large number of cases they need to make a lot of little decisions and go with them. But on the other hand, there are things with wide ranging effects, influence the community, or will be difficult to reverse. It's key they find a way to act quickly, when the community doesn't care, and pay attention to involving the community to the extent necessary when they do. That's the job. I've taken the job of the RFC series advisory group, which has been doing this in the past, and I've expanded it to say 'you're also there to help guide the RSE, the RFC series editor, when the community would just be as well happy to move on and get the thing done. It's subtle, but important. On one hand we want the results, but we want the right results. Furthermore, the role is extended so that if the RSE is not paying attention to the community, they can somewhat more likely say 'you're not listening'. If they doesn't work they can carry it up to the IAB. So, those are the three core recommendations, those are the fundamental structural changes. They are subtle and not terribly massive in terms of the change of the overall model, but they have very wide ranging effects. Now, I've built an approach. I've made a few big changes and now I want to look to the secondary consequences. The first one is even though I defined the Independent Stream Editor as independent - it is an independent part. I'm making emphasis on this because there's enough ambiguity, and it's not entirely clear that the independent submission editor is part of it or not. And I'm not, let's put them clearly inside the RFC editor but let's put them in a bubble, they are untouchable by the RSE, but they're part of the editor function, that allows them to participate in the different activities but they have full independence. I want to force an issue. I could have choice even to say this is outside the realm of the RFC editor. That would have been slightly more change. But it's not as desirable. Because we've actually liked the way this has worked for the last eight months. It seems to be a highly cooperative arrangement. But there are counter arguments, and I think this is an important place where the community voice has to be heard. Let me say also I've been very impressed with the output of the independent submission stream, and I think it's both of vital part of the overall work of the IETF, vital contribution to the series, and I kind of like having it inside the editor. It's fun there. So, another item regarding RFC series continuity and quality... 5620 already calls out responsibility for quality and continuity by the RSE in the series. But I've added detail, if you like to look at the overview document published last week, please do so. But I want to say, continuity is expanded - in a definition that talks about *series* continuity. The series should not change arbitrarily, but rather should be smooth. And there's operational continuity. As Bob Braden said, 'keep the documents moving'. That links into work by the series editor to make sure that the style manual and the procedures manual are up to date, so should there ever be an accidental breach of service, or discontinuation of service, they can pick up the documents and hand them to another organization or team of editors and keep the documents moving, which protects the community from any kind of disruption which would be highly undesirable. And 5620 only mentions this, but I call out very explicitly that the RFC editor has 'no say' over the technical content. There's some tension there between that and the ability of the RSE to 'raise their hand' - but that's not influence over specific technical content. That's saying 'I've gone out and talked to operators and and they don't understand what we're talking about.' The community needs to do what smart organizations do, which is to encourage everybody to lead when it comes to problems of quality and getting them better. And that certainly applies to leadership as well. So, two closing observations, and also follow-ons from the major ones. Historically the RFC editor could publish documents that they believed were relevant to the series or to the community. And when the streams were created, and we subdivided the publications power, the creation of documents went to the streams, we partitioned that up fully and there was no place in between for the RSE to publish various kinds of documents. It seems to me it would make a lot of sense to have that built-into the hands of the RFC editor, to be able to publish the one RFCs and documents like the style manual the procedures manual, commentaries or observations, and I think this could be an improvement to the series, and it a avoids any problem of either the RFC editor having the to find a willing stream to publish this, which could be tricky, if for instance the comments are less than glowing about one stream or another. Again, you as the community want to speak frankly, will problems in the case of the independent stream, that might become a conduit for the RFC editor to pressure the independent submissions editor or vice versa. And then finally, 5620bis argues that we need some of the time to look at the customers of the RFC editor. And I've clarified that in terms of the production side, customers, which are two streams - the people who produce documents, who hand to us to produce into RFCs, or to transfer into RFCs, and consumption side customers who consist of largely of people who read and use the various RFCs. I don't have a laser pointer but if you look at the far right end of the screen, the end users are here. I can move a mouse, great. Cool. Thanks. So, I've added this box to the old model. What's interesting to me - for all the success of this community, we seem to have done it without knowing really very much about who uses RFCs except for the people we know directly, and the other folks on the list. But there's a huge constituency out there. During my tenure people have said maybe we need to tune the editorial model, or change the design of RFCs, and then there's the universal question - do we need to bond to ASCII? To a very large degree, these questions are informed by who is reading the RFCs, and how. We don't know the answer and we should. To bank on doing quality work without knowing the outcome of your work is to bank on luck. We've done well so far, but we have to keep an eye on it, and I call for the RFC series editor to work the on that. I've also added the IAB and the IAOC, and frankly this belongs as IAD and not IAOC. But again, IAB is the superior of the series. I've drawn a line, around the RFC editor, a friend of mine and I today spent the better part of an hour to make this look like China. We'll try to do better in the future. Other than that, this is a very identical model to what we had before. And notice that there is no connection between the RFC series editor, and the independent streams editorial board, or the ISE, except where they need, where the ISE uses the production center and RFC publisher as their production house. So, in closing, of course, this depends upon the character, caliber and type of person that the community decides to hire. But I put together a hiring process that has a simple criteria. I want to maximize community participation in the selection process, but doing it in such a way that maximizes expertise so we have knowledgeable people on the selection committee. I could have chosen leadership of the entities to do this, but it seems like in such a wide and talented community, there's a lot of people who can make it work successfully. So the general approach is to allocate to the streams the ability to put people on a selection committee as follows: One from the IESG, recognizing the fact that they publish about '91 to '93 percent of all RFCs. Another one selected by the remaining three streams, the IRSG, and the IAB. And they have intimate requirements of the job and technical editing. And one member from a source to be determined. I've had some design sessions with a lot of people, including with the RSE, and we have not come up with a clear vision of what to do. So I would like to see that come out of community discussion. Finally, human resources professionals which might come from the one of the corporations. And, there's a default here that says unless the committee chooses otherwise, this is going to be a search professional. Finally the RFC series editor as an advisor on the content of the job description and experience and requirements of the details of the job. So, we're going to go into Dutch Q and A, as evidenced by Olaf's spelling. And I'd like to add one more point which I think is interesting. Completely by accident these efforts resulted in a model which is highly similar to the model practiced in the last 40 years, minus the last ten months. Because there was one RFC editor that was in charge of the entire function. They advanced the series, the writing techniques, and so on. And without intending to do so, I've returned us to a model, that's consistent, I hope with the way things have been done very successfully for many years. Thanks for your time and I'm happy to do Q and A. Olaf: You can stay there - I'll use this mic. I see one person, second person. I see you've been on your feet for a long time. Ted Hardie: One of the things I wanted to do is read exactly that section of Glenn's thing which says if I may read it aloud, 'an unexpected consequence of the effort is that most of the changes proposed for the updated model style and perspective used during the first 40 years of its life. Although adapted to the technical community. This memo proves that this is the best way to serve...' I have to say, it's one of the worst pieces of shit I ever read in my life. This document is sufficiently infused with an ignorant nostalgia of where we actually have been. It is really very hard for me to read it, without thinking that a very tiny number of people have been convinced that the RFC editor function worked in this way. Because it simply not true. There's a huge amount of this community that's been dealing with the RFC series for a very, very long period of time, and the way that this has worked has evolved enormously through that 40 years. From you know, a guy sitting in a graduate student room collecting pieces of paper, to a huge web based effort to do a variety of things. This document is so wrong I can't even begin to tell you how angry it makes me. It starts from a presumption that this series is the only way the internet technical community talks to itself. And it goes on to presume that this will remain the same whatever we do to the series. Which is just flatly wrong. It ignores the internet draft problem, which is a problem many of us have. And it relies on an old boys network in the RSE that are enormously problematic. This is a bad document to start the conversation from. And I am very, very worried that if the IAB says we need to get consensus either on this document, or minor changes to it, we will end up with something that does not work for this community. Olaf: To be very clear, what I said is we need to determine whether this is the right direction. If this is not the right direction, we have a problem, but we'll need to fix it in a way that gets consensus. Ted Hardie: I think that there is a very major question the IAB needs to ask itself about the RFC editor. Is this an independent body that provides a check and balance, adult supervision? Because that's how it comes off. Do the independent streams that make up this model? Or is it somebody whose going to keep the chips up? Because the way the document reads now is that you're looking for adult supervision of the independent series editor, of the IETF and IRTF streams, and somebody who can publish on his own. That's wrong. That's not where the community is at this point, and taking us back there may be be nostalgic, but it will not work. Glenn: Wow. Good opening. Hold on Ted, I have some questions. Unless there are people at the mic. Olaf: Please reply to it. Let's roll over to ... Leslie. Leslie Daigle: Okay. Well, thanks, Ted for going first, because I was afraid I was going to be critical. And so, I will say a few remarks that may provide a little bit of illustration where Ted is coming from, and you may want to revisit his remarks. Glenn: There's so much of an echo. I'm having trouble following you if you could bee careful to enunciate. I'm hearing more echoes than speech. Leslie: I'm trying to get the mic to be resized. One of the things I wanted to observe is you've been in the role for how many months and a few days. And presumably you've learned a lot of things about how the system works that have prompted you to propose these directions. But I think the document is rather slim on articulating what those things are. It's more or less a set of directions that are proposed by assertion rather than really laying out the reasoning for why we all want to go this way. And I think it would be more solid to understand what has led you to these conclusions, because it's pretty hard for the reader to follow along in that regard. And I'd like to point out, that's actually aligned with something I consider to be a fairly significant problem in the proposal, in that, as written, not so much in your articulation of your slides, but as written the document essentially talks about the RSE getting approval for directions that they are going. And that's pretty much the extent of the expected involvement of discussion with the community. And I think that's that's a failing, and that's one of the points that Ted was getting at. The community actually, the community are not made up of technical editors. They cannot provide technical professional direction. But they are very much involved in making sure that this series evolves in the way that works with the internet technical community. And that must not be advised. I think that needs to be reflected more in the document, making sure although it's great to have the RSE get community involvement, that it doesn't become an insulation between the community and the RSE for instance. And then finally, the last remark I'll make here, I'll send others in writing, the last remark I want to make is that this is either, this proposal is either way too big or way too small. It's, you know, it's way to too big if you consider how things have been done in the RFC series over the last 40 years. I have a hard time imagining it fitting, you said it's reflective of how it was done for 40 years. I have a hard time seeing Jon Postel sit anything the role, and carrying out this longview analysis of what should be done by fifth of every December. I highlight that maybe it's actually too small. I think that, too small, yes, because if you actually pursue all the directions outlined in this document, you are in essence, talking about the initiation of a much broader, much bigger publication series that really should be defining what its end goals are, what its vision is, and how it's I going to get there. Because right now, it's a whole lot of pent up energy that's going to be laid out in somebody's idea of a plan every year, but it has no vision and no continuity in terms of why are you doing all of these things to formalize a lot of things that have worked out really well. So at this point I would say it's too big or too small. And, I also agree with what Ted said. Harold?: I'm observing that the people at the mics have mainly existed of what I would characterize as the middle age boys, of which Leslie is an honorary member. I mean the old boys network is not that loud. And the new people are not speaking to this at all. But, I would repeat Leslie's comment about evidence based changes. I was a bit disappointed in the presentation. And disappointed that I couldn't find the document because it has not been published as an ID yet. And in that it presented a number of suggested changes, but none of the experience of problems that those changes would fix. And I would like you to say a few words, if you can, about the problems that you have experienced as opposed to problems that have been imagined that could occur. Which this is, this changes could fix. Glenn: So, the biggest thing, and that is what my proposal addresses, I'd say the biggest thing it's unclear of the scope of authority. They're in a fuzzy situation. Let's recall that a significant item in my work was to see if we could define the job so that we could have both the right job and somebody actually be able to do the job. Harold?: So does that translate to 'I have been in a situation where I wanted to give instructions to somebody and I didn't know if I have the authority to do so?' Glenn: To some degree, yes. Harold?: What, -- can you give specific examples Glenn: I can, but I need to offer context, which is that this was a job that was primarily oriented around being able to figure out what the work was, and to emphasize that over making any changes to the system. So I've actually done a modest number of things in the operations, or changes of the RFC editor. I have not produced a procedures manual. I haven't dived into the style guide. I haven't had time to look at things like the, who the end users are, although I did work speaking around. More time and a longer term position. I would have seen what people said in use of the series. I have looked at statistics. I would say it's interesting, because some things seem to be in the hands of the publication center. Some things seem to be in the hands of the IAD and IAOC. The RFC series editor has a clear position of fielding questions from the production center. And kind of in the mix, I would say that, for the person who is supposed to succeed me, they would have to spend their time clarifying those things. So in other words, what they get to control, what they don't have to control. And that's exactly what I was not supposed to accomplish. My job was to make sure when the RSE is hired they know the scope of their authority, know where the responsibility lies, and they can start working instead of discussing what they can do. Those are the shame shape of the issues. Harald: Thank you. Glenn: You're welcome. Olaf: Moving over to Sam? Sam Hartman: Sam Hartman. I have a comment to Glenn and a comment to Ted. So, in general, my default reaction to this document is, or to your presentation, I apologize I have not reviewed the document in detail, is generally positive. I'd like to call out a couple of things I specifically like and one I don't. I agree with your analysis of the qualifications of the RFC editor. I think that's a really important thing for us to basically, to say. I also like your proposed selection process. I think that your approach there is very good. I disagree with your proposal to move things from the IAOC to the IAD. I think that the IAOC has a fairly strong role in setting, you know, overall administrative direction for what sort of people we're willing to hire, what the requirements will be, processes, and that sort of thing. And I think, and just as the IAB, has, you know, there's a split in the authority between for example the IAB and the IAOC when hiring, say the RSE for example, I am concerned that pushing that to the IAD rather than the IAOC is one too prescriptive and two, focuses it a little bit more in, fails to recognize that there is some tension there, and that that's intentional. And it's good for the community. That you know, the IAOC actually does have a role to approve that the administrative things we're doing, and to be involved in those. My comment for Ted is that, I got a very strong message that you don't like this. And kind of, I would say, the source and some comparisons of what you thought, there's a certain sense I got of a description of your concerns but it's not something that's actionable for me for me as a reviewer. So here, as a member of this community, I'd like to balance your position against Glenn's and iterate with one or the other. I think basically it would be very valuable to the community if you would produce a version of what you don't like about this, that's focused on the proposal, rather on a comparison of the proposal to any particular past or future practices. Because, and I appreciate, I think it's great to come up and say, hey, heads up everybody, this is serious, I think we need to seriously look at this. I have some major concerns. This is great, but I think part of acting on those concerns is turning those into an actual commentary on the proposal. That is something that is a detail, that a reviewer can actually, that somebody could judge, or excuse me, a review that somebody could judge. And I really look forward to seeing that from you. And certainly if I don't respond to it and you want me to, I would be delighted to read such a review. Ted Hardie: Happy to do that and I will say, please, everybody, please read the actual document. Olaf: Ted, one part of this is that it is clear that the presentation layer, so to speak, of version -00 document, is something that we felt, as IAB, when we saw it, which was actually at publication, could use a lot of shape up and, and improving. I hope that the presentation of this oversight tonight is actually less aggravating concerning the history, but I was actually also wondering if you had very concrete problems? Except, I understand what I took away from your remark was, lack of vision, that was one of the parts that I got away specifically, for instance in relation to internet drafts. But, in the model description, what are the parts where you say, you should do a better job at looking at this, this is really something that, you know, this is a recommendation that I do not like. Or maybe even drown the whole model, start again. Where are you in that sort of scope? Ted Hardie: So, I noticed that there are other people at the mic, so I'll make this as brief as possible and I will try to write a document as Sam suggested. I do encourage everybody to read the current version and any later versions, because I think they're much too detailed to rely on the presentations in plenary. But the core of the issue is this, is the RSE an independent actor that acts as a check and balance, in the system for the internet technical community, or is it somebody who is hired in order to harmonize in areas that the internet technical community would like to see harmonized? If it is a check and balance capable of leading the series in new directions, going out and finding the customers of the series, and suggesting change on that basis, it is fundamentally different from what we were looking for from the RFC series editor as an outlet of IRTF work and as an independent stream. And I believe that the current document, for whatever reason, and my passionate statement notwithstanding, the reason doesn't matter. I believe the current document goes way too far towards seeing it as adult supervision of the overall series and, not nearly focused enough on keeping the chips up. Making sure that the style manual evolves when we want to do things like allow authors to use their native character names. There are certain aspects of this job which are simply editorial work that needs to be harmonized across streams, not higher level executive management of the three streams. This is fundamentally not an executive task. It is a lead editor's task. And the way the document is written takes it far too far along the executive peer and not nearly far enough down the lead editor role. Olaf: I want to ask Glenn to respond to that and ask him what his recommendation is, without having it put on paper that crisp and clear. Glenn: If I understand you well, your distinction is between, or your observation is that this is purely an editorial supervision task, if I may, versus something much more far reaching and transformational, and in the later case, undesirable. My perspective based on direct experience, is that a purely editorial supervision task actually jeopardizes the community in terms of its long term success in publishing technical documents. When I came on board, my broad observation is that all sorts of fundamental things that need to be attended to once you have a series of a certain scale were simply not taken care of. When everyone sets a function in an organization, one does not have to do the steps that one wishes to do, or the fundamental steps, but the activity itself doesn't exactly take on alive of its own, but it begins to make certain demands. So a quite telling thing, even though we have an international standard serial number over two years ago, it's never been in the card catalog any library in the world that we can find one, of the publications center or production center people found that. That means that our goal of accessibility was a complete failure. A lot of people do research through libraries. Furthermore, there are issues of the development of the procedures manual and the style guide, and those are not purely editorial tasks. In the latter case, they are substantial. My own observation is as good as the people are in the production center, this community needs a layer above that, to observe what's happening in the layer below, make sure it's serving them well, and to advance the series to optimize the overall advantage of the community. And, the processes that are defined in the document, and I concede as a first it is a first draft. But the processes have a powerful feedback loop of observation and recommendation by the RSE, and feedback by the community to see if they ever want to go there. So, my own sense is that it's absolutely up to the community if they wish to do, if I may, Ted, your approach of relatively supervisory limited editorial model, or if they wish to follow more the potential of the series even if only at a half time basis. But I think that if they don't go with this proposal, it actually is to the detriment of this community. Olaf: So, we are going to run out of time. Because it's now three minutes to the half of the hour. That means that I will close the mic line after -- no. The people who are no on the mic line will be able to communicate and raise their points. We will have discussion, but after that we close. So we will run about 15 minutes over time. Andrew Sullivan. So, the series of comments have led me to believe that there's a deep division among people about what it was that we want, you know, out of this work. Whether we want an analysis of the deficiencies of 5620, or whether we want to say, we have 5620 and how are we going to implement that. That seems to me to be tension that's not resolved by the document The second thing I would say, just without knowing anything about it, my reading of 5620 is that, you know, you've got a job here that has a lot of responsibility without the authority to do it. So, if that problem is one that we want to solve, and we want to solve it right away, I think some of the recommendations in the proposal are pretty good. Just as a third thing, I wasn't around for a lot of the history that was in this document, but it seems to me to be a little glib in its presentation and you could probably rip most of it out because I don't think it's that important. But if you're going to leave it in there, you better cite some things, but I don't know that it's doing a lot of good. Your last remark, your last set of remarks about experience that you had when you came to the project, I don't actually see that stuff in this document. I don't see a whole lot of evidence about what the deficiencies were when you landed. That actually would motivate a lot more of this stuff, be it seems to me that is that is information that could be incorporated in this document. And if it's there I didn't see it. Glenn: Thank you Andrew. Olaf: Over to Scott. Scott Bradner. I think there's starting off with the confusion of what Glenn's document was supposed to be. And I think it's an unfortunate confusion. Glenn seems to have written a replacement for 5620. Or whatever the number is. And I think that's a reasonable thing to have tried to do. But in doing that, he didn't go through the stuff that Leslie asked for, and what was just asked for here. Which is 'why?' Why do this? Why do that? We don't do a whole lot of that in our documents. We probably should do a lot more of that, of how we got to a decision, and what the experience was that got us to decide path A or path B. We do a lot more than some other bodies do, but we do it in our requirements documents more often than the final document and technology document. So while I think those things would have been very helpful to do, I don't think they were right for this document as it was being envisioned. Now, maybe we need a different document, maybe we need a travel log through the RSE as a separate document. I don't know. But I think to criticize this particular document for not having the experience section is probably unfair for it. That's the first thing. The second thing - Ted's rant was one of the better rants that I've heard with almost no content at all. It was very unfortunate. His second set of comments were a little better and more useful. I don't agree with him. I do think that the RFC series editor has to have the authority to, if the community starts saying, independent stream, RFC, IESG or whomever is publishing crap, consistently publishing crap... I remember Jon Postel calling me up and saying, you know, some of this stuff isn't very good. You ought to think about it. And I think the RFC series editor needs the ability to do that. I don't think they would do it very often, or he would do it very often. I do quarrel with Glenn for using they instead of he or she. I think Glenn did a good job of trying to do the wrong thing, which was to redo 5620 at this stage. I think what was needed is 'here's what Ilearned from 5620.' 5620 was the thing that was there when Glenn was hired. And, he needed to say, given that, here's what I think was different. That's what he did in the presentation tonight and I think that was pretty good. And I'm more going on the basis of what the presentation tonight was, rather than the document which I do find to be long and rambling and not crisp, and I do think it needs a lot of work. But I think it needs work based on figuring out what the Deltas are and then explaining them. But not necessarily doing the travel log. Maybe that's a different document. But I think Glenn did a good job and I don't think he deserved the kind of trash that Ted gave him. Olaf: Going over to the other side. Tony. Tony ?: It seems like there's two visions for what the RFC editor, that particular type of role they should have. And one of them is a very management oriented role. And the other one is a leadership role that Ted was envisioning. And, the leadership role, obviously requires a bit more vision openness for ideas, and like he mentioned the possibilities of other character sets in the RFCs and what not. I'm wondering if that particular portion of the role should be embodied in the, what you're calling the series advisory group, or whatever the acronym refers to. So, I think there's need for both types of that, or both pieces of that role, but I'm not sure they have to be in one person. And it might be that the visionary part could be spread out further. Just an idea. Glenn: So, apropos that, I believe it's in the draft. I actually make a statement that, I'm going to paraphrase, since the RSE is there so the community knows they've got a person doing two things: making sure the whole system makes sense, and secondarily to act as an instigator of things that ought to get done. One of the characteristics of designing one person, who is in a ship, in a crow's nest from a single vantage point for a standards organization, they're in this one place, where are we going, what's happening. I'm talking about from an editorial point of view. Is there an opportunity here? Is there a problem here? Usually that requires that you dedicate some degree of resources to doing that. That's a large part of it, not strictly, but a large part of it. Once you've got somebody doing that, what they become is an instigator with a lot of people, with committees and volunteers. So I tried to emphasize that the RSE is there to make sure certain things happen and get started, but they don't necessarily have to be the one that does it. And similarly, if there are people with ideas, they don't necessarily, by any means, have to go through the RSE to get them started. But at some point the RSE needs to come up and start to aid, and provide coordination depending on the circumstances. So I didn't want to do anything that said, you know, this is a person through whom everything has to go. Rather, at least there's one person looking and making sense of things, and speaking up if they discover them. Glenn Zorn: I actually sat down and thought about whether I wanted to say anything or not. Because, I become very irritable when I hear people use the word 'we', when they're talking about, almost anything, about what we think, we believe, the way we see things. I'm not really sure who they're talking about when they say we. I heard a lot of we's coming earlier today. Along with a lot of yelling about how things are not the way that Glenn's document claimed that they are - and never have been, and never will be or never should be. But if we're looking for evidence based approaches, perhaps we should offer some evidence in that direction. Which we, the greater we, the royal we. Dave Crocker. Yes, I was really sorry to hear that this was the worst piece of shit that Ted had ever read. I thought he had a broader base of experience. There are some core questions that have been pending for a while. Glenn's effort tries to resolve them in certain ways. But the question of whether this is more junior or senior position is massively strategic, and needs some theory to drive it. Glenn outlined some view of what should be a more senior one. To the extent people think it should be more junior, the question I would ask them is A, why aren't the people already in the trenches enough for that? And the other is, if the RSE isn't the one doing the more senior, the more strategic, the higher level management issues, who is going to do that, and why do we believe they will bring enough focus and knowledge to that task? Similarly, the lines of authority up from the RFC have been confusing from what I've been able to discern for a long time. And I don't think that Glenn resolved that because he's got two lines above, and I don't think that's his fault. I think that there's some confusion. I guess I would characterize it from my sense of confusion between the IAB and the IAOC, about how, if lines of authority need to be and all. I would say that needs to be worked out, that there needs to be one line, and assistive, and that might be necessary. But it needs to be clarified. In terms of your request to the community - mostly what I heard you ask for was for people to say whether they were happy or unhappy, and I sure hope that's not what they do. Olaf: Give recommendations. Please say exactly what you don't like and why. What's wrong with it? But best of all is, what do you believe the better choice would be? Which I know that's what you meant. And I realize also, that we're pushing the boundaries of process in a sense that we are asking people to review an incredibly big document in a very short time. In fact, I want to stress that we've asked Glenn to take away what he learned tonight, one of the things is, in essence, what I heard is make a much more concise set of recommendations, and a much smaller document, and we've asked him to do a rev two by November 22nd. Dave Crocker: Wow. Olaf: That is incredibly ambitious. But that is the document that I would like to ask everybody to look at again. In a relatively short time scale. And I know this is stressing the process, but the clock is ticking, and I really don't like saying that, but that is why we have to understand based on feedback, based on arguments and suggestions for improvements, whether the directions that are proposed lead in the certain direction, and we have a feeling that the next steps will go smoothly. Because if not, if there is a lot of debate and there's no clear direction on, for instance the questions on junior versus senior, or the reporting arrangements, which is by the way, something that Glenn has come out by doing the job. It's not something that the IAB told you you should implement it that way. It's not something that the IAOC said you should implement that way. We have that discussion internally now too. But it's those kind of recommendations that people need to bring forward and discuss. I hope that this presentation actually bubbled up the major questions. Dave Crocker: I want to end with one last point, which is the question of 'whether the RFC needs to be a technical expert.' The equivalent to the RSE, which was Braden and before him Postel, to my knowledge, Bob Braden was not doing technical reviewing, or revision, so we haven't had the function that people, some people seem to want. We haven't had that performed by that job for I don't know how many years. Leslie Daigle. I wanted to follow up on Scott's point. I'm not looking for a travel log. I would, though, like better clarity about the problems statement, and that probably is best served as Harold put it as being evidence based. So I don't need to see a transcript of the last six months of Glenn's life, but as written to characterize it only slightly - this is a different model that this expert proposes. And absent an actual problem statement and evidence, my only basis really for judging it is whether I think he's a good expert or not. And I don't know what happens the next time a new expert comes along and writes a new model. This is not how we do business around here. It certainly wasn't the way we did it such as the administrative restructuring activity, where I was reminded on more than one occasion I had to provide problem statements and more clarity for the community to dig into why one path might or might not be the right direction. So I think it's fair to expect that here. The point I actually stood up to speak to was, you did, Glenn, in response to Ted articulate a particular problem being solved here, and that was the need to get clarity of the executive management role of the RSE. That's certainly a valid problem and has been on the table since we started going through this. But I want to observe a couple of things in what happened in that part of the discussion. Ted said, words to the effect of, that you've moved too far along the executive peer and not far enough down the technical series editor part of the problem. Which I think is probably a statement I would make, but your response was to re articulate why we need to get clarity on what is the executive role of the RSE. So, I think what we actually need to do here is tease out two separate discussions. One, are we solving the right problem? Which probably we are. And two, are we solving the problem right? And I think that Ted's point is, he doesn't think we're solving this problem right and that's where we have room for further discussion. Olaf: That was very helpful. Thank you, Leslie. Next steps? As said, our new document will follow November 22nd. We have asked Glenn to keep inventory of the things that have been discussed. He will do so on the RFC interest list, and on the RSE part of the RFC editor web site. For everybody who is interested in this discussion, please do this discussion on the RFC interest and RFC-editor.Org. That's where we need to find the consensus. Also, for example stream clarity, this is an IAB decision based on community input. We'll try to make a consensus goal and determine where the consensus goes, but in the end it's an IAB decision which is going to be incredibly difficult. But I hope that this, I know that this plenary has actually raised a number of good paths to proceed, discussion on whether or not we are solving the right problem, and whether the solution to the problem is the right one, is actually a fairly good summary of that. With that, I won't keep you any further from your dinner. I will see you all in Prague. Thank you very much.