IAOC/IESG Plenary 31 July 2008 Agenda 1. Welcome 2. NOC Report (Andrew Lange) (see slides) 3. IETF Chair (Russ Housley) (see slides) 4. IETF Trust (Ed Juskevicius) (see slides) 5. IAOC (Jonne Soininen) and IAD (Ray Pelletier) (see slides) 7. NomCom (Joel Halpern) (see slides) 8. EDU Team Update (Margaret Wasserman) (see slides) 9. IAOC Q&A 10. IESG Q&A 11. IAB Q&A IESG Q&A Henning Schulzrinne: follow-up question regarding the bonjour documents. It was promised at the last IETF that this would be progressed, what is the status on that? Mark Twonsley: that document depends on another document. This other one is now done, so the document in question will be progressed really soon now. Keith Drage: how do the PROTO write-ups help and how do they affect the timeline? Cullen Jennings: the PROTO write-ups help very much Jon Peterson: yes, agree. We use them. Mark Twonsley: PROTO write-ups are a good thing, the other comments sometimes yes, sometimes no. Dave Ward: they absolutely help, especially in areas I am not so much an expert on. Lars Eggert: the process if applied should work pretty well. Keith Drage: there are large pieces of the RFC that defines the PROTO process that we are at the moment not followed, but should be. Brian Carpenter: as a Gen-ART reviewer, the PROTO write-ups are extremely useful. Last Call reviews would be easier if a PROTO write-up were available. Russ Housley: the Secretariat has been posting the PROTO write-up as the first comment in the Data Tracker. It is available to everyone. John Klensin: there was a discussion on the list regarding extending the sessions on Friday afternoon in Minneapolis. Is the IESG getting back to the community with a decision? Russ: this is still under discussion. More community comments would be good. It will be a management item on the next telechat and then reported back to the community. John: I have had several conversations this week with several ADs, on an individual basis, regarding my recent appeal. I have been pleased by the things that those ADs are saying about process and rules, although I don't know if their opinions represent the IESG as a whole. Ted Hardie: I was also very happy with your response to John's appeal, made the right decision. I agree that there should be a dialogue about this. However, I am not sure that it should be the IESG running that dialogue. We still have a problem with the review process. Can you Russ, in your role as General Area Director, offer any clever way to have such community discussion that does not end up into a fight? Russ: I have some thoughts, none that are fully worked out. I would love to brainstorm with anyone who has any good ideas about process change. Lisa Dusseault: I posted a mail to the list with some proposed changes. If that helps to develop a better procedure, that would be great. I invite comments and feedback. Jeffrey Hutzelman: any time the IESG looks at someone cross-eyed, five people jump up to complain that the IESG has too much power. The primary job for the IESG is to manage the process. Wouldn't it be easier if we would concentrate on technical work rather than changing the process every five minutes? Russ: there is definitely need for some process changes, maybe not in all areas suggested. I'm all for incremental improvements. Magnus is working on a document that will be sent out to the community shortly. John: my gratification was not about the appeal response. I was appalled that the IESG apparently felt under pressure to respond the way they did, in legalistic, narrow, language that completely ignored the main point of the appeal itself and that, even on the narrower issues, immediately followed an appeal response that indicated they were going to unblock the document with proposed text for it that many people felt was petty and punitive. I'm glad the latter got straightened out too, but getting to a reasonable result should not be this painful for either the community or the IESG. Spencer Dawkins: I could not understand the IESG's response. Not sure what actually happened, even though he is a scribe at IESG telechats. The technical discussion about the appeal was not minuted. The discussion that is happening doesn't need to disappear just because one person in the community makes an appeal. I think this is the first time we had a response to a technical appeal like this one. As a member of the community: he did not understand what happened at the telechats. Lisa: this document did not come back to a telechat, because the issue was cleared in between telechats. This is not a rare case. Spencer: the point is that this was not very transparent. Russ: to clarify what a DISCUSS-DISCUSS is: sometimes review of a document raises a question. There is a real concern if the answer to the question is A, but no concer at all if the answer is B. During the telechat the sponsoring AD will usually provide the answer to the question. Sometimes the answe comes before the telechat. Once the answer is known, the DISCUSS-DISCUSS is either cleared or turned into an actionablee DISCUSS. The explanation of DISCUSS-DISCUSS is not very clear, and the IESG has taken the action to explain it better in an updated document. Harald Alvestrand: this is a symptom, not a disease. I disagree that this can be improved by incremental changes. People waste time on the wrong things. It is not the individual's problem, it is the system that needs to be changed. Russ: I would love to hear your ideas on how it ought to work. Scott Bradner: the problem is that we never defined the internal workings of the IESG. This was brought up in Yokohama. We have a process in which one individual IESG member for whatever reason can stop progress in a very non-democratic or non-technical way. And this is frustrating and not-understandable by the WG. The way the IESG makes decisions, is not well defined. Russ: since the IESG started using the Tracker, things have become much more transparent. Now, anyone can see the status of the review and see what comments need to be resolved for the document to progress. Pasi Eronen: the Tracker has been unchanged for a long time. One thing that is probably very confusing: that it doesn't allow you to determine if only one AD has a problem or if some or all ADs agree with the blocking comment. That is not visible to the community. Scott: I was on the IESG when the tracker was developed. Some of us pushed extremely hard to get the tracker out. But we hoped that the community and the NomCom would make use of the information in the Tracker, and that is not happening. Sam Hartman: I want to talk about appeals. RFC 2026 says that the appeals process is supposed to be open. While I was on the IESG, the answer often was: if you had an open appeals process, how would we be impartial about the second level appeal. He would much rather see appeal handling be extremely open. It would be more useful to have a dialogue with the community and have a community consensus at the end and not a decsion made by the IESG internally. Dave Crocker: the Tracker is excellent. Obviously it has problems, because it is big and complex tool and process. Would like to thank Pasi for bringing up his point. Would encourage that if an AD has an issue, he or she should register that separately. Bottom line: if you go back and check why the IESG is in charge, it was exactly to address the problem of late surprises: the issue of the community being pre-empted. This has not changed. We still have the same problem. Every time an issue gets raised: dominant response is either that this is a problem with the Tracker or it is a dismissal of a "whiner". Ron Bonica: I heard that we need to have a discussion about the IESG behaviour. I heard that this should maybe not led by the IESG. Can the community then suggest another forum and what the exact topic? Tim Polk: a longer and more open review might conflict with other goals the IESG has, like efficiency and timeliness. Much more effective to look at the Tracker and find out some other AD is already taking care of a certain issue. One person should hold the DISCUSS and then others add comments to show they agree. This way, only one AD needs to clear the DISCUSS to get the document approved. Chris Newman: agrees with Tim, but also with Pasi. Nominating one AD to take care of one DISCUSS is faster. Magnus Westerlund: we need to work bottom-up: cross-area reviews need to be happening. Many of the issues that come up in a DISCUSS should be addressed early on in the review process. Dan Romascanu: sympathises with visibility issues raised by Dave Crocker. We need participation from the community, technical experts in the review teams, and also response from the authors when the comments are sent back to them. Ross Callon: during the telechats it usually it is not important enough to put a comment in the Tracker to indicate agreement with the comments of other ADs unless I want to be involved in the email discussion about this DISCUSS. Thomas Narten: Tracker is great. Observation: how long are we using it? 5 years? Are we still using version 1.0? Regarding feature richness and so on. The way ADs are using the Tracker, it is hugely variable. Consistency would be helpful. We also need to step back and go to the next level and make the work flow of the tool better. Russ: that is on the to-do list. There were meetings this week to talk about Tracker enhancements. Pasi: the tool is not so easy to change. But we are working on it. Pete Resnick: WGs are thinking what should we do to satisfy the AD. That is wrong. If a DISCUSS goes on a document, then there should be an agreement that the community goes to that WG for a discussion of the concern. Lars Eggert: agree that the WG needs to be involved if it is a serious issue. We are indeed sometimes working around idiosyncrasies of the tool. Pete: we need to be careful of how artifacts are influencing the way we handle things. John: I've been in software development for a long time. If a group that is supposed to use discretion and good judgements says that it can't be done because of the tools they use, I get the chills. Lars: that is not what I said or meant Lisa: it is a fact that tools, and even email, influences the way things are done. It has side effects. But without a tool, the decision would be even more judgemental. John: afraid that the tool makes you confuse consensus with rough consensus. Lisa: none of us have a simplistic way and blame the Tracker. John: problem is when DISCUSSes become blocking issues over trivia. If there is disagreement between the IESG and the community, if it is a trivia or a serious issues, there needs to be better communication. Jari: agree that the way the ADs communicate to the WGs about DISCUSSes needs to be improved. Ron: we should focus on the type of DISCUSSes that deal with serious issues, even though they happen very rarely. John: agree, but I am afraid that the trivial kinds of issues are a waste of time for the IESG. Spencer: regarding the question how the communication should go forward in the various DISCUSS cases. Maybe it would be worthwhile to set up a group or panel and work on that and come back with a proposal as was previously suggested in Vienna. Loa: I have been a WG chair for some time. I have experienced a number of ADs. Sometime I get all the three types of DISCUSSes on my document. They have helped to improve the document. Also, I am a liaison to the IESG. The problems we talking about stem from a very few number of DISCUSSes. Overall the work done is great. Hadriel: regarding not having enough time and possibly adding time on Friday in Minneapolis. We have not nearly enough time to meet with all the WGs in the area he is working in. To have 7 hours spent on plenary does not seem time well spent (5 hours plus 2 hours re-arranging the rooms). Russ: re-arranging the rooms won't be necessary in Minneapolis. And we are also considering 1 instead of 2 plenary sessions. We are working on that problem. Hadriel: or maybe put one of the plenary sessions on the Friday afternoon slot and see how many people show up? Margaret: disagree with extending to Friday afternoon. People already loose one weekend before the IETF. Can we not start earlier in the morning? One plenary session might help and will provide another slot. Making it longer doesn't seem to be the only or best solution. Ross: not all work is actually done in open sessions. You end up doing breakfast- and lunch-meetings to talk about documents or other work issues. Not humanly bearable to do this for an entire week. Maybe we should consider doing more work during meetings. Mark Townsley: evaluate if your WG actually needs to meet at every meeting. Keith Drage: ad-hoc meetings are necessary. Some people go home on Thursday, we need to suggest everyone stays until Friday. Thomas Narten: yes, more work needs to be done outside the meeting. Look at when I-Ds are published. Margaret: maybe we could have calls in between meetings. Not everything has to be done during this one week. IAB Q&A Gregory Lebovitz encourages everyone to use their roles and functions in their communities or companies to help deploy IPv6. Scott Bradner: there was an appeal on the NomCom process last time. What happened with that? Dave Oran: I am the liaison to the NomCom from the IAB, and I encourage input from the community. We met with the new NomCom chair today and discussed the issue of sharing information about the candidates with the confirming body. We reached agreement on how do facilitate information sharing between the IAB and the NomCom. I do not anticipate problems. This may not make everyone comfortable. But he does not think that this particular issue will come up again. : What does the IAB think about adding new congestion control algorithms to TCP? We view a aggregated UDP/IP header as just the "layer 3" datagram layer over which we run this TCP implementation as opposed to sticking with TCP or using another congestion-controlled transport like SCTP or DCCP? This was an issue that came up in the TANA BoF this week. Stuart Cheshire: I understand the tension between the IETF which makes long-term standards, and companies that want to ship a product this year, and not wait for Microsoft to release the next Windows version that implements the new TCP congestion control algorithm. I personally think that it is a good approach to experiment with this at user-level running over UDP, and then when the algorithm is worked out it can be standardized, and then gradually make into the mainstream TCP implementations over a longer time frame, like five years. Dave Oran: not sure I agree with Stuart on this. We have to be extremely cautious with congestion control algorithms. There is a balance to be struck. Involvement of the sponsoring ADs and the relevant ICCRG (Internet Congestion Control Research Group) is important. Let's move with much speed and low haste. : The issue is that the purpose was not to simply mirror TCP congestion control with UDP protocols, but to have a different congestion control that by backing off much more than TCP, serves effectively as a separate less-than-best-effort traffic class. Stuart: I view UDP as just IP with port numbers for demultiplexing. I personally think it is a historical design mistake of IP that the IP header has no port numbers for demultiplexing, so every single transport protocol running over IP has to have its own port number space. AppleTalk, for example, had the port numbers in one place, in the datagram header, instead of that functionality being duplicated in every transport protocol. Given that, I don't see it as inherently ugly to layer transport protocols over UDP, or "architecturally clean" to layer new transport protocols directly over IP. I'd be happy to see all new transport protocols layered over UDP, and just treat UDP/IP together as the new datagram header. Demultiplexing belongs at the internetworking layer ("layer 3") not the transport layer ("layer 4"), so let's just treat UDP/IP as the new "layer 3" header. : You should use UDP when you want peer-to-peer communication between peers stuck behind NAT gateways, and TCP for everything else. Stuart: No. This is a red herring. Broadly speaking, you can do NAT-to-NAT peer-to-peer communication equally well with either TCP or UDP. The reason TANA wants a new congestion control algorithm is because they want something less aggressive than today's TCP. It's nothing to do with NAT gateways. Patrik Faltstrom: when working with international domain names, to include this in all the protocols will not work. Today we are using IPv6, DNSSEC and other new technologies, why not also do some serious work across the protocols to include UTF-8. Olaf: yes, this is well noted. Scott: when I was a transport AD, we had a lot of people who wanted to use UDP. That as usually a way to say TCP was to heavy and is too slow etc. Would be very concerned what the underlying excuse is. Gonzalo: agrees. Has to be evaluated on a case by case basis. Marshall Eubanks: there was a BoF on Experimentation in LISP. Does the IAB have comments if this ready to work on in the IETF? Dave: every BoF is attended by at least one IAB member and we advice the IESG of the architectural aspects on it. But the process for chartering a WG is run by the IESG. : a follow-up comment on the UDP discussion. pure client-server communications, TCP is the natural choice. If you need to use NAT-to-NAT it requires UDP.