Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA
On 09/06/2013 11:46 AM, Ted Lemon wrote: The threat model isn't really the NSA per se—if they really want to bug you, they will, and you can't stop them, and that's not a uniformly bad thing. I disagree, or at least, I think that your statement conflates two different threat models. One kind of threat is that the NSA will bug you specifically. And yes, if they consider it important to do so, they very likely will. There is almost certainly some vulnerability in your hardware or software or physical security, and they have lots of resources that can be invested in finding it. The other kind of threat, is that NSA will bug you because it's currently really easy for them to engage in mass surveillance. Most traffic isn't even encrypted; and at least some of what is encrypted is trivially broken. I don't think IETF can (or should) do much about the former kind of threat. Most of it is out of our scope.But we should be working hard to address the latter kind of threat. Keith
Re: Charging remote participants
On 08/16/2013 09:38 AM, Janet P Gunn wrote: ...I want it from people who can't get approval for even a $100 expense, from people who are between jobs, people from academia, and even from just plain ordinary users rather than just vendors or big corps. I agree. The realities of internal politics/funding being what they are, it is sometimes going to be just as hard to get $100 remote fee approved as it as to get the whole f2f trip approved. As someone who just spent $3.5K out of pocket to show up in Berlin, I have a hard time being sympathetic to someone who won't participate because he has to spend $100 out of pocket. Keith
Re: Radical Solution for remote participants
On 08/16/2013 04:59 AM, Joel M. Halpern wrote: Conversely, until the technology gets that good, we must not penalize the face-to-face meeting for failures of the technology. Unfortunately, we've been doing that for many years, e.g. by forcing speakers to queue up at the microphones, and by arranging seating so that it's difficult to get to the microphones unless you're seated near an aisle. If you actually think you might want to speak at a f2f meeting, you need to show up early (forgoing any potentially valuable hallway conversations) and get a seat near an aisle. Keith
Re: Charging remote participants
On 08/16/2013 11:36 AM, Hadriel Kaplan wrote: On Aug 16, 2013, at 10:56 AM, Keith Moore mo...@network-heretics.com wrote: As someone who just spent $3.5K out of pocket to show up in Berlin, I have a hard time being sympathetic to someone who won't participate because he has to spend $100 out of pocket. This isn't about fairness or equal-pain-for-all. It's about getting work done and producing good output. Whether someone remote has to pay $0 or $1000 won't change your $3.5k out-of-pocket expense. If you don't feel the $3.5k was worth it for you to go physically, don't go. I'm all about having IETF get work done and produce good output. May I suggest that we start by trying to reduce IETF's longstanding bias in favor of large companies with large travel budgets that pay disproportionate attention to narrow and/or short-term interests, and against academics and others who take a wider and/or longer view? The Internet has suffered tremendously due to a lack of a long-term view in IETF. To that end, I'd like to see IETF do what it can to reduce meeting costs for those who attend face-to-face, rather than increase those costs even more in order to subsidize remote participation. I have reached the difficult (i.e. expensive) conclusion that the only way to participate effectively in IETF (except perhaps in a narrow focus area) is to regularly attend face-to-face meetings. There are several reasons for this, just a few of which (off the top of my head) are: (1) It's really hard to understand where people are coming from unless/until you've met them in person. I had been participating in IETF for about a year before I showed up at my first meeting, and I still remember how (2) It's much easier to get a sense of how a group of people react to a proposal in person, than over email. (3) For several reasons, people seem to react to ideas more favorably when discussed face-to-face. (4) It's easier to get along well with people whom you see face-to-face on at least an occasional basis, so people whom you've met face-to-face are more likely to appreciate constructive suggestions and to interpret technical criticism as helpful input rather than personal attacks. (5) Among the many things that hallway conversations are good for are quickly settling misunderstandings and resolving disputes. I realize that a better remote participation experience might help with some or all of these, but I think we're decades away from being able to realize that quality of experience via remote participation, at least without developing new technology and spending a lot more money on equipment. If someone wants to fund development of that technology and purchase of that equipment separately from the normal IETF revenue stream, more power to them. But I do suspect that at some point it will cost money to maintain that technology and equipment, and again, I suspect it shouldn't primarily come from people who are paying to be there in person. Or if we're really about trying to make IETF as open as possible, then we should be willing to publicly declare that people can participate in face-to-face meetings without paying the registration fee. [*] But I don't think that IETF's current funding model can support that. So maybe IAOC should give serious thought to changing the model, but offhand I don't know what a better model would be. Should IETF become a membership organization, and let some of the administrative costs be borne by membership fees, so that meeting costs can more accurately reflect the cost of hosting meetings? How would the organization provide benefits to paying members without excluding participation from others? I don't expect that there are any obviously right answers to questions like those - everything involves compromise - but it might be that there are far better answers to those questions than those that have been assumed for the past 20 years or so. [*] I do realize that some people have, on occasion, shown up as tourists for the benefit of hallway and bar conversations, and avoided paying the meeting fee.
Re: Faraday cages...
On 08/09/2013 09:39 AM, Ted Lemon wrote: On Aug 8, 2013, at 9:05 PM, Keith Moore mo...@network-heretics.com wrote: Would being able to reliably know exactly who said everything that was said in a WG meeting visibly improve the quality of our standards? If the answer is not a clear yes (and I don't think it is) then I suggest that this topic is a distraction. If you mean will it improve what is written on the page, probably not. Will it decrease the likelihood of someone participating without identifying themself, and then violating the IPR rules? Possibly. AFAIK that's why we do it. Not so much because it is an iron-clad preventative, but because it to some degree removes the illusion of anonymity that might tempt someone to do something like that, or just be careless about it. If it's that important to catch people violating the IPR rules, perhaps we need to hire a court reporter for every WG meeting, and not rely on volunteer Jabber scribes to accurately capture what is said and who said it. Keith
Re: Faraday cages...
On 08/08/2013 07:41 PM, Phillip Hallam-Baker wrote: Hmmm didn't a certain large company whose name rhymes with scroogle recently get whacked with a huge fine for violating privacy in a similar manner in the EU? The rules are different for large companies with funny names. Keith
Re: Faraday cages...
On 08/08/2013 08:48 PM, Phillip Hallam-Baker wrote: Barcodes have the potential to work really well and require almost no change from current practice. Except that current practice is broken anyway and we desperately need to change it, not add more mechanisms to reinforce continued use of it. Actually I think all of this emphasis on being able to reliably identify every speaker is a bit beside the point. With rare exceptions, who is speaking is not nearly as relevant as what is being said. Of course there are times when it's important or useful to know who is speaking - say if it's an AD, or the document author/editor, or a person with whom there needs to be a followup discussion. But when we find ourselves working so hard to make sure that we can reliably identify every speaker (and perhaps also to exclude anonymous / pseudonymous input), maybe that's a distraction. Maybe we should instead be concentrating on how to make sure that our standards have been written in light of a wide degree of input about requirements, are technically sound, and have enjoyed thorough review. Would being able to reliably know exactly who said everything that was said in a WG meeting visibly improve the quality of our standards? If the answer is not a clear yes (and I don't think it is) then I suggest that this topic is a distraction. Keith
Re: [iaoc-rps] RPS Accessibility
On 08/07/2013 02:26 AM, Riccardo Bernardini wrote: Just thinking out aloud What about a web-cam (maybe a wireless one? Never tried to use them...) right under the mic, so that it takes a picture of the badge and shows it on the screen? Everyone (right?) in a meeting has a badge wit his/her/its:) name and affiliation, so privacy concerns are just comparable to those of wearing a badge. Except that this would preclude use of portable/wireless microphones to let people engage in more effective conversation. Even if there continues to be some sort of queue or other discipline to determine who speaks next, we need to get away from the habit of forcing people to walk through narrow rows of chairs and stand in a queue behind a fixed-location microphone in order to speak. Keith
Re: procedural question with remote participation
On 08/04/2013 02:54 PM, Ted Lemon wrote: While I think getting slides in on time is great for a lot of reasons, reading the slides early isn't that important. What is important is that remote people see the slides at the same time as local people. For that, it seems to me that Meetecho support does exactly what is needed. You just follow the slideshow online, along with the audio. I agree that remote people should see the slides at the same time as local people, except that I think that in both cases this should be well before the meeting. The slides shouldn't be shown at the meeting unless needed to illustrate a point of active discussion. People keep acting as if the purpose of these meetings - the reason people spend thousands of euro and travel thousands of km - is to watch slides. Keith
Re: procedural question with remote participation
On 08/06/2013 11:06 AM, Andrew Feren wrote: On 08/06/2013 09:08 AM, Keith Moore wrote: On 08/04/2013 02:54 PM, Ted Lemon wrote: While I think getting slides in on time is great for a lot of reasons, reading the slides early isn't that important. What is important is that remote people see the slides at the same time as local people. For that, it seems to me that Meetecho support does exactly what is needed. You just follow the slideshow online, along with the audio. I agree that remote people should see the slides at the same time as local people, except that I think that in both cases this should be well before the meeting. The slides shouldn't be shown at the meeting unless needed to illustrate a point of active discussion. People keep acting as if the purpose of these meetings - the reason people spend thousands of euro and travel thousands of km - is to watch slides. Hi Keith, I think this sort of misses the point. At least for me as a remote participant. Actually I think the desire to get slides out early largely misses the point. Or at least, it's an effort optimizing what should be the rare case. I fully agree that slides should be easily available to both local and remote participants well prior to any meeting in which a presentation will be made. (Say a plenary session where presentations are normal and appropriate.) While speakers might like to revise their slides at the last minute, there's no reason why they shouldn't be expected to upload preliminary slides well in advance (because the key to an effective presentation is good preparation, after all) and a revised version (if necessary) later. This isn't at all rocket science, and there's no reason why it should not be done. But if we really want to make remote participation effective, we need to figure out better ways to involve remote participants in _discussions_ - not only in plenaries, WG meetings, BOFs, etc., but also in hallway and bar conversations. Having a local speaker read something from a laptop that was typed into a Jabber session by a remote participant is better than nothing. But surely we can do better. As of today when the slides are available (or if there are no slides and just talk) I can follow WG meetings quite well. Being able to actively engage in any discussion remotely is, IMO, pretty much limited to the mailing lists. Getting involved in an active discussion at a WG meeting remotely is currently difficult at best and impossible at worst. It used to be the case that Internet access at IETF meetings was flaky, either because of the wireless network or because of the network connection or both. More recently the performance of the meeting Internet access has been stellar. If we put the same kind of effort into facilitating remote participation in discussions, I suspect we could move from difficult at best and impossible at worse to works well. Of course, it might take awhile, but it's those very kinds of discussions that are so essential to broad consensus that (when it works) makes our standards effective. The fact that it doesn't work well now is not a good argument for not making it work well in the future. (We're supposed to be creating the future, after all. That's our job.) It's also the case that the fact that facilities for involving remote participants in conversation haven't historically worked well, is used as a justification for continuing to have this dysfunctional style of conducting working group meetings, thus making very poor use of local participants' time and money. I'm all for making presentation slides available to local and remote participants well before the meeting. But if we're only concerned with making presentation slides available, we're selling ourselves very short. That's the point I'm trying to make. Keith
Re: [iaoc-rps] RPS Accessibility
On 08/06/2013 04:03 PM, Melinda Shore wrote: On 8/6/13 11:58 AM, Joe Abley wrote: For what it's worth (not much) I would miss the line at the mic. There are useful conversations that happen within the line that I think we would lose if the mic followed the speaker, and I also think that pipelining the people at the mic promotes more fluid conversation. But these are minor points, and I'm mainly just waxing nostalgic. I actually think that this is not a small point. The people in line are the people with issues and the ability to hash stuff out quickly is pretty nice. This only works if the queue is fairly short. When the queue gets longer, and the microphones are in fixed positions, it's not unusual for the topic to jump around from one speaker to the next - and then each speaker has to re-establish what context he's talking about. It's very hard to get convergence under those conditions. I'd actually like to see the microphone queue discipline replaced with something that could handle more than two currently active speakers. Multiple wireless microphones would probably work well enough, if we could change the room setup to make access to those microphones fairer. (though it could still be challenging to incorporate remote speakers into the mix) Keith
Re: Berlin was awesome, let's come again
On 08/06/2013 07:36 PM, John C Klensin wrote: ... IETF 39 was in Munich (August 1997) ArabellaSheraton @ Arabella Park, and it was HOT pretty much the whole week. If I recall, another very successful meeting in a place we should go back to. I liked Munich as a destination. But the hotel / meeting facility in Berlin far surpassed the Sheraton in Munich in every way imaginable. Keith
Re: Bringing back Internet transparency
On Aug 1, 2013, at 9:14 PM, Noel Chiappa wrote: From: Phillip Hallam-Baker hal...@gmail.com The ISPs had a clear interest in killing of NAT which threatened the ISP business model. So this is rather amusing: you're trying to tell me that ISPs wanted to kill NAT, and I have other people telling me NAT was an intergral part of ISPs' master plan to take over the universe. Clearly you all both can't be right. ISPs were against NATs at first. It was only later that they embraced them. Keith
Re: Berlin was awesome, let's come again
On Aug 2, 2013, at 1:09 PM, Eggert, Lars wrote: Hi, On Aug 2, 2013, at 13:04, Russ Housley hous...@vigilsec.com wrote: I have also enjoyed my time in Berlin. However, we need to complete the analysis on the impact of VAT. I hope there is a way to avoid a cost to each participant of an 19%. We heard in plenary that VAT clearly applies to conferences, but it may not apply to standards meeting. agreed. It's not just the 19% VAT. I found fares to Berlin several hundred USD more expensive than fares to other European cities. But I agree that the city and the hotel were a splendid location for an IETF conference. Snarky side comment: We should also analyze the impact of over-the-top tipping customs in some countries :-) seems fair. Keith
Re: Berlin was awesome, let's come again
On Aug 2, 2013, at 1:27 PM, Yoav Nir wrote: In the grand scheme of things, it's less than the room price for one night (unless you're staying at some particularly cheap motel, and those are more available in the US). The availability of less expensive nearby hotels was also a plus for the Berlin location, and is something that should be considered for any location. My hotel room (perfectly adequate and quite close to the IC) was far less per night than the amount of VAT imposed on the conference. Keith
Re: making our meetings more worth the time/expense
On Jul 30, 2013, at 10:38 PM, Brian E Carpenter wrote: It's been pointed out before that in a group with very diverse languages, written words are usually better understood than speech. It's a fact of life that you can't have a full-speed cut-and-thrust discussion in a group of 100 people, half of whom are speaking a foreign language. Sitting in a circle does not fix this. Yes, but most of the people in a typical WG meeting today aren't really participating in the meeting anyway. They're not contributing input, they're not paying attention. Their noses are in laptops. It's hard to tell how many of them would be participating if the meeting were more useful, but the very fact that the room contains so many nonparticipants is itself a deterrent to getting work done in the meeting. If nothing else, whenever someone tries to get a sense of the room, it's very misleading - people may be humming when they haven't even been listening, or it may appear that there's no significant support for something when there really is significant support among those who are interested in the topic. Also, remote participants need full text slides; the soundtrack simply isn't enough. You seem to be assuming that the purpose of WG meetings is to have presentations. I emphatically disagree. If we decide to make WG meetings fora for interaction and discussion, we can adopt or invent disciplines and tools to better accommodate interaction and discussion between people of diverse languages and including those at other locations. But the disciplines and tools that we've adopted at the moment are designed to accommodate an audience, not active participants. The old days are gone. It sounds like you are saying that IETF is doomed to become irrelevant because it's stuck in habits that do not work. I hope you're wrong about that. Keith
Re: making our meetings more worth the time/expense (was: Re: setting a goal for an inclusive IETF)
There are occasions when presentations are appropriate, but they should be the exception rather than the rule or default assumption. Sent from my iPhone On Jul 31, 2013, at 1:52 PM, Abdussalam Baryun abdussalambar...@gmail.com wrote: IMHO, The presenters are MUST, but the time channel for presenting is the problem or boring factor. I mentioned before that we need short presentations 5 minutes, and more discussions. AB On Tue, Jul 30, 2013 at 9:30 PM, Keith Moore mo...@network-heretics.com wrote: On Jul 30, 2013, at 7:47 PM, Bob Braden wrote: On 7/30/2013 9:35 AM, Noel Chiappa wrote: Easy fix: 'slide' (well, nobody uses real slides anymore :-) rationing. E.g. if a presenter has a 10 minute slot, maximum of 3 'slides' (approximately; maybe less). That will force the slides to be 'discussion frameworks', rather than 'detailed overview of the design'. Noel Noel, I tried the 3 slide limit in the End2end Research Group some years ago, and it did not work very well. Presenters just can't discipline themselves that much, no matter how hard you beat on them. Maybe the first step is to stop having presenters. Keith
Re: making our meetings more worth the time/expense (was: Re: setting a goal for an inclusive IETF)
On Jul 31, 2013, at 10:30 AM, Donald Eastlake wrote: The most valuable part of IETF meeting is and has always been the hall conversations and side meetings The hall conversations and side meetings will continue to be immensely valuable. But working group sessions can, and should, also be valuable. This gets back to my original point, which is that if we want to encourage broader participation in IETF we need to make participation in IETF work the participants' time and money. Also, if we help working group sessions make better use of their time, WGs will reach closure more quickly. Hardly anybody, I suspect, would mind that. Keith
Re: making our meetings more worth the time/expense
On Jul 31, 2013, at 10:55 PM, Brian E Carpenter wrote: It's hard to tell how many of them would be participating if the meeting were more useful, but the very fact that the room contains so many nonparticipants is itself a deterrent to getting work done in the meeting. If nothing else, whenever someone tries to get a sense of the room, it's very misleading - people may be humming when they haven't even been listening, or it may appear that there's no significant support for something when there really is significant support among those who are interested in the topic. That's true; I am much more suspicious of sense of the room consensus calls than I am of sense of the mailing list calls. But pretty much all WG Chairs do what they're supposed to by confirming the consensus on the list. When binding decisions are being made, this is of course the right thing to do. But we still need an accurate sense of the room (from active participants) just to make good use of meeting time - so (for example) we can know whether or not it appears that a problem has been discussed sufficiently and/or addressed. Of course we have to consult the mailing list in order to be sure we have rough consensus, but it's also very important to take advantage of face-to-face time to attempt to work out solutions to thorny problems. So the failure to get an accurate sense of the room might not necessarily mean that the wrong decision is made, it might mean that the decision doesn't get made until much later - maybe after there have been another one or two meetings. Also, remote participants need full text slides; the soundtrack simply isn't enough. You seem to be assuming that the purpose of WG meetings is to have presentations. I emphatically disagree. The purpose is to communicate, including communication with remote participants. Sometimes that means explaining things that are, perhaps, badly explained in the draft - and getting back comments that show what needs to be changed in the draft. Sometimes, yes. But I doubt that should occupy the bulk of our meeting time. If we decide to make WG meetings fora for interaction and discussion, we can adopt or invent disciplines and tools to better accommodate interaction and discussion between people of diverse languages and including those at other locations. But the disciplines and tools that we've adopted at the moment are designed to accommodate an audience, not active participants. I don't think it's fair to blame the tools. We should be asking questions about how we use the tools. Some people don't see this, but I'm very convinced that the tools do have a significant effect on how we choose to convey our messages. Partly because of the hardware, partly because of the software, these tools are optimized for certain things and pessimized for others.It's pretty obvious that a laptop with a full-size keyboard and a poor pointing/drawing device is going to be much better at putting text on a screen than drawing diagrams.It's very easy to do what the tool makes it easy to do (typically put a few words of text on a screen) while losing sight of your purpose (typically to facilitate an interactive discussion with input from several parties). Part of the problem is indeed the tool's fault, or perhaps our fault for choosing the wrong tool for the job out of habit. It's not that visual aids are inherently bad. Properly chosen visual aids can really help facilitate a discussion. But a few words in large type on a small screen is rarely effective, and these screens aren't big enough and the projectors often lack the resolution needed to display adequate diagrams. Also, the tools are generally designed to produce static content, rather than let you manipulate the content while it's on screen (say to illustrate the answer to a question). The old days are gone. It sounds like you are saying that IETF is doomed to become irrelevant because it's stuck in habits that do not work. I hope you're wrong about that. No, I mean that we have to deal with a very diverse community and the style of discussion that was successful when you or I first started coming to the IETF isn't going to come back. I don't, unfortunately, have the magic formula. I'm not arguing that we need the same style of discussion that worked for IETF when it was ~300 people. You're right that we have a much larger and more diverse community now; we also have a much more diverse set of needs to consider in our designs. Because of all of this diversity, it's even more important that we let diverse voices be heard. We certainly need a better way to moderate discussions than either having the loudest people speak whenever they want, or forcing people to queue up at microphones.And yet, I think what we're doing now is actually far worse (even for our current circumstances) than what IETF was doing in
Re: making our meetings more worth the time/expense
On Jul 31, 2013, at 11:34 PM, Melinda Shore wrote: It may be the case in some instances that if it's going to be nothing but presentations there may not be a need for a working group to meet at all. +1. If nothing else, when a WG agenda starts to shape up like this, this should be a big red flag for chairs and ADs. Keith
Re: Bringing back Internet transparency
On Jul 30, 2013, at 3:23 PM, Noel Chiappa wrote: From: Roland Bless roland.bl...@kit.edu we probably need to do something on reducing the number of _broken_ middleboxes (or their implementations respectively) - I'm not focusing on NAT boxes here. ... I think it's clear that we will not get rid of them, but if I hear about boxes that try to do clever optimization or security by re-writing TCP sequence numbers ... bundling segments and so on, I'm wondering who actually engineered those boxes; aren't the vendors/engineers participating in the IETF? Who buys and deploys such boxes ... What could be IETF efforts to get a better situation for the deployment of future innovations or do we simply accept that (a few) broken middleboxes dictate the future level of innovation in the Internet? I hear you, but... this is not a simple problem. I think we need to start by understanding what drives the creation and deployment of these devices. I think the answer to that has to be that some people have needs that aren't being met by the IETF, and so there's an opportunity for private entities to create and sell 'solutions'. The IETF doesn't have a police force, or any enforcement mechanism. That's true, but people do sometimes cite IETF specifications as requirements for equipment procurement. And in many cases it is possible to test equipment for conformance to specifications. If we're going to head off these boxes, the only tool we have to do that is to build better mousetraps - i.e. design stuff that does what people want, is more cost-effective, and is better than these local 'point deployment' boxes. That's not the only tool (see above), but to the extent we're failing to address legitimate needs, we need to identify those needs and see what we can do to address them. And we need to do this as early as possible, ideally before we've gone down a particular path so far that there's too much deployment of a protocol that can't be retro-fitted to address those needs. We have no structure at all for doing this now. Sadly, the IETF has a long history of being hard-headed about 'my way or the highway', and not carefully listening to what the 'customers' are telling us about these various aspects of a successful design. I suspect it's worse than that. We don't even know who our customers are. (The most noteable example of this being NAT - which was going to be ugly anyway, but as a result of the IETF refusing to create an architected NAT solution - apparently on the theory that if we stuck our fingers in our ears and went la-la-la-la loud enough, it would Just Go Away - we now have NAT that is both ugly _and_ brittle [because it's not part of an architected _system_], difficult to work with because it [mostly] lacks any external control interface, etc.) It's ridiculous to say that we have NAT because we didn't architect NAT. NAT has never been a good idea from any long-term point of view. The only justifications that have ever existed for NAT were short-term hacks. Our mistake, in hindsight, was in not specifying NAT in such a way that they provided a transition path away from NATs. (perhaps something like PCP in conjunction with v4/v6 NAT, though there's a huge privacy/security problem with that kind of approach that I've never figured out how to address, so I'm inclined to think that PCP makes things still worse.) Though of course an underlying problem is that no vendor wants to sell hardware that will obsolete itself, unless of course it obsoletes itself by requiring the customer to purchase even more expensive hardware than it replaces.It's hard to see how IETF could fight against vendors who were making good money by making the network more complex, less reliable, and less flexible. Keith
making our meetings more worth the time/expense (was: Re: setting a goal for an inclusive IETF)
On Jul 30, 2013, at 3:53 PM, Jari Arkko wrote: We have discussed diversity at the IETF at length. Yesterday, Pete Resnick and I wrote an article about what we think the goal for the IETF should be, as well as listing some of the early activities that we have taken at the IETF. Our goal is making the IETF more inclusive for everyone who needs to be working on Internet standards. We are at the beginning, however, and a lot of work remains ahead. Here's the article: http://www.ietf.org/blog/2013/07/a-diverse-ietf/ Also, I wanted to let everyone know that tomorrow in the Administrative Plenary, Kathleen Moriarty and Suresh Krishnan will be talking about what they have uncovered so far in their efforts in the diversity design team. I'm looking very much forward to their report. Their efforts will help us understand where we have room to improve - often by much :-) - and what kinds of actions we can take to improve our inclusiveness. This is something that I've struggled with for years. A big part of the problem (from one point-of-view) is that we've become so geographically diverse in our choice of meeting sites that we've drastically raised the cost of attending meetings on a regular basis - everyone has to travel a lot to so (though people in North America still have an easier time of it). And while there are clearly things that could be done to reduce meeting costs, we'd be doing very well to reduce total trip cost by more than say 15%. But earlier today I realized that the problem isn't just the cost of attending meetings - it's the value that we get in return for those meetings. I've been taking notes about how ineffectively we use our meeting time. Most of what I've observed won't surprise anybody, but here's a summary: WG meeting sessions aren't scheduled to encourage discussion, but to discourage it. At meeting after meeting, in several different areas, I see the lion's share of the time devoted to presentations rather than discussion. Similarly, WG meetings generally aren't run in such a way to facilitate discussion, but to discourage it. It's only Tuesday afternoon and I've already lost count of how many times I've heard a meeting chair tell people that they have to stop discussing things because there are more presentations to do. Rooms are set up not to facilitate discussion, but to discourage it. The lights are dim, the chairs are facing forward rather than other participants, the projector screen (not the person facilitating a discussion, even if someone is trying to facilitate a discussion) is the center of attention.The chairs are set so close together and with so few aisles that it's hard for most of the attendees to get to the mics. The microphone discipline which was intended to facilitate remote participation ends up making discussion more difficult for everybody who has paid to be on site. In the vast majority of WG sessions, everyone has his nose in a laptop. (me included). This is because the information being presented at the moment is generally not valuable enough to occupy the attendees' attention. The attendees are there for one of two reasons - either they're just trying to absorb some low-value information while still doing something else that is more useful, or they're waiting for some opportunity to actually interact - either within the context of that WG meeting or afterward (perhaps because the best way to catch a particular person is often to show up at a WG meeting that that person is attending.) All of these things have been standard practice, in IETF and elsewhere, for so long, that hardly anyone questions them. They have to be that way because they're habit, and even if one or two people try to change things (and I realize some ADs are trying), they have to contend with the mindless habit-driven decisions of everyone else involved. Well, please excuse my candor, but f*ck habit. We can't be effective engineers if we let bad habits continue to dictate how we work. -- My expenses for this meeting are around USD 2.500. Some are paying more, some less, but if we multiply average expense times the number of people attending, that's a tremendous amount of money. Add that value is dwarfed by the value of the people's time that is being spent here. We are spending this time to travel to meet face-to-face, not so that we can see PowerPoint all day for a week, but so we can interact. Presentations, for the most part, do not help. They get in the way. Visual aids can help to facilitate a discussion, but they should be as brief as possible, and the room setup, meeting schedule, etc. should not be optimized for the visual aids. They should be optimized for discussion. For 80% of most WG meetings, the lights should be bright, the participants should face each other. If there's a person facilitating the discussion that person should be the center of
Re: Bringing back Internet transparency
On Jul 30, 2013, at 5:55 PM, Josh Howlett wrote: Though of course an underlying problem is that no vendor wants to sell hardware that will obsolete itself, unless of course it obsoletes itself by requiring the customer to purchase even more expensive hardware than it replaces.It's hard to see how IETF could fight against vendors who were making good money by making the network more complex, less reliable, and less flexible. Personally I would characterise this as a demand-side problem, not supply-side: most users plainly aren't willing to pay for Internet transparency. I don't think that's the problem; I think the problem is that most users don't realize how much lack of transparency is harming them. So transparent Internet access isn't a commodity.Transparency would be cheaper if there were more demand for it, and there would be more demand for it if people realized how much more utility they'd get out of the Internet if they had it. Keith
Re: making our meetings more worth the time/expense (was: Re: setting a goal for an inclusive IETF)
On Jul 30, 2013, at 7:47 PM, Bob Braden wrote: On 7/30/2013 9:35 AM, Noel Chiappa wrote: Easy fix: 'slide' (well, nobody uses real slides anymore :-) rationing. E.g. if a presenter has a 10 minute slot, maximum of 3 'slides' (approximately; maybe less). That will force the slides to be 'discussion frameworks', rather than 'detailed overview of the design'. Noel Noel, I tried the 3 slide limit in the End2end Research Group some years ago, and it did not work very well. Presenters just can't discipline themselves that much, no matter how hard you beat on them. Maybe the first step is to stop having presenters. Keith
Re: Remote participants, newcomers, and tutorials
On Jul 29, 2013, at 3:59 PM, t.p. wrote: I think the points you make below are good, once the newcomer to the IETF has found their working group. This is not always easy. Fine if your interest is in OSPF, ISIS, TLS, TCPMaintenance but in other spheres, the IETF approach of choosing a 'witty' name seems to me less than welcoming. Think about it as a stranger to these parts. What comes to mind when you encounter; salud, straw drinks insipid lemonade - behave, kitten vipr, cuss! I was thinking this morning that clever short WG names are fine, but we shouldn't try too hard to make them acronyms - or at least, we shouldn't pretend that the acronyms suffice as descriptions for the WGs. In lists of WGs, we should include brief descriptions of the WGs, not the acronym expansions. Keith
Re: Remote participants, newcomers, and tutorials
On Jul 28, 2013, at 6:17 AM, Melinda Shore wrote: On 7/27/13 8:13 PM, Randy Bush wrote: yup. i guess it is time for my quarterly suggestion to remove the projectors and screens. Then I guess it's time for my quarterly I'd be good with that. As would I. Keith
Re: IAB Statement on Dotless Domains
On 07/12/2013 08:16 AM, Phillip Hallam-Baker wrote: And before people start bringing up all the reasons I am wrong here, first consider the fact that for many years it was IETF ideology that NATs were a terrible thing that had to be killed. A position I suspect was largely driven by some aggressive lobbying by rent-seeking ISPs looking to collect fees on a per device basis rather than per connection. You are weakening your argument. NATs still are a terrible thing that need to be killed. They break applications and prevent many useful applications from being used on the Internet.That much is more widely understood now than it was 10-15 years ago. Keith
Re: IAB Statement on Dotless Domains
On 07/12/2013 09:28 AM, Phillip Hallam-Baker wrote: On Fri, Jul 12, 2013 at 8:58 AM, Keith Moore mo...@network-heretics.com mailto:mo...@network-heretics.com wrote: On 07/12/2013 08:16 AM, Phillip Hallam-Baker wrote: And before people start bringing up all the reasons I am wrong here, first consider the fact that for many years it was IETF ideology that NATs were a terrible thing that had to be killed. A position I suspect was largely driven by some aggressive lobbying by rent-seeking ISPs looking to collect fees on a per device basis rather than per connection. You are weakening your argument. NATs still are a terrible thing that need to be killed. They break applications and prevent many useful applications from being used on the Internet.That much is more widely understood now than it was 10-15 years ago. The Internet has less than 4 billion addresses for well over six billion devices. No, the Internet has approximately 2**128 addresses. NATs are a large part of the reason that IPv6 adoption has been delayed. I think that at this point you are the only person still making the argument that the world should reject the easy fix for IPv4 address exhaustion that solves their problems at negligible cost to them for the sake of forcing them to make a transition that would be very difficult, expensive and impact every part of the infrastructure. You are wrong both about solving the problems and negligible cost. (And the real issue isn't so much the cost, but who pays.) But it would be nice if at least one of those people who argued against me when I was making the case for NAT that has now become the accepted approach would say 'hey Phill you were right there, I am sorry for implying that you were an evil heretical loon for suggesting it'. Not that I am holding my breath waiting. If you were right, someone might say that. Most folk here value consensus. I do not value consensus when it is wrong. Nor do I. Keith
Re: IETF registration fee?
On 07/11/2013 11:17 AM, John C Klensin wrote: --On Thursday, July 11, 2013 10:34 -0400 Phillip Hallam-Baker hal...@gmail.com wrote: ... Using paid conferences as a profit center is a risky long term prospect at best. Refusing to adapt the format of the conferences to protect the profit center worse. Or adapting the format to attract more paying attendees, such a what we have sometimes called tourists, with no real expectation that they will do work, because it increases the income. Still better than building a funding structure based on sale of publications, however :-( The best idea that I've come up with would be for IETF to offer tutorials (not at IETF meetings, but at other times and places) to teach people about current and emerging Internet technology, and use the proceeds from those to pay for its standards-making and -maintenance efforts. Part of the function of the tutorials could be to serve as a means of getting user feedback for just how well IETF standards were or were not meeting their needs. Of course, there are hazards associated with any approach. One could imagine, for instance, that the IETF tutorial division could end up being much larger than the IETF standards division, and that IETF standards making would suffer from the desire to optimize performance of the cash cow. Or that there would be conflicts between what the teachers taught as best practices, and the practices recommended by IETF standards. At any rate, it certainly would be a significant change from the current way we operate. Keith
Re: IETF registration fee?
On 07/11/2013 11:39 AM, Moriarty, Kathleen wrote: The tutorials is an interesting idea. I think youtube videos may be effective as well without having to schedule meetings for tutorials. Note that I was suggesting tutorials as a revenue source for IETF. I doubt that youtube videos would work well for this. Keith
Re: IETF registration fee?
On 07/11/2013 04:50 PM, Brian E Carpenter wrote: Douglas, ... Those traveling thousands of miles already confront many uncertainties. Those that elect to participate remotely should be afforded greater certainty of being able to participate when problems occur at local venues or with transportation. Increasing participation without the expense of the brick and mortar and travel should offer long term benefits and increased fairness. How much would you be willing to pay for remote participation (assuming it was of high quality)? Not much. Remote participation misses the whole point of IETF meetings. Sure, it's useful to be able to listen on WG sessions and make a comment or two. But the WG sessions generally aren't actually worth very much, especially the way that they tend to be run these days. The most important work gets done in the hallways and over food and drink. So IETF is in this very strange position of supporting itself by charging a large amount of money for an activity that's mostly peripheral to getting useful work done. Keith
Re: IETF registration fee?
On 07/11/2013 06:24 PM, Andrew Allen wrote: I think that misses the point. The WG sessions are where the issues are raised and the opinions and positions are stated. As far as I can tell, these days the WG sessions are where endless PowerPoint presentations are held and bored people check email. Keith
Re: IETF registration fee?
On 07/10/2013 02:50 PM, Donald Eastlake wrote: The IETF values cross area interaction at IETF meeting and attendees have always been encouraged to attend for the week. Allowing one day passes is a recent phenomenon to which some people, including myself, are on balance opposed. I'm also of the opinion that the one-day passes were a bad idea. We have too little cross-group and cross-area participation, too many groups working at cross-purposes, and too little attention paid to the implications of any one new protocol on the Internet architecture. We have become very overspecialized and we need to see what we can do to discourage this trend. Keith
Re: IETF registration fee?
On 07/10/2013 05:17 PM, Josh Howlett wrote: Day passes have nothing to do with it. I disagree. Day passes encourage the notion that it's normal to parachute into the IETF to attend a single session. I think that the IETF's strength is that we don't totally compartmentalise work items. I am perplexed that there is, on the one hand, a (valid, IMHO) concern about increasing IETF diversity participation, when there appears to be an active policy of discouraging potential participants who simply wish to get work done in some specific sessions. Superficially, it would seem that making participation more flexible and affordable might help to improve diversity participation. There's more than one kind of diversity. IETF (and its work) would greatly benefit from participants who work in more diverse areas, including areas within IETF and/or outside of IETF. IETF has a long history of giving too much favor to narrow and/or short-term interests. The long-term viability of the Internet continues to suffer because of this bias. Keith
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
On 05/20/2013 04:08 PM, Brian E Carpenter wrote: Publication of EUI-48 or EUI-64 addresses in the global DNS may result in privacy issues in the form of unique trackable identities. This might also result in such MAC addresses being spoofed, thereby allowing some sort of direct attack. So it isn't just a privacy concern. ... These potential concerns can be mitigated through restricting access to zones containing EUI48 or EUI64 RRs or storing such information under a domain name whose construction requires that the querier already know some other permanent identifier. This can be seems too weak. Shouldn't we have a MUST here? Also, I doubt that the second option (a shared secret) is sufficient. And yet, multifaced DNS is also a bad idea, and probably not the sort of thing that IETF should encourage with a MUST. Publishing EUI-XX addresses in the DNS is a bad idea. I get the impression that we're bending over backwards to try to create new security risks with this document, and people are trying to justify it by citing freedom to innovate. IMO, that's not the kind of innovation that IETF should be endorsing. Keith
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
On 05/21/2013 10:04 AM, Joe Abley wrote: On 2013-05-21, at 09:36, Keith Moore mo...@network-heretics.com wrote: Publishing EUI-XX addresses in the DNS is a bad idea. With respect, *my* question as the author of this document is simply whether the specification provided is unambiguous and sufficient. It was my understanding that this was the question before the community in this last call. The criteria for Proposed Standard are quite a bit higher than that. See RFC 2026 section 4.1.1. TThe topics of whether the current RRType assignment process is appropriate, or whether storing these IEEE addresses in the DNS is a good or bad idea or whether sub-typing would be useful in any as-yet unknown future use case seem entirely tangential. Assignment of the RR types (though IMO unfortunate) is a separate issue.Granting Proposed Standard status would essentially be an endorsement of this practice by IETF. This is not to say they are not useful topics, but I don't see how they relate to this document. Whether or not this document proceeds has nothing to do with any of that. I get the impression that we're bending over backwards to try to create new security risks with this document, and people are trying to justify it by citing freedom to innovate. IMO, that's not the kind of innovation that IETF should be endorsing. I have no real idea where you get that impression. The goal of this document is to document the use of RRTypes that have already been assigned, to provide a more structured option for encoding data that is already published in the DNS using non-interoperable and clumsy encoding schemes. Nothing more. Perhaps Informational or Experimental would be a better label for this document, then. Keith
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
On 05/21/2013 11:46 AM, joel jaeggli wrote: With respect to the question of proposed standard. What changes if the requested status is informational? I think just get rid of the normative language - SHOULDs, MUSTs, etc. Given that the RR types have already been assigned, documenting them seems entirely appropriate. Keith
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
On 05/21/2013 11:52 AM, Joe Abley wrote: On 2013-05-21, at 11:50, Keith Moore mo...@network-heretics.com wrote: On 05/21/2013 11:46 AM, joel jaeggli wrote: With respect to the question of proposed standard. What changes if the requested status is informational? I think just get rid of the normative language - SHOULDs, MUSTs, etc. From the perspective of giving guidance to people implementing these RRTypes, it seems to me that the normative language is useful, perhaps even necessary, to ensure interoperability. I admit I have not done my homework here; is the suggestion that the 2119 normative language cannot (MUST NOT? :-) appear in an informational document? 2119 language is intended to describe requirements of standards-track documents.Informational documents cannot impose requirements. Keith
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
On 05/21/2013 11:57 AM, Joe Abley wrote: On 2013-05-21, at 11:56, Keith Moore mo...@network-heretics.com wrote: 2119 language is intended to describe requirements of standards-track documents.Informational documents cannot impose requirements. Then I think we've just identified a reason why this document should be on the standards track. Actually I think that what we need is a BCP that says that DNS is not intended, not designed, and SHOULD NOT be used for dissemination of any information that is not deemed acceptable for widespread public distribution. Neither the DNS protocol nor DNS implementations are designed to meet the security requirements of such applications, and DNS is too widely deployed to change that. Keith
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
The scope of RFC 2119 is clearly standards-track documents. Documents that aren't standards should not be worded as if they were; this is likely to cause confusion about the status of the document. Sent from my iPhone On May 21, 2013, at 12:08 PM, Paul Hoffman paul.hoff...@vpnc.org wrote: On May 21, 2013, at 8:56 AM, Keith Moore mo...@network-heretics.com wrote: 2119 language is intended to describe requirements of standards-track documents. Can you support that statement with a reference to an RFC or an IESG statement that supports it? Informational documents cannot impose requirements. Same request. I don't find either statement supported by RFC 2119 or 2026, or any updates to the latter, but I may have missed it. --Paul Hoffman
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
On 05/21/2013 01:35 PM, joel jaeggli wrote: On 5/21/13 9:02 AM, Keith Moore wrote: On 05/21/2013 11:57 AM, Joe Abley wrote: On 2013-05-21, at 11:56, Keith Moore mo...@network-heretics.com wrote: 2119 language is intended to describe requirements of standards-track documents.Informational documents cannot impose requirements. Then I think we've just identified a reason why this document should be on the standards track. Actually I think that what we need is a BCP that says that DNS is not intended, not designed, and SHOULD NOT be used for dissemination of any information that is not deemed acceptable for widespread public distribution. The basically rules out every internal split horizon use of DNS in existence. Indeed. Things have gotten way too far out of hand. Again, DNS was not engineered for this purpose, and the hacks that people have employed like split-horizon DNS do not and cannot fix the underlying problems. Keith
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
On 05/21/2013 12:30 PM, Paul Hoffman wrote: Documents that aren't standards should not be worded as if they were; this is likely to cause confusion about the status of the document. I'm pretty sure that you as AD approved Informational RFCs that used 2119 language, and that this was discussed during your tenure on the IESG. My recollection is that other ADs were the ones who insisted that 2119 language not be used for Informational documents. I was more concerned about other things, but I could see their point. If the document is going to be published as Informational, rewording the document to remove 2119 language is my recommendation. But it's not something I feel like making a huge fuss over. If the document is still being considered as Proposed Standard, 2119 language would be appropriate. But I believe that this RRtype is fundamentally inappropriate for the standards track. Keith
Re: Proposed Standards and Expert Review
Without responding in detail to John's note, I'll say that I agree substantially with the notion that the fact that someone manages to get a protocol name or number registered, should not be any kind of justification for standardization of a document that describes use of that name or number. (For that matter, just because a document describes protocol data objects is also not a justification for standardization of that document.) More generally, IETF standardization should not be a rubber stamp. And to the extent that people have that notion, we would do well to discourage it. Keith
Re: Deployment of standards compliant nameservers
It seems like a first step might be to set up a web page and/or write up an I-D with a) a description of the problem b) documentation a procedure and/or code that can be used to test name server software for compliance c) recommendations for zone operators that delegate to other zones The next step might be for TLD operators to encourage the TLD registrars to (a) inform their customers of this issue, (b) test their customers' servers, and report the test results to their customers. Ideally those registrars would be able to refer their customers to updated or improved servers. Longer term it might be appropriate to do some other things, like a) define standard tests for compliance b) define a mechanism by which a server could be queried to find out its implementation name, version, etc. Keith p.s. I wonder if the problem you describe might at least partially be caused by DNS proxies and interception proxies, including but not limited to those incorporated in consumer-grade routers. On 05/20/2013 08:26 PM, Mark Andrews wrote: I call upon the IESG to discuss with IANA, the RIRs, ICANN and TLD operators how to deal with the problems caused by the deployment of non standards compliant nameservers. For a long time there have been operational problems cause by the deployment of non standards compliant nameservers that fail to respond to DNS queries directed at them or respond incorrectly. The biggest problem with respect to deployment of new types is nameservers that fail to respond to types they don't understand. RFC 1034 allows for several different responses: * name error * no error no data * not implemented * refused * formerr Name error and no error no data are the expected responses for queries with unknown types. This is reinforced by RFC 3597. But any of the other responses is acceptable. Failure to respond however is not acceptable. It introduces systematic timeouts which are indistinguishable from network errors without extended analysis of query response behaviour. While the percentage of nameservers misbehaving like this are relatively small they have a disproportionate effect on protocol development. They are also easily identifiable when looked for by querying for a know type at a name that is know to exist, the zone apex, that is supported by virtually all nameservers (e.g. A) and querying for a random unallocated type, then querying again for the original type. If you get a answer, no response, answer then the nameserver in question almost certainly has this issue and you are not looking at a dead server or network congestion issue. I'm not sure what the solution should be but regular audits of delegated nameservers by infrastructure operator and removal of delegations after a grace period to correct the faulty nameserver and checking of nameserver behaviour at registration time would go a long way to addressing the problem. Removal of the delegation is one of the suggested remediations identified in RFC 1034 for nameservers that are causing operational problems. It is not the first step by it is a step in the process. Mark
Re: Is this an elephant? [Was: call for ideas: tail-heavy IETF process]
On 05/17/2013 05:31 AM, Yoav Nir wrote: On May 17, 2013, at 12:58 AM, Keith Moore mo...@network-heretics.com wrote: On 05/16/2013 04:46 PM, Yoav Nir wrote: The time for asking whether the group has considered making this field fixed length instead of variable, or whether RFC 2119 language is used in an appropriate way, or whether the protocol is extensible enough is at IETF last call. Actually the time for asking these questions is long before IETF-wide Last Call. We need widespread review of proposals for standards-track documents long before a WG thinks it's finished with those documents. It's a gaping hole in our process. Sure. But we have opinionated ADs who read every draft that comes to the IESG. There is no way they have time to participate in all of the working groups. I, as a participant, can read drafts as they are discussed in working groups, because I'm free to ignore all the drafts that are not interesting to me. ADs don't have that luxury. Unless things have changed a great deal since I was on IESG, ADs do have the luxury of not reading drafts. When I was an AD I tried to read every draft that was in my area (Applications), and every draft that seemed to have the ability to affect applications developers.The lower in the protocol stack, the less likely that I'd feel like I'd have anything useful to say about a draft. Even when I read a draft outside of my area, in many cases it was just skimming the draft looking for red flags. I developed a pretty good sense of whether a group had done due diligence or whether there were serious technical omissions that they were trying to ignore. Only in the latter (rare) cases did I feel like such drafts needed more of my attention. I certainly agree that ADs don't have time to participate in all working groups, or even probably 10% of our working groups. But WGs should be able to periodically summarize what they're doing - what problem they're trying to solve, what approach they're taking, what technologies they're using, what major decisions they've made, what the current sticking points seem to be, what problems are as yet unresolved, what potential for cross-group and cross-area effects have been identified, and what efforts have been made to get the affected parties in the loop. For most groups that summary should be maybe 2-3 pages. The ADs should be able to verify that those summaries are accurate and reasonably complete, or appoint a trusted WG observer other than the chair to review each summary. ADs and other members of the community should be able to view those summaries and comment on their accuracy. And I think it would be reasonable for everyone on IESG to read through those summaries once in awhile - at least for groups that seemed likely to affect their areas of concern. I think that such summaries could actually lessen IESG's workload. Fix that problem, and most of the conflicts between IESG and WGs that surround DISCUSS votes will go away. Good reviewers are a scarce resource, and there are 500(*) working group drafts competing for their attention. That's a hard problem to fix. That's a related but IMO somewhat different problem. Working groups are producing far too many documents. That's one reason (far from the only one) why WGs shouldn't undertake documents that aren't specifically authorized in their charters. Keith
Re: Is this an elephant? [Was: call for ideas: tail-heavy IETF process]
On 05/17/2013 05:32 AM, Yoav Nir wrote: On May 17, 2013, at 1:38 AM, Fred Baker (fred) f...@cisco.com wrote: On May 16, 2013, at 1:46 PM, Yoav Nir y...@checkpoint.com wrote: There is a problem, though, that this will increase the load on ADs. Other concerns raised during IETF LC may lead to revised I-Ds, which the ADs will need to re-read (or at least look at the diff). I don't know how significant this extra work would be, but it would come at a time that we're thinking of ways to reduce AD workload. It might also require prolonging the LC time, because there would be actual discussion in it. If they raise the issue later in a discuss, will they not have to do this anyway? How does this relate to the timing of the comment or the vehicle by which it is conveyed? If you review early, you later might feel like you need to review again, because the document has changed some. Hence - more work. Yes, but you only need to review what has changed. It _can_ be more work, particularly for documents that have changed a lot, or if it's been too long since the last review.But I really wouldn't suggest that ADs should do several reviews of each document.I suspect that the trick is to review a document at the time the WG thinks that it's maybe 70-80% done (which is to say the WG is probably closer to 40-50% done), but when some issues still seem unresolved. That's when the ADs' input, and external input in general, can be the most valuable. That way, ADs should be able to say yes, but you're totally ignoring this very important issue here, and you really have to deal with it at a time when the WG isn't yet so exhausted or off in the weeds that it can't focus on it. Then the ADs just need to track the changes from that point forward, to make sure that the issues identified were dealt with satisfactorily. Of course new issues can still be identified, and WGs can address previously identified issues in unsatisfactory ways. But at some point (well prior to WGLC) it might be appropriate to raise the bar for new issues. At some point it should take a serious defect to significantly delay publication of a document, and at that point it might make more sense to consider other remedies for identified less-serious issues, especially if the existing protocol isn't seen to be actually harmful and it appears that the protocol can be extended to address the issues in a manner that is compatible with existing implementations. In those cases, it might make sense to go ahead and publish, but charter the WG to extend the protocol to address those issues. Keith
Re: Is this an elephant? [Was: call for ideas: tail-heavy IETF process]
On 05/17/2013 04:36 PM, Yoav Nir wrote: On May 17, 2013, at 6:37 PM, Dave Crocker d...@dcrocker.net wrote: On 5/17/2013 7:01 AM, Keith Moore wrote: But WGs should be able to periodically summarize what they're doing - what problem they're trying to solve, what approach they're taking, what technologies they're using, what major decisions they've made, what the current sticking points seem to be, what problems are as yet unresolved, what potential for cross-group and cross-area effects have been identified, and what efforts have been made to get the affected parties in the loop. For most groups that summary should be maybe 2-3 pages. The ADs should be able to verify that those summaries are accurate and reasonably complete, or appoint a trusted WG observer other than the chair to review each summary. ADs and other members of the community should be able to view those summaries and comment on their accuracy. The idea that working groups should be required to issue periodic project progress reports seems strikingly reasonable and useful. This makes the folks who are the most knowledgeable responsible for assessing their work, and should facilitate public review. Recording the sequence of reports into the wg datatracker could nicely allow evaluating progress over time. It also, of course, nicely distributes the work. d/ From: WG Chair To: ietf@ietf.org Sunbject: Progress Report - Foo WG There has been zero activity on the FOO list in the last three months (except for that Fake Conference message everybody got last month). I've tried emailing the WG document authors twice, but they're not answering my emails. So, the WG has 2 documents: draft-ietf-foo-use-cases-03, and draft-ietf-foo-proto-01. The use case document is just about done, but we haven't really started discussing the proto document. We haven't met in Orlando, and are unlikely to meet in Berlin That's it for this report. Cheers WGC Instead of a WG progress report, what I had in mind was a separate report for each work item. The report should briefly describe 1. The purpose of the work being undertaken 2. A description of the work being undertaken (including mention of major technologies on which the work is based) 3. All known parties and interests likely to be affected by the work 4. The current state of the work (what's been done, what hasn't been done) 5. Any major issues that have been identified but not resolved 6. Pointers to the WG's charter, the datatracker pages for each of the current draft document(s) associated with that work item, and any other useful material (e.g. open issues list, summaries of design decisions already taken and the rationale for each) A person who is knowledgeable about current Internet protocols should be able to read that single document and understand what the WG is doing with this particular work item, what state it's in, whether or not it will affect that person's are of interest, and where to look for detailed information. Keith
Re: Is this an elephant? [Was: call for ideas: tail-heavy IETF process]
On 05/17/2013 10:21 PM, Andy Bierman wrote: I notice that nowhere on this list is any mention of the charter milestones or dates. Is the Foo Proto draft due in 14 months or is it 14 months behind schedule? If the latter, why isn't the Foo WG meeting at the IETF? I don't think milestones will be useful unless and until: (a) they're defined in terms of not only concrete but also meaningful goals (e.g. complete problem definition, identify affected parties and groups representing their interests, complete outline of initial design, but NOT revise document X); (b) we start automatically suspending the activities of groups that fail to meet them (no meetings, no new I-Ds accepted, mailing list traffic blocked), until such groups are formally rechartered; and (c) IESG is reluctant to recharter groups that have repeatedly failed to meet milestones, especially if those groups haven't produced evidence of significant progress. Keith
Re: Is this an elephant? [Was: call for ideas: tail-heavy IETF process]
On 05/17/2013 10:37 PM, Andy Bierman wrote: On Fri, May 17, 2013 at 7:29 PM, Keith Moore mo...@network-heretics.com mailto:mo...@network-heretics.com wrote: I don't think milestones will be useful unless and until: (a) they're defined in terms of not only concrete but also meaningful goals (e.g. complete problem definition, identify affected parties and groups representing their interests, complete outline of initial design, but NOT revise document X); (b) we start automatically suspending the activities of groups that fail to meet them (no meetings, no new I-Ds accepted, mailing list traffic blocked), until such groups are formally rechartered; and (c) IESG is reluctant to recharter groups that have repeatedly failed to meet milestones, especially if those groups haven't produced evidence of significant progress. I think we can find some middle ground between ignore charter milestones completely and autobot to terminate WGs behind schedule. :-) Actually I think it might require an autobot. Because someone (probably the responsible AD) has to evaluate a WG's progress, and ADs don't want to take the heat for shutting WGs down. Better to put the responsibility on the chairs for completing the milestones and reporting to the AD before the shutdown deadline. (of course, there could be a generous grace period between the milestone deadline and the actual shutdown, with warning messages sent to the WG chairs and ADs, etc.) Keith
Re: call for ideas: tail-heavy IETF process
On 05/16/2013 01:44 AM, John C Klensin wrote: --On Thursday, May 16, 2013 00:55 -0400 Keith Moore mo...@network-heretics.com wrote: Which is to say, if there is only a single AD blocking a document, that block is essentially a 2 week affair if you are willing to push the point. No need for negotiating; if the WG decides that the AD is totally off base, tell your sponsoring AD that you're waiting the two weeks. People (unfortunately IMO) don't push the point nearly enough. I think it's very unfortunate that IESG has adopted rules that work this way. Part of IESG's job is to provide independent review of WG output. It that review can be circumvented merely by waiting two weeks, that's a bug in the process. And if an AD raises a DISCUSS about a matter of technical or document quality (or for that matter, about a process violation), and the WG isn't even willing to discuss the point, but instead relies on the two week timeout, I think that's grounds for appeal to the IAB. Keith, I generally agree with Pete although I share your low opinion of a lot of current IETF work, but your comment above seems to call for comment from someone, like myself, who has often been critical of the IESG. I don't think the current rules are ideal, but the effect of the ones that you and Pete cite isn't really that a WG can circumvent a review by waiting two weeks. First, the dissenting AD has those same two weeks to convince others on the IESG that his or her position is reasonable or at least needs more extensive consideration. If that is possible, then there is no longer a single AD objecting and the two week rule does not apply. If it is not possible, then there is either something wrong with the objection or the AD making it and probably it is reasonable for the process to move forward. I don't think I agree. I do agree that a single AD shouldn't be able to indefinitely delay a WG's output, and that you want IESG to be able resolve such issues internally in the vast majority of cases (because appeals to IAB are very time- and resource-consuming). But I don't think two weeks is long enough in general to get other ADs to thoroughly review a document. Two months would be much better. Now it might be the case that IESG members will help each other out, and collaborate to log multiple DISCUSS votes to give everybody more time to review a document. People of good will acting in good faith can usually find ways to work around buggy processes to make the right thing happen, at least in the most important cases. But it's not ideal, and it relies on ADs getting along with each other - which creates incentives for ADs to not do an adequate job of reviewing some documents, so that they'll be able to call in favors from other ADs when they need them. So overall I think the balloting process that IESG currently follows is seriously flawed. Conversely, a WG that decides to avoid actually engaging on an issue in the hope of letting the two-week clock run out is putting itself at considerable risk. The IESG still have the ability to fire WG leadership and even to close WGs. In theory, yes. But that hardly seems like a good tool for resolving issues in a single document, especially when the WG has other ongoing work that might turn out to be useful.Also, at least when I was on IESG all of us seemed to be aware that though we did have the authority and responsibility to push back on poor work, we also had to be mindful of the potential for the community to mutiny. Under any reasonable circumstances, I assume that the IESG would respond very strongly if an AD pointed out the a WG had ignored an effort to discuss a substantive issue even if the rest of the IESG disagreed with that particular AD about that issue. I'd hope so. But I also think that the process should work even for an objection raised by an AD who was unpopular with the rest of IESG. Of course I hope that ADs get along well with one another and work together to make a better Internet. But I also know from experience that some ADs tend to have more clout than others, and that the ones with the most clout aren't always the ones with the best technical judgment. Keith
Re: Gather Profiles/Resumes [was Re: call for ideas: tail-heavy IETF process]
On 05/15/2013 12:25 PM, Thomas Narten wrote: I don't think the IETF needs to be in the profile/resume business. There are plenty of other places that do a fine job already. What I do think the IETF should do is *require* that participants identify themselves. That means knowing who they are (a name and email contact) and an affiliation. I have mixed feelings about this. On one hand I would like to know who (if anyone) is paying someone to do IETF work, because there's always some potential for inappropriate bias even among people with a high degree of integrity - and of course not everyone has such integrity. On the other hand I don't think that a contributor's affiliation should mean anything at all when evaluating that contributor's input to IETF. If people treat contributors from major companies as having more weight than other contributors, it makes a joke out of the whole notion of consensus-based decision making. (And we all know that people do this sometimes.) I also don't think that anyone should automatically presume that a contributor's input is representing his employer's interests. On balance, I do sometimes find it helpful when IETF contributors disclose their employers. But I don't think it should be required. And if everybody stopped disclosing their employers in the context of IETF conversations, it might be a good thing. Keith
Re: Is this an elephant? [Was: call for ideas: tail-heavy IETF process]
On 05/16/2013 04:46 PM, Yoav Nir wrote: The time for asking whether the group has considered making this field fixed length instead of variable, or whether RFC 2119 language is used in an appropriate way, or whether the protocol is extensible enough is at IETF last call. Actually the time for asking these questions is long before IETF-wide Last Call. We need widespread review of proposals for standards-track documents long before a WG thinks it's finished with those documents. It's a gaping hole in our process. Fix that problem, and most of the conflicts between IESG and WGs that surround DISCUSS votes will go away. Keith
Re: Is this an elephant? [Was: call for ideas: tail-heavy IETF process]
On 05/16/2013 06:09 PM, joel jaeggli wrote: Fix that problem, and most of the conflicts between IESG and WGs that surround DISCUSS votes will go away. Maybe but I wouldn't take that as an article of faith. You're going to get pressure for more changes when fresh eyes review something. Yeah, every new set of eyes that looks at a document is going to have some new ideas for what the document should be. The trick is to get those eyes to look at the document earlier in the process, when it's easier to fix problems. Maybe if we did the early review well enough, the scope of Last Call comments could be limited in some way. Keith
Re: article on innovation and open standards
On 05/15/2013 02:00 AM, Mikael Abrahamsson wrote: Otoh hand the whole point with IETF is that *nobody* is *excluded*, it consists of all interested parties and the barrier of entry is really low. That's what many of us would like to believe. But IETF certainly doesn't consist of all interested parties, and the barrier to effective participation (regularly showing up at meetings all over the world and spending significant time participating in mailing lists) can be prohibitively high. Yes, I'm aware that some people (including myself) have effectively participated on occasion without doing either of the above. But I think it's hard to effectively participate in IETF on a regular basis without a significant investment in both time and money. Keith
Re: article on innovation and open standards
On 05/15/2013 02:42 AM, Mikael Abrahamsson wrote: On Wed, 15 May 2013, Keith Moore wrote: Yes, I'm aware that some people (including myself) have effectively participated on occasion without doing either of the above. But I think it's hard to effectively participate in IETF on a regular basis without a significant investment in both time and money. Personally I've only been on a single physical IETF meeting. I participate mainly via mailing lists. And yes, it's hard to participate without spending (significant) time. I don't know how else this could be done though. It's at least my opinion that if time is made available, the barrier of entry is probably the lowest of any similar organisation I can think of. I'd like to see WGs be more pro-active about periodically summarizing the salient points of their proposals, determining which parties outside of the WG are likely to be affected, explicitly soliciting input from those parties, and explicitly considering that input in their deliberations. Some WGs do this, but for most WGs I don't think it happens often enough or formally/transparently enough. Last Call shouldn't be the first time that we explicitly solicit feedback on proposals from interested parties outside the WG. As far as I can tell, the primary reason that WGs are so resistant to IESG feedback is that too often the WGs have labored long and hard with little or no feedback from external sources, and they've reached consensus mostly by exhaustion. By the time a document gets to IESG review and community-wide Last Call, the WG is usually too exhausted and/or too committed to that particular solution to fix any major flaws. At this point there are often no good solutions - simple text changes and IESG notes are usually inadequate, and publishing the document in its current form may do more harm than good. But if WGs got feedback from outside parties much earlier in the process, there's a much better chance that such problems could be fixed before the WG were exhausted and committed. Of course anyone can send input to a WG's mailing list at any time. But someone who doesn't regularly follow the mailing list can have a difficult time understanding the state of things and knowing how and when to provide useful input. Keith
Re: article on innovation and open standards
On 05/15/2013 10:00 AM, Mikael Abrahamsson wrote: On Wed, 15 May 2013, Keith Moore wrote: I'd like to see WGs be more pro-active about periodically summarizing the salient points of their proposals, determining which parties outside of the WG are likely to be affected, explicitly soliciting input from those parties, and explicitly considering that input in their deliberations. Some WGs do this, but for most WGs I don't think it happens often enough or formally/transparently enough. I agree. I'm also participating on nanog-l and other operator lists, and it's very rarely that a WG solicits feedback in those kinds of forums. Question is, if larger feedback is requested, a lot of the time a larger feedback will be generated, and more work needed to go through this feedback and answer it. End result might be better, but overall workload would be up, both in preparation phase and when feedback is coming in. I'm sure end result would probably be better, but more work would be needed, probably resulting in less technical work being done. We need to be careful about the tendency to measure IETF's output in terms of the number of RFCs produced. I'd like to see IETF produce fewer (and sometimes shorter) RFCs of more relevance and higher technical quality, than we do now. Keith
Re: call for ideas: tail-heavy IETF process
On 05/15/2013 10:39 AM, Joe Touch wrote: On 5/14/2013 9:54 PM, Keith Moore wrote: Publishing broken or unclear documents is not progress. Keith Broken, agreed. Unclear, nope - please review the NON-DISCUSS criteria, notably: The motivation for a particular feature of a protocol is not clear enough. At the IESG review stage, protocols should not be blocked because they provide capabilities beyond what seems necessary to acquit their responsibilities. The DISCUSS isn't there to make documents better - that's for COMMENTs. A DISCUSS there to catch a set of problems and to *block* the document's progress until that problem is resolved. I strongly disagree with what the NON-DISCUSS criteria say. DISCUSS isn't just for blocking documents. And document quality is as important (in the sense that poor document quality can lead to as many interoperability or other problems) as technical correctness. Why are people trying to sabotage IESG? Keith
Re: call for ideas: tail-heavy IETF process
IMO, IESG should have grounds to reject any document that isn't specifically authorized in a WG's charter. - Keith On May 15, 2013, at 10:55 AM, Ted Lemon ted.le...@nominum.com wrote: On May 15, 2013, at 10:41 AM, Keith Moore mo...@network-heretics.com wrote: The motivation for a particular feature of a protocol is not clear enough. At the IESG review stage, protocols should not be blocked because they provide capabilities beyond what seems necessary to acquit their responsibilities. I strongly disagree with what the NON-DISCUSS criteria say. DISCUSS isn't just for blocking documents. And document quality is as important (in the sense that poor document quality can lead to as many interoperability or other problems) as technical correctness. The interpretation of this particular NON-DISCUSS criterion that Joe has given is simply wrong. The key word to pay attention to to see the error is motivation. The point of this criterion is to eliminate a very specific sort of stall that has been known to happen in the past: the stall where the AD doesn't understand why the document is being put forward at all, and therefore blocks the document until the authors explain the motivation behind the document to the satisfaction of the AD who is holding the DISCUSS. This is a real issue that has created real problems in the past, and that is why it is in the NON-DISCUSS criteria. But this criterion _does not_ mean that a criticism that the document itself is unclear is not a valid reason to hold a DISCUSS on it. In fact, it's an excellent reason to hold a DISCUSS on it. A lack of clarity in a document can result in it being implemented incorrectly, or in the case of a BCP, interpreted incorrectly. Or in extreme cases, not read at all. This is a bad outcome, worth spending time on, even if the authors would rather be quit of it.
Re: call for ideas: tail-heavy IETF process
On 05/15/2013 02:48 PM, Joe Touch wrote: On 5/15/2013 11:08 AM, Ted Lemon wrote: I don't think this is a topic that the IETF as a whole is likely to find very interesting. However, if anyone is curious, they are welcome to read the DISCUSS here and see if they agree with your characterization of my question: http://datatracker.ietf.org/doc/draft-ietf-tcpm-experimental-options/ballot/ For those who may be interested, the last sentence of the first paragraph is the motivation for this being a DISCUSS position (as opposed to a comment). Which is I think that using a 4-byte ExID runs a real risk of overflowing the available space in the TCP header in real-world circumstances. Except that the document already describes the ExID as either 16-bit or 32-bit: All ExIDs MUST be either 16-bits or 32-bits long. Motivation for the additional two bytes is already explained in the document in several places, notably: The second two bytes serve as a magic number. ... Using the additional magic number bytes helps the option contents have the same byte alignment in the TCP header as they would have if (or when) a conventional (non-experiment) TCP option codepoint is assigned. Use of the same alignment reduces the potential for implementation errors, especially in using the same word-alignment padding, if the same software is later modified to use a conventional codepoint. Use of the longer, 32-bit ExID further decreases the probability of such a false positive compared to those using shorter, 16-bit ExIDs. ... Use of the longer, 32-bit ExID consumes more space, but provides more protection against false positives. Which is why I feel this motivation isn't sufficient for a DISCUSS. It certainly seems like a valid topic for an AD to want to discuss with a WG.And that's all that DISCUSS inherently means. Keith
Re: call for ideas: tail-heavy IETF process
On 05/15/2013 11:33 AM, Yoav Nir wrote: On May 15, 2013, at 6:06 PM, Keith Moore mo...@network-heretics.com wrote: IMO, IESG should have grounds to reject any document that isn't specifically authorized in a WG's charter. - Keith Why? There's definitely a process failure there, and it should be blamed on the WG chairs and/or the AD, who should have either moved the work out of the working group or worked on updating the charter. ADs shouldn't have to micro-manage the WGs and keep track of whether every single document that a WG is working on is authorized by its charter. Fundamentally, it's the WG chair's job to stay within the charter. What I was addressing with my above statement is that there seems to be a presumption on the part of some people that a WG can produce anything it wants, and that the IESG is under an obligation to approve such work unless it can object on some very specific grounds.I can understand something resembling such a presumption for work that the WG is specifically chartered to do. We don't want WGs investing their members' time and energy to produce something that will never see the light of day, and WG members need some assurance that their efforts are likely to bear fruit at least as far as publication is concerned. But I see no reason that a WG should be able to presume that the IESG should ultimately accept something that they weren't specifically chartered to do in the first place. Though probably a better remedy than to reject the document outright, would be for IESG to treat such documents as individual submissions. Keith
Re: call for ideas: tail-heavy IETF process
On 05/15/2013 09:07 PM, Pete Resnick wrote: I initially replied to address Keith's comment. But a few things on Joe's: On 5/15/13 7:41 AM, Keith Moore wrote: On 05/15/2013 10:39 AM, Joe Touch wrote: On 5/14/2013 9:54 PM, Keith Moore wrote: Publishing broken or unclear documents is not progress. Broken, agreed. Unclear, nope - please review the NON-DISCUSS criteria, notably: The motivation for a particular feature of a protocol is not clear enough. At the IESG review stage, protocols should not be blocked because they provide capabilities beyond what seems necessary to acquit their responsibilities. The DISCUSS isn't there to make documents better - that's for COMMENTs. Exactly right. Sometimes we forget; it's a good thing to remind us. A DISCUSS there to catch a set of problems and to *block* the document's progress until that problem is resolved. Mostly correct. However: - If there is only one AD who wishes to DISCUSS and no other AD agrees with the DISCUSS holder, at the next telechat the document is unblocked. (See http://www.ietf.org/iesg/voting-procedures.html.) - Even if others agree with the DISCUSS, the chair can be asked to use the alternate procedure, which requires 2/3 of non-recused ADs to agree to publication. Which is to say, if there is only a single AD blocking a document, that block is essentially a 2 week affair if you are willing to push the point. No need for negotiating; if the WG decides that the AD is totally off base, tell your sponsoring AD that you're waiting the two weeks. People (unfortunately IMO) don't push the point nearly enough. I think it's very unfortunate that IESG has adopted rules that work this way. Part of IESG's job is to provide independent review of WG output. It that review can be circumvented merely by waiting two weeks, that's a bug in the process. And if an AD raises a DISCUSS about a matter of technical or document quality (or for that matter, about a process violation), and the WG isn't even willing to discuss the point, but instead relies on the two week timeout, I think that's grounds for appeal to the IAB. (For the record, the IESG has *never* used the latter of the two procedures.) That said, I am also of the view that there is a third way, but I have never seen a WG attempt it: DISCUSS should in fact require discussing. We agree on that much. Assuming there was some good faith effort on the part of the WG to figure out what the AD was on about and they really assess that the AD has it wrong, a WG could say, Sorry, we got this right. You are confused (or wrong). We are not changing the document. We are done discussing. At that point, I am of the opinion that the AD cannot hold the DISCUSS any longer. The AD must move to ABSTAIN. I disagree with this in the strongest possible terms. I believe that for IESG to have rules that insist on or encourage voting ABSTAIN when the AD really means this document is not acceptable, is both irresponsible and dishonest on the IESG's part. I also believe that it tends to mean that ADs who didn't actually review the document get more say than ADs who did. The proper thing to do in that case is for either side to appeal to the IAB. The discussion is, for all intents and purposes, over and to continue to DISCUSS is (IMO) an appealable offense. Then it is a matter of the IESG deciding whether there are enough ADs supporting the document (YES or NO OBJECTION) to count as consensus of the IESG. We ostensibly use 2/3 of non-recused ADs to mean consensus, since (I think the theory goes) if you can't get 2/3 of ADs to agree that it's OK to publish a document, that is a sign of a lack of rough consensus in the IETF (and probably a serious problem in WG operation). Indeed, if the ADs are so off of their rockers that more than 1/3 of them are against a perfectly reasonable document, it's time for the appeals and recall procedures to be used. I don't think IESG voting should be thought of as a consensus process, except perhaps in the deadlock breaking procedure. The typical number of reviewers on the IESG is too small for a consensus process to be meaningful. With so few thorough reviewers outside of the WG, you need a procedure that at least initially assumes that all review comments have to be taken seriously. Now, as to Keith's comments: I strongly disagree with what the NON-DISCUSS criteria say. DISCUSS isn't just for blocking documents. And document quality is as important (in the sense that poor document quality can lead to as many interoperability or other problems) as technical correctness. Why are people trying to sabotage IESG? I'm sorry Keith, but your last line is rubbish. To claim that what people in this thread are talking about amounts to an attempt to sabotage the IESG is the height of hubris. sabotage is probably not the best word I could have chosen. But I do have the strong impression
Re: call for ideas: tail-heavy IETF process
On 05/14/2013 06:30 PM, Dave Crocker wrote: On 5/14/2013 3:12 PM, Ted Lemon wrote: On May 14, 2013, at 6:00 PM, Joel M. Halpern j...@joelhalpern.com wrote: At the same time, discussions do have to be resolvable. If there is no way to address it, then it is not a discuss. But required to clar is the wrong picture as far as I can tell. Exactly right. It would actually be pretty presumptuous for an AD to say what is required to clear the DISCUSS. That would tend to imply that the DISCUSS is a directive, not an invitation to, well, discuss. It isn't an 'invitation'. It's an exercise in political authority by blocking progress of the document. It's a mistake to inherently define progress in terms of advancing the document. Many documents should not be published in the form in which they first reach IESG; a few documents that reach IESG should probably never be published. We came up with the term Discuss when I was an AD because, at the time, the IESG had little authority and wanted to encourage a constructive tone; we didn't want to sound like we were saying 'no'. And of course, that's still everyone's preference. But the reality is that the imposition of the Discuss is an assertion that changes are being required. That's neither what Discuss means, or what it should mean. Though I've seen many cases where WGs or authors demanded that ADs tell them what to fix. It's understandable that they should want clarity from the AD, and yet fixing the document is not the AD's job. For reference, that milder uses of Discuss, which is something akin to I'd like something clarified does not require a Discuss. It requires a query to the working group and some dialogue. Disagree. I've seen a number of cases where informal conversations caused more problems and delay than voting DISCUSS. By the time a document has reached final IESG review, it's generally much better to have the level of formality and transparency that comes with voting DISCUSS. Of course we have to _try_ to say what we think would clear the discuss, but I don't think we can go beyond that; it's virtually impossible for us to have complete information. That makes no sense. The AD is the one choosing to block progress. It will be the AD who decides to clear the discuss. I disagree in the strongest possible terms. If an AD believes that there is something wrong with a document, even something that needs clarification, the proper thing for the AD is to vote DISCUSS. This is NOT choosing to block progress. Publishing broken or unclear documents is not progress. Keith
Re: call for ideas: tail-heavy IETF process
On 05/14/2013 04:45 PM, Joe Touch wrote: Brian, et al., On 5/14/2013 1:10 PM, Brian E Carpenter wrote: I think this exchange between Cullen and Ted says it all, except for one tweak: the IESG is allowed, even encouraged, to apply common sense when considering the DISCUSS criteria. They are guidance, not rules. Also, everybody needs to take the word discuss literally. An entirely possible outcome is that after discussion, the AD says Oh. You're correct. Pretend I never spoke!. Or the author says Oh. You're correct. We'll change it. Either outcome is good. The trouble with this assumption is the IESG review process. COMMENTS are appropriate for feedback, but the IESG review process is too often considered an *opportunity* for the IESG to make the document better, or (in some case) have an opportunity for their input. For that matter, working groups are too often echo chambers where a set of people manage to isolate themselves from input from those whose work they might otherwise effect.Some people seem to think that working group output should be sacrosanct. There's absolutely no reason to believe that. WGs often make technical mistakes that are uncovered by external review. Even when no such mistakes are encountered, WG output rarely represents rough consensus of all interested parties, and WGs often fail to do due diligence in considering the interests of the broad spectrum of those potentially affected by their work. Of course IESG isn't infallible either, and shouldn't behave as if it is. But review by experts from outside of the WG generally seems to improve the IETF's output. As important as the DISCUSS criteria are, there are NON-DISCUSS criteria that ought to be more carefully followed - including the point that disagreements with the WG or clarifications are not justification for DISCUSS. Strongly disagree. First, DISCUSS only means that there's something the AD wants to discuss.In particular, disagreements with the WG about technical quality are always appropriate for IESG to raise. The same is true of requests for clarification. Ted pointed out that DISCUSS doesn't mean the IESG doesn't like a document - agreed, but it *does* hold up a document until the IESG member clears it. But there are also procedures within IESG to ignore a single DISCUSS vote. So ultimately it takes multiple DISCUSS votes to hold up a document indefinitely. DISCUSS is a heavyweight mechanism that holds up document resolution; it should be used only where absolutely appropriate. If the IESG wants to have a discussion with the authors, they are welcome to participate in the WGs or IETF LC, or to contact them out of band. DISCUSS is not supposed to be a heavyweight mechanism, and actually it's hard to imagine a lighter weight mechanism that gives IESG review any weight. Informal communication doesn't generally work well in practice because it lacks transparency, and it can cause additional delay without resolving the problem. Voting DISCUSS puts pressure on BOTH the AD and the WG to resolve the issue. Keith
Re: Sufficient email authentication requirements for IPv6
On 04/09/2013 08:07 PM, John Levine wrote: Quoting Nathaniel Borenstein [1]: One man's blacklist is another's denial-of-service attack. Email reputation services have a bad reputation. They have a good enough reputation that every non-trivial mail system in the world uses them. They're not all the same, and a Darwinian process has caused the best run ones to be the most widely used. There seems to be a faction that feel that 15 years ago someone once blacklisted them and caused them some inconvenience, therefore all DNSBLs suck forever. I could say similar things about buggy PC implementations of TCP/IP, but I think a few things have changed since then, in both cases. There's an inherent problem with letting 3rd parties affect email traffic, especially when there's no way to hold those 3rd parties accountable for negligence or malice. Keith
Re: Sufficient email authentication requirements for IPv6
On 04/10/2013 06:55 PM, John Levine wrote: There seems to be a faction that feel that 15 years ago someone once blacklisted them and caused them some inconvenience, therefore all DNSBLs suck forever. I could say similar things about buggy PC implementations of TCP/IP, but I think a few things have changed since then, in both cases. There's an inherent problem with letting 3rd parties affect email traffic, especially when there's no way to hold those 3rd parties accountable for negligence or malice. Like I said, things have changed since 1996. Indeed they have. Email is much less reliable now than it was then. Keith
Re: Sufficient email authentication requirements for IPv6
On 04/10/2013 07:14 PM, John R Levine wrote: Like I said, things have changed since 1996. Indeed they have. Email is much less reliable now than it was then. Agreed. But it's not the DNSBLs, it's all the other stuff, notably heuristic content filters, that we have to do to deal with the 95% of mail that is spam these days. In a sense, it's the same problem. Bad heuristics are being used to filter content, generally without the affected users getting any notification or having any recourse. Whether a DNS-based oracle is involved, or whether the heuristics are being applied to source IP or DNS name, are largely irrelevant. Certainly using DNS doesn't make the use of bad heuristics any better. Keith
Re: Sufficient email authentication requirements for IPv6
On 03/29/2013 01:28 PM, Douglas Otis wrote: The Internet is under a DDoS attack specifically against an email address reputation service. You have it backwards. Internet email has long been under DDoS attack from email address reputation services. Keith
Re: On the tradition of I-D Acknowledgements sections
On 03/25/2013 02:05 AM, Melinda Shore wrote: My experience over lo, these many years is that the best way to ensure that you're recognized is to produce text/suggestions/ideas that other people find valuable. +1
Re: Less Corporate Diversity
On 03/23/2013 02:27 AM, Bob Hinden wrote: To raise this discussion up a bit, I can think two other related reasons why there may be less corporate diversity in the IETF. The first is that it's possible to build applications and businesses that take advantage of the Internet without having to come to the IETF to standardize anything. The work of the IETF (and related organizations like W3C, IEEE, etc.) have made this possible. A success problem so to speak. The second is that it's very hard to make changes at the IP and transport layers and have them be deployed in scale given middle boxes. Many organizations have stopped trying and focus on making things work on top of http. This also doesn't require coming to the IETF. Perhaps not, but the extensive proliferation of middle boxes is arguably due to various failures within IETF, such as the failure to promote end-to-end security or the failure to extend the Internet architecture to accommodate legitimate needs of networks. Keith
Re: Architecture
On 03/22/2013 09:50 AM, John Curran wrote: On Mar 21, 2013, at 8:58 AM, Keith Moore mo...@network-heretics.com wrote: ... Another result is that the Internet architecture has gone to hell, and we're now spending a huge amount of effort building kludges to fix the problems associated with other kludges and the new kludges will almost certainly create more problems resulting in a need for more kludges later. Keith - While I won't argue with the symptoms you describe, I'm not sure I'd attribute it to lack of diversity. Both wildly diverse and relatively homogeneous communities can still bifurcate on multiple approaches to solving any given problem, and if that happens repeatedly and at multiple layers, then we inevitably end up with a bit of a mess... What you are seeing is more likely the result of applying relatively few architectural principles in weeding out possible solutions, i.e. more of the let a thousand protocols bloom and the market will decide approach generally taken when establishing working groups and deliverables. I don't think we're in disagreement. I think that more diversity in IETF would help minimize the risk that some interests were shortchanged, but I certainly agree that another factor is a lack of understanding of, and respect for, the effect of certain changes on the Internet architecture. Have we even tried to identify and advertise those architectural principles since the early days? Keith
Re: Architecture
On 03/22/2013 03:03 PM, John Curran wrote: On Mar 22, 2013, at 2:49 PM, Keith Moore mo...@network-heretics.com wrote: I don't think we're in disagreement. I think that more diversity in IETF would help minimize the risk that some interests were shortchanged, but I certainly agree that another factor is a lack of understanding of, and respect for, the effect of certain changes on the Internet architecture. Interesting... that could be the case. Have we even tried to identify and advertise those architectural principles since the early days? It may no longer be achievable, as pressure from vendors for new features and functionality drives new protocols and protocol additions, and while saying no sounds good in theory, the reality is that it probably doesn't really prevent the efforts, as much as cause them to be done as via private vendor=specific efforts... What's necessary, I think, is to respond to pressure for new features and functionality differently. Rather than saying yes or no, say we have noticed that the existing architecture fails to meet needs X, Y, and Z; and we propose to change the architecture in such a way to accommodate those needs while still safeguarding other important features or interests Keith
Re: Less Corporate Diversity
On 03/20/2013 07:20 PM, Martin Rex wrote: The more diverse the culture, the higher the probability for miscommunication (misunderstanding and taking offense). True, but without the diversity, the solutions provided by IETF are less likely to serve the interests of the extremely diverse Internet community.(And that's what we're here for.) The more more diverse the (interests) of the affiliations of IETF participants and IETF leadership, the hotter the dicussions typically burn on contentious issues (ratholing). Perhaps, but what we commonly do in IETF now is artificially narrow the scope of discussions to generate the appearance of consensus without the reality. One result is that our protocols fail to meet the needs of a great many users. Another result is that the Internet architecture has gone to hell, and we're now spending a huge amount of effort building kludges to fix the problems associated with other kludges and the new kludges will almost certainly create more problems resulting in a need for more kludges later. (if you need an example, you need look no further than PCP and LSN) Keith
Re: Less Corporate Diversity
On 03/20/2013 08:51 PM, Martin Rex wrote: IMHO, the IESG is not (and maybe never was?) a committee where_each_ member reviews_all_ of the work, where_each_ forms his very own opionion, and where all of them caste a VOTE at the end, so that the diversity within that committee would be vitally beneficial (to anything). IESG is the review body of last resort. When WGs do a poor job of review, especially cross-area review, the burden falls on IESG to take up the slack. The idea that IESG shouldn't actually do review is naive in the extreme, given the brokenness of IETF's structure. Keith
Re: Diversity of IETF Leadership
On 03/20/2013 08:13 AM, Martin Rex wrote: The monetary and time resources necessary to fill an I* position adequately appear quite significant to me, and I believe it would be hard to fill them without strong support from an employer which covers the monetary investment. Agreed. But this is a huge problem for IETF. Far too often, our standards aren't serving the Internet community so much as serving the interests of a few large companies. I'd actually guess that this is IETF's biggest problem. Keith
Re: Diversity of IETF Leadership
On 03/20/2013 11:41 AM, Mary Barnes wrote: Given that folks are still debating whether this years nominees reflected a reasonable diversity (there were 9 women out of 37 nominees), I actually don't think that the number of female nominees is relevant.What is relevant is the number of qualified female nominees who had the willingness, the availability, the required expertise, and the support necessary to fill the position. On several occasions in the past decade I've been asked if I were willing to be nominated to serve on IESG again, even though I didn't have either sufficient time or support to devote to the task, just so that nomcom would have a slate of candidates to compare. I thought on those occasions, and still think, that it's a bit silly to ask nomcom to investigate candidates who don't have the time or support to do the job. But I still agreed to be nominated because I could also see some value in having nomcom compare several candidates. (Just like when shopping for a new car, it doesn't hurt to look at models that you know that you're probably not going to buy, just to get a sense of whether you really want what you think you want). So I guess I've formed the impression that merely being nominated for a position doesn't really mean that a person is available. Keith
Re: Diversity of IETF Leadership
On 03/20/2013 12:21 PM, Mary Barnes wrote: On Wed, Mar 20, 2013 at 11:10 AM, Keith Moore mo...@network-heretics.com wrote: On 03/20/2013 11:41 AM, Mary Barnes wrote: Given that folks are still debating whether this years nominees reflected a reasonable diversity (there were 9 women out of 37 nominees), I actually don't think that the number of female nominees is relevant. What is relevant is the number of qualified female nominees who had the willingness, the availability, the required expertise, and the support necessary to fill the position. [MB] Sure. But, I know of at least two that I don't think or would hope anyone would debate were qualified in all the areas you suggest. Both have contributed significantly to IETF in a variety of leadership positions. Sure, but that doesn't mean that they have sufficient time or employer support to do the job now. And there's no way that someone like you or me can reliably know whether that's the case. That has to be something that's kept confidential between the nominee and the nomcom. One concept that is not very well understood, however, is the basic fact that women work differently than men and thus expecting us to fit the cookie cutter of IETF leaders isn't quite appropriate. To be clear: I wasn't arguing about that aspect at all, just about whether it's reasonable to look at a slate of nominees and compare that to the slate of people selected and make inferences about the role of gender in the nomcom's decision process. I'm also not presuming that just because there were no women in the latest set of appointees to IESG, that it's because the current nomcom didn't think that women could fit the cookie cutter. I don't have and don't pretend to have the ability to read their minds. In general I think that presumptions that require the ability to read specific people's minds should be dismissed out-of-hand as irrelevant and perhaps insulting. People can imagine or project what they like, but what people imagine or project should never be confused with reality. To be told by a nomcom voting member, when I mention this fact, that this just isn't so because IETF is a meritocracy is insulting and shows a sheer lack of respect for the value that diversity brings to an organization. Respectfully disagree. We expect the nomcom to balance lots of different considerations when choosing IESG and other appointees, AND we expect them to keep their deliberations confidential. Gender is definitely a valid consideration, but it's only one consideration, and at least a dozen others have been mentioned. To look at the nomcom result through the aperture of only one or two of those considerations, and then make a statement about the nature of their imagined gender bias strikes me as pure speculation. I certainly hope that the nomcom doesn't believe that women can't do the jobs. Our community has ample evidence and decades of experience that they can. I served with several women when I was on IESG and found all of them to be capable and professional in every respect. Note also that the process for selecting the nomcom is inherently gender-neutral, at least to the extent that the requirement for nomcom attendance at prior IETF meetings doesn't impose a gender barrier. [MB] You have to keep in mind in the past that the there were dummies in the nominee pool before open list. I was explicitly told by this year's nomcom chair that they were not doing that. Thus, I would anticipate that the majority of those in the pool this year were willing and able.[/MB] That helps a bit, but I still don't think it supports an assertion of gender bias in the nomcom's process. Keith
Re: Diversity of IETF Leadership
On 03/11/2013 03:33 PM, Arturo Servin wrote: ISOC is doing a great job with the fellowship program. There is just a few people each meeting but it is a good start. I'm glad they are doing it but it is a drop in the bucket. Our processes are considerably biased against anyone who is not funded by a large company, and is not independently wealthy. It's not just people on certain continents who are under-represented, it's the vast majority of the Internet developer and user community.
Re: Diversity of IETF Leadership
On 03/11/2013 01:43 PM, Arturo Servin wrote: My opinion is that we agree we have a situation that we should improve, but also we shouldn't focus on the nomcom process, the problem is not about how we select people (it may help but it is not the root problem). The problem is to bring new people (younger people, women, from more countries, different languages, etc.) to write RFCs, to participate/be interested in the IETF and how we involve/prepare these people to become our leaders and not just participants. If we do that, then we will have more diversity in our leadership. Agree. And I suspect that a large part of the answer is make effective participation in IETF substantially less expensive than it is now (I didn't say it was an easy problem to solve.) Keith
Re: Diversity of IETF Leadership
One aspect of IETF leadership diversity that seems to have considerably decreased over the years that I've been working with IETF is the number of people from academic/research relative to the number of people from the commercial sector. I believe that this has been extremely harmful to IETF. Keith
Re: Internet Draft Final Submission Cut-Off Today
On 02/27/2013 01:49 PM, Carsten Bormann wrote: On Feb 27, 2013, at 19:18, ned+i...@mauve.mrochek.com wrote: routing around obstacles It turns out for most people the easiest route around is submitting in time. That is actually what counts here: how does the rule influence the behavior of people. Chair hat: WORKSFORME. (And, if I could decide it, WONTFIX.) +1. As far as I can tell, the deadline actually serves the purpose of getting people to focus on IETF and update their documents sufficiently prior to the meeting, that it's reasonable to expect meeting participants to read the drafts that they intend to discuss. And I say this as someone who, as an author, has often found the deadline to be very inconvenient. Keith
Re: presenting vs discussion in WG meetings (was re:Remote Participation Services)
On 02/16/2013 03:04 AM, Brian E Carpenter wrote: On 15/02/2013 20:57, Keith Moore wrote: ... But this makes me realize that there's a related issue. An expectation that WG meetings are for presentations, leads to an expectation that there's lots of opportunity to present suggestions for new work to do. WG time scheduled for considering new work can actually take away time for discussion of ongoing work. And once the time is scheduled and people have made commitments to travel to meetings for the purpose of presenting new work, chairs are understandably reluctant to deny them their allotted presentation time. This is closely related to a well-known problem at academic conferences. Many people can only get funded to travel if they are presenting a paper. It's common practice, therefore, to have either a poster session (which allows massively parallel presentations) or hot-topics sessions (with a strict and very short time-limit). We tend to throw the hot-topics sessions into WG meetings, which is not ideal. Why not have a poster session as part of Bits-n-Bites? It would give new ideas a chance to be seen without wasting WG time. Make it official enough that people can use it in their travel requests. That sounds like a great idea to me. Keith
Re: presenting vs discussion in WG meetings (was re:Remote Participation Services)
On 02/15/2013 12:46 PM, George, Wes wrote: [WEG] Perhaps it would be helpful to make an informal recommendation to WG chairs (via the wiki, for example) that generally they should carve each request for agenda time roughly in half, with a hard limit of $speaker_time/2 devoted to presenting or otherwise framing the discussion and the remaining time devoted to open mic discussion. Likely this will result in presenters asking for 2x their previous time, but at least it will be a more realistic method to plan out time during a meeting and reduce the instances where the WG will be running short of time for meaningful discussion if the presenter (or WG chair) isn't good at managing the available time and spends the whole allocation reading slides to the people in attendance. I actually don't think a hard limit is a good idea. WGs need more presentation time in their early phases. But this makes me realize that there's a related issue. An expectation that WG meetings are for presentations, leads to an expectation that there's lots of opportunity to present suggestions for new work to do. WG time scheduled for considering new work can actually take away time for discussion of ongoing work. And once the time is scheduled and people have made commitments to travel to meetings for the purpose of presenting new work, chairs are understandably reluctant to deny them their allotted presentation time. (It seems like every time I attend an IETF there are numerous WG meetings with schedules full of presentations for new work that are hardly even listened to, and that those presentations crowd out discussion of ongoing work. When the alloted time for such discussion has elapsed, the chair will sigh and say ok, let's take that to the mailing list.) I suggest that ongoing work should nearly always take precedence over consideration of new work, particularly for new work that's not fairly close to the current scope of the WG's charter. It follows that chairs probably shouldn't schedule all of their allotted meeting time by filling otherwise unused time with presentations of proposals for new work. The amount of time required for discussion is difficult to predict, and often runs over that anticipated. A better strategy might be this: List the major issues that need to be sorted out in face-to-face discussion, probably in order of importance (how much is this particular issue blocking WG progress on its chartered goals?) combined with some sense of how likely the group is to make progress. Allot maybe 5 minutes for each topic for presentation time (introduction of the discussion), to be followed by the actual discussion. Each discussion gets cut off after some pre-determined amount of time, or when the chair determines that it's unlikely to produce any useful progress. If there's time left over after everything has been discussed, and the WG is close to finishing its chartered goals, the chair can invite speakers to briefly present proposals for new work. But in general a WG shouldn't preallocate time for such presentations in WG meetings - they should rather be discussed in separate BOF sessions. Keith
Re: Remote Participation Services
On 02/05/2013 11:04 AM, IETF Chair wrote: 3.4. Slide Sharing Slides are often sent by email in advance of the meeting. WebEx allows the slides and desktop applications to be viewed by the remote participants. These are controlled by the presenter. The presenter can be shifted from participant to participant as needed. Can we *please* discourage the habit of treating IETF WG meetings as one series of PowerPoint presentations after another? This makes the meetings much less productive. The notion that there are supposed to be slides for each presentation, is IMO, a huge error. Keith
Re: Remote Participation Services
On 02/11/2013 10:23 PM, joel jaeggli wrote: On 2/11/13 5:17 PM, Keith Moore wrote: On 02/05/2013 11:04 AM, IETF Chair wrote: 3.4. Slide Sharing Slides are often sent by email in advance of the meeting. WebEx allows the slides and desktop applications to be viewed by the remote participants. These are controlled by the presenter. The presenter can be shifted from participant to participant as needed. Can we *please* discourage the habit of treating IETF WG meetings as one series of PowerPoint presentations after another? This makes the meetings much less productive. The notion that there are supposed to be slides for each presentation, is IMO, a huge error. If you have prepared materials for your segment of the agenda they should be available beforehand, full stop. Agree. But perhaps slides are not, in general, the best kind of preparation?Perhaps some brief notes consisting of a summary of the discussion topic and the major points to be made (perhaps from multiple points of view), with pointers to I-Ds or other relevant background documents, would be more appropriate? Perhaps instead of talking about presentations, this document should talk about discussions? And perhaps instead of Slide Sharing the section should read something like: 3.4. Sharing of Briefing Material Each speaker is strongly encouraged to prepare material to brief meeting participants about the topic to be discussed during his or her meeting segment. Such a briefing should generally be less than two pages in length, and contain a summary of the topic to be discussed. If there are multiple points-of-view that need to be reconciled, the briefing should attempt to capture these. When appropriate, the briefing should also include URLs of background material, such as RFCs or Internet-Drafts, that discussion participants should be familiar with. Both local and remote meeting participants are strongly encouraged to download and read such material prior to the meeting. Such materials should be in a format that everyone can read, e.g. HTML, or PDF. If slides are used to provide visual aids for the discussion, these should also be made available for download prior to the meeting, in PDF format.
Re: Remote Participation Services
On 02/11/2013 10:46 PM, Bob Hinden wrote: Keith, On Feb 11, 2013, at 5:17 PM, Keith Moore wrote: On 02/05/2013 11:04 AM, IETF Chair wrote: 3.4. Slide Sharing Slides are often sent by email in advance of the meeting. WebEx allows the slides and desktop applications to be viewed by the remote participants. These are controlled by the presenter. The presenter can be shifted from participant to participant as needed. Can we *please* discourage the habit of treating IETF WG meetings as one series of PowerPoint presentations after another? This makes the meetings much less productive. The notion that there are supposed to be slides for each presentation, is IMO, a huge error. I disagree. The slides are a great help for non-native english speakers. Let me back up a bit, because I don't think I stated my case strongly enough. WG meetings should not, in general, be used for presentations. They should primarily be used for discussions. Presentations are largely a waste of precious WG time. It is sometimes possible to prepare slides to help facilitate discussions. But more often than not, the exercise of preparing slides encourages the speaker to fill up most or all of the available time with presentation material, leaving insufficient time for discussion of important questions. I certainly agree that when presentations are made, the slides can be helpful to those who aren't so fluent in English. My point is that presentations should be made only rarely. Keith
Re: Remote Participation Services
On 02/11/2013 11:45 PM, Joel M. Halpern wrote: Keith, you seem to be asking for something (discussion, wit no presentation), that has never happened in the WGs I have attended in the last 20 years. Even the WG sessions that had the best, most useful, discussions, generally started with a presentation of the topic and issue. Such initial presentation is usually strongly helped by clear bullets that everyone can follow to keep straight what is being discussed. yes, many of the briefings (here and elsewhere) are people reading their slides. yes, Powerpoint seems to make this worse in the way the tool is designed. But the issues seems to me not to e slides. If I had to guess, it is a combination of folks lacking confidence to discuss their material, folks doing what they have seen, and the patterns the tools encourage. There almost certainly are other factors. If you could assume that all 10 people you were talking to were fully up to speed on the topic, and had not lost context to the other 10 WG sessions they have been preparing for, and if we knew how to hold conversations effectively in rooms with 50+ people, and ... Yes, we should be looking for encouraging, and thanking / rewarding, those people who use their slots to briefly present and then engage in conversation with the WG. But lets not invent a fictional past in which this was some how natural, or even the norm. I remember IETF before PowerPoint. Yes, people wrote topics or drew diagrams on transparencies that were projected for viewing within the room. But (perhaps because preparing such materials was laborious) I don't recall the majority of WG time being devoted to reading things from those slides. I do recall lots of fruitful discussions. Keith p.g. Admittedly, there were other differences when I first started participating in IETF. e.g. Most people didn't have laptops, and the rooms didn't have wireless Internet, so you didn't see meeting rooms full of people playing solitare, reading email, and/or browsing the web and not paying attention.
Re: The notion of fast tracking drafts
On 12/14/2012 06:09 PM, John C Klensin wrote: I've been trying to say out of this because I think most of the suggestions are better carried out by AD-encouraged experiments and reports to the rest of us on effectiveness rather than by long discussions in the community about details and the costs of an unnecessary consensus process. However, since I gather we are pushing (or being pushed) down this path, let me suggest that approval of an IETF spec, especially a standards-track one, has (or should have) elements of all of the following: (1) A conviction that the idea is implementable and that the ideas expressed are consistent with implementation (and, ideally, operational realities. (2) Specification of sufficient quality to make independently-developed interoperable implementations by people who were not part of the WG or development process possible and specifically that there are no ambiguities that could adversely affect interoperable implementations. This includes, but is not limited to, editorial quality in terms of good technical English, but does not include good idea criteria (see (4)). (3) No known technical defects in the spec (the RFC 2026 requirement). Note that, while an implementation might turn up technical defects that might otherwise be unknown, it might easily not turn up ones that could be identified in other ways. It should imply a fairly comprehensive review that would have a high likelihood of turning up any technical defects that are present, but we all know that sometimes doesn't happen. (4) Some level of IETF consensus that publishing the specification has value for the community. This might or might not include a community belief that the document specifies a good idea that should be implemented and deployed (the latter is why we have Applicability Statements). to this I'd add (5) Widespread, examined belief that the specification has minimal impact on the Internet architecture. I keep seeing IETF standardize protocols that seem likely to have seriously damaging architectural impact without much, if any, examination of that impact (the PCP and MIF work come most immediately to mind, but I could cite several others given a few minutes to think about it). I'd hate to see a fast-tracking procedure used as a way to further circumvent such examination. Keith
Re: The notion of fast tracking drafts
On 12/16/2012 04:49 PM, Stephen Farrell wrote: ISTM that you are of the opinion that anything the IETF does to go faster is bad in and of itself because its scary. It's not that simple, at least in my opinion. I'm generally fine with fast tracking a document that describes a simple protocol that is easily understood, easily implemented, noncontroversial, and has a limited impact. In all other cases, I think that more deliberation is appropriate. That's not to say that IETF currently makes good use of deliberation time. But I'd rather see it make better use of that time, than to try to reduce that time without first improving protocol and document quality. For example, I'd like to see earlier and more explicit cross-area review. Keith
Re: Useful slide tex (was - Re: English spoken here)
On 12/04/2012 08:29 AM, Tim Chown wrote: Exactly. If the presentation is one slide listing the key changes in the document since the last revision/meeting, and one slide per key question/issue being asked of the room, then that should help facilitate good discussion, not hinder it. What doesn't work is a 15 minute presentation of the current contents of a draft that leaves a couple of minutes for questions. It's not the tool, it's how it's used. I'm somewhat amused that so many IETFers seem to be saying don't blame the tool, blame the people. Blaming people is such an effective way to encourage them to change their habits. :) Keith
Re: English spoken here
On 12/04/2012 12:50 PM, Steven Bellovin wrote: I started making up really good slides (in a variety of settings) after noticing non-native-English speakers at the IETF taking pictures of the screen -- it*really* helped them. I used to see that also, but I don't recall seeing anyone do that in Atlanta. Maybe people just download the slides now?
Re: Useful slide tex (was - Re: English spoken here)
On 12/03/2012 08:57 AM, George, Wes wrote: From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Keith Moore A different toolset, (e.g. pens and paper and overhead cameras coupled to projectors), would likely produce better results if that toolset did not encourage laziness in preparing materials to facilitate discussion. [WEG] I don't know about anyone else here, but you do *not* want me to attempt to facilitate a discussion using freehand drawings and writing. My handwriting and drawing skill was bad before I discovered a keyboard, and years of atrophy have made its usefulness approach zero as a meaningful method of communication. You'd be better off with the aforementioned stone tablets and cuneiform in terms of understanding. Nothing would prevent you from preparing drawings in advance (even using PowerPoint, if you wished) and bringing them to the meeting on paper. And you could still annotate them with pens during the discussion if you found it useful to do so. For that matter, nothing would prevent you from plugging your laptop into the projector, except perhaps the groans from the participants who might think you were about to start a presentation. And I echo what Dave said - quit blaming the tools and assuming that forcing people to use tools they're not used to using will fix this. I've seen over and over again that the choice of tools significantly affects how people interact and the quality of their interaction, and I'm frankly amazed that others in IETF haven't seen this also. And I don't really propose that people be forbidden to use PowerPoint. There will still be times when it's an appropriate tool, and hard-and-fast process rules can create as many problems as they solve. But I do suggest that if someone is alloted a discussion session in an IETF WG meeting, that he should think twice before sitting down to use PowerPoint to crank out a deck of slides for it. I also realize that people don't like to change the tools that they're accustomed to using. But the whole point of this discussion is to encourage this community, and people in this community, to make better use of precious meeting time, have better discussions, produce better specifications, and to do so more quickly. To the extent which our community's habits have contributed to poor use of meeting time and degraded the quality of discussion, it makes sense to reexamine those habits. And use of PowerPoint is one of those habits which I believe should be reexamined. You have a very specific opinion of what an effective WG session should be like and what people should and should not be doing to facilitate such. Sounds like you need to work with the EDU team to give a Sunday afternoon training session entitled how not to turn a WG session into a broadcast-only medium possibly with a section for WG chairs and a section for potential speakers. Years ago, my impression was that that Sunday training sessions were pretty much ignored by anyone experienced in the organization. Is this still the case? Keith
Re: PowerPoint considered harmful (was Re: Barely literate minutes)
On 12/02/2012 01:29 AM, Melinda Shore wrote: On 12/1/12 9:19 PM, Randy Bush wrote: sadly, too many of us remember writing on scrolls of acetate. i imagine that some remember stone and chisels. At the last meeting, for my own stuff I went with the old one-slide approach. However, it did occur to me that by doing that the slide(s) lost its archival value (slim as that may have been) for people not in the room. Anyway. Not really sure what can be done about this - you can say discussion, not presentation until you're blue in the face and the outcome of all that will be a blue face but presentations during the meetings anyway. Ultimately I expect it comes down to how individual chairs want to run meetings. I think that organizations sometimes get into habits of doing things regardless of whether those things work well. And the habits sometimes become so entrenched that it's considered heresy to suggest that they be changed. Even individual chairs might have a difficult time changing those habits for their own working groups. Keith
Re: PowerPoint considered harmful (was Re: Barely literate minutes)
On 12/02/2012 03:27 AM, Brian E Carpenter wrote: Yes. It escapes me why we would hamper ourselves by *not* using diagrams to explain complicated new ideas. The first time. Not the second and subsequent times; that's why we have proceedings. It also escapes me why we would hamper ourselves by not projecting lists of open issues. True, almost everyone has a little screen on their knee. Mine is usually full of jabber sessions for clashing WG meetings, the text currently under discussion, etc. I prefer to see the current discussion item on the big screen. We should also remember that in our community with very diverse ways of pronouncing the English language, the words on the big screen are sometimes better understood than the words spoken. I do agree that the ability to write new stuff on the screen in real time was a significant advantage of the old acetate sheet. That is clumsy to do with PPT. I have no objection to using PPT to display diagrams or lists of open issues. And I understand that PPT can be of aid to those (including me) who have trouble with understanding the diverse ways that English is spoken. But I still maintain that there's something about PPT and similar tools that tend to degrade interaction rather than facilitate it, and that this is tremendously damaging to the way IETF working groups conduct their face-to-face sessions. For example, PPT is much better at conveying short, bulleted lists than diagrams. It's tedious to draw diagrams with PPT, and I suspect, with most similar tools. Most computers still have keyboards which are good for inputing text, but most computers don't have an input stylus for drawing. And it's much more time consuming to draw adequate drawings with a mouse or trackpad than to draw them on acetate with a pen. For another, PPT's ability to rearrange slides actually makes it really good for working out the order of things to be presented. There's nothing at all wrong with using PPT in that way, as long as the slides aren't actually projected on the screen, and the speaker doesn't feel compelled to follow them closely. (The PPT files could still be made available for download, even in advance, thus inviting participants to prepare their own questions and counterpoints in advance.) Also, there's something about PPT that seems to encourage speakers to attempt to capture everything that's possibly relevant to a topic, and thus, to fill up all available time, leaving none for discussion. Maybe this is why the best way that I've ever discovered to use PPT is to help me collect my thoughts and organize them into a logical sequence for presentation; then to identify the points which are best conveyed by drawing and to incorporate those drawings into the presentation; then to hide all or almost all of the text-only slides. If we want to work effectively, we must not let our work habits be dictated by newer technology, especially when older and simpler technology works better. If slide projectors, sheets of acetate, and appropriate pens are no longer readily available, perhaps we need to ship large dry-erase boards and markers for those to every meeting. Keith p.s. I certainly acknowledge the difficulty in understanding different dialects of English. But it strikes me that part of the problem is the high level of ambient noise in the presentation environment, resulting in large part from having large numbers of people in the room who aren't paying (much) attention and who are each generating small amounts of noise, say by typing on laptops, or chatting quietly with those sitting near them. This is just one way that people who are just camping out in a room distract from what is going on.
Re: PowerPoint considered harmful (was Re: Barely literate minutes)
On 12/02/2012 09:45 AM, John C Klensin wrote: But rigs for cameras that are set up to be pointed down onto sheets of paper on which drawings and notes are being made are a lot more compact, compatible with the projectors we are using already, and, like overhead transparencies and PowerPoint-like decks, leave traces that can easily be incorporated into minutes -- something that is less feasible with any whiteboard technology we'd be likely to be able to drag around. I'd love to see us adopt such technology and strongly encourage its use, while at the same time actively discouraging the use of these meeting slots for /presentations/ and instead treating them as /discussions/. (Another way to put is that even if we provide such cameras in meetings along with colored pens and paper, we will continue to see PowerPoint being used as it is today unless there's a community-wide effort to change our entrenched habits.) Keith
Re: PowerPoint considered harmful (was Re: Barely literate minutes)
On 12/02/2012 10:03 AM, John C Klensin wrote: --On Sunday, December 02, 2012 09:53 -0500 Keith Moore mo...@network-heretics.com wrote: ... (Another way to put is that even if we provide such cameras in meetings along with colored pens and paper, we will continue to see PowerPoint being used as it is today unless there's a community-wide effort to change our entrenched habits.) Sure. But it is the now-entrenched habits that are the problem. The overuse of PowerPoint for purposes of which neither of us approve is merely a symptom, not, IMO, a cause (even if it reinforces the behaviors). Agreed, though sometimes when changing habits it helps to focus attention on the most visible or tangible part of the habit. It's always been possible, and will presumably remain possible, to build small PowerPoint decks that consist of only a few diagrams, to leave some blank slides in the middle of the deck for the purpose of typing in comments made at meetings, etc. -- all for the purpose of facilitating discussion. I wouldn't have a problem with PowerPoint being used in that way, though I suspect that it will be difficult for people to restrain themselves to using PowerPoint in that way as long as that's the tool that they're using. Anyone for incorporating a slide (!) into the Newcomer's Presentation (!!) that says a presentation in a f2f meeting that makes extensive use of PowerPoint decks with many and/or dense slides brands the presenter as either a newcomer, someone who is trying to avoid an actual discussion, or a fool? :-( Yes, but first we need to get existing WG chairs to say that to their participants, and to push back on people who continue to do use PowerPoint in that way in meetings. Keith
Re: Useful slide tex (was - Re: English spoken here)
On 12/02/2012 12:42 PM, Dave Crocker wrote: But can be considerably aided in many cases by written material (slides, summaries, or both) well in advance especially if those material are also used at the meeting, thereby aiding synchronization. This is a very specific matter of technique. As I started doing more presentations outside the US or with mixed audiences, I was told that the challenge of slide content is to make it neither too terse nor too verbose. Too terse imparts too little information for a reader who is using them to augment listening to the English. Too verbose, of course, takes too much time to read for real-time. In addition, slides often circulate later and need to have enough text to be useful without the speaker's commentary. So I try to use telegraphic text that stands on its own. That is, it's a terse as I can make it, while still making sense without my commentary. (It turns out this also provides the opportunity to have the speaking commentary go beyond the slide text, since I can let the audience rely on the slides for key points.) I think you're missing the point. The core problem is the overuse of presentations, and presentation tools, for working group face to face meeting time which is better suited for discussion. For those occasions when presentations are appropriate, or for slides that are provided as background material in advance of the discussion, the above is good advice. Keith
Re: PowerPoint considered harmful (was Re: Barely literate minutes)
On 12/02/2012 12:50 PM, John C Klensin wrote: --On Sunday, December 02, 2012 12:19 -0500 Joel M. Halpern j...@joelhalpern.com wrote: There is another unfortunate community habit that I have noticed. It is, I believe, a consequence o their being simply too much stuff to look at. Of course, having too much stuff to look at is ultimately a consequence of the inability of the Steering Group to prioritize and structure work enough (even if it means saying no to reasonable, but less-important, proposals) that the number of things people (and they) have to look at bears a reasonable relationship to available time and resources. I'd add working group chairs (though I'm sure there are a few exceptions) to the list of those with an apparent inability to prioritize and structure work. Or perhaps WGs should have to get approval from their supervising AD before they can take on new documents. Keith
Re: Useful slide tex (was - Re: English spoken here)
On 12/02/2012 12:57 PM, Dave Crocker wrote: On 12/2/2012 9:51 AM, Keith Moore wrote: I think you're missing the point. The core problem is the overuse of presentations, and presentation tools, for working group face to face meeting time which is better suited for discussion. stop blaming the tool. focus on the folks doing the speaking. The tool is a big part of the problem. The tool encourages a certain style of interaction that is generally inappropriate for face to face working group meetings. Of course, strictly speaking, the focus is on the people who are using the tool, and more broadly, on using the habit and community expectation that keeps encouraging people to use a poorly suited tool. But they're using the tool poorly precisely because it's very difficult to use that tool well for that purpose. A different toolset, (e.g. pens and paper and overhead cameras coupled to projectors), would likely produce better results if that toolset did not encourage laziness in preparing materials to facilitate discussion. Keith
Presentation vs. Discussion sessions (was: PowerPoint considered harmful)
On 12/02/2012 01:06 PM, Melinda Shore wrote: There's a whole nexus of connected issues here, I think, and what a given person complains about depends on that person's pet peeves. It seems to me that if we were better about moving work forward between meetings (- peeve!) meeting time wouldn't be chewed up with presenting the current state of the work. While I fully agree that most WGs could be better at moving work forward between meetings, I don't think it would solve the problem of face to face meeting time being filled up with presentations. I suspect that most WG participants have difficulty keeping up with the traffic on their WGs' mailing lists for various reasons (too much distraction from normal work, the sad state of mail user agents, etc.). By forcing people to travel away from work, face-to-face meetings serve as useful interruptions from normal distractions and opportunities to catch up on IETF work. If working groups moved forward even faster than they do now, that might actually be seen to increase the need for presentations at face-to-face meetings. Occasionally I've wondered if IETF meetings should have presentation sessions separate from (and in advance of) working sessions.The difference between the two types of session would be clearly indicated in the schedule. The presentation sessions would be geared toward presenting an overview of current state of the proposals, including a summary of recent changes. Perhaps participants would be allowed to ask questions for clarification, but discussion should be discouraged and any kind of polling of the room or other decision making would be forbidden. The presentation meetings would therefore be optional for those who had kept up on the mailing list. And presentations would be forbidden in discussion sessions. I can imagine these being useful in several ways, e.g. in facilitating better cross-group and cross-area review. People who were active participants in working groups could attend presentation sessions of other groups, without sacrificing their attendance in the discussion sessions of the groups in which they were active. Perhaps roughly the first 2(?) days of an IETF meeting could be largely devoted to presentation sessions, and the remainder of the time to discussion sessions.Having a strict allocation of time for each kind of session isn't so important as having the presentation sessions for a particular group well in advance of the discussion session for that group. This is something that could be tried on a small scale, by a few working groups (say one in each area) before being widely adopted. It might help, however, to have explicit support for the idea in the tools that maintain and display the meeting schedules. Keith
Re: Useful slide tex (was - Re: English spoken here)
On 12/02/2012 01:46 PM, joel jaeggli wrote: We have non-native english speakers and remote participants both working at a disadvantage to follow the discussion in the room. We should make it harder for them by removing the pretext that the discussion is structured around material that they can review and follow along on? I don't think that's even remotely helpful. In general, the purpose of those meetings is *discussion*, not presentation. I'm all for exploring better ways to facilitate *discussion* among the diversity of IETF meeting attendees. But our experience with use of previously-prepared PowerPoint presentations to facilitate *discussion* shows that use of that tool, in that way and for that purpose, is a miserable failure. Of course I'd encourage speakers to make available for download summaries of the material to be discussed in advance of the meeting, for the benefit of non-native English speakers and others. PowerPoint (or better, PDF of material prepared in PowerPoint) seems like a reasonable format for that. I also think it would be quite helpful to arrange for the topics discussed and points raised in the discussion to be displayed in the room in real time, as they are typed. This would provide non-native speakers with visuals similar to what they see now with PowerPoint, but without the undesirable side-effect of coercing discussion time into presentations. This would also reinforce the need for a minute-taker and help to keep the minute-takers honest. (I doubt that PowerPoint is the best tool for this purpose, since it would be highly desirable to convey the same information, at the same time, to remote participants.) Keith
