two Air France bus tickets to CDG available
As a result of the recovery of my wife's purse, I now have two extra bus tickets. Contact me if you're interested. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Tech topics and plans for tonight's plenary
FYI, and to get people's minds in gear for tonight's technical discussion, here's the list of things we had suggested when we called for technical topics: 1/ The big interconnect -- voice and IP service provision (without re-running the VOIPEER bof). 2/ Does the IETF still follow (observe) the end-to-end and KISS principles? (e.g. sip, sipping, SBC, voipeer, ...) 3/ "I'm seeing a whole new world of NAT-alikes popping up with Session Border Controllers, and would like to mention this to the community." So, think about the topics and what might be interesting to talk about, in them, that isn't going to take us down the ratholes we've explored thoroughly before (in plenary or various working groups). Perhaps harder than the technology itself ;-) . ie Leslie. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: project management (from Town Hall meeting)
I would never suggest adopting a 4-year project schedule, but would suggest a number of simple project management techniques and goals: - As part of WG chair training, train WG chairs in basic project management techniques and indicate that driving progress is an important role. - For large WGs, encourage use of WG secretaries to track and encourage progress. If a WG is behind, the ADs might want to ask why a WG is not using this mechanism. - Avoid massive number of parallel efforts in working groups. Instead, focus on a small number of drafts and get them out in less than a year from draft-ietf-*-00. (They might start as draft-personal- if they are exploratory.) Excessive parallelism leads to 12 5-minute presentations in IETF meetings where nobody except the authors understands the open issues and everybody else is reading email. Also, if there 30 drafts under some form of consideration, the number of people that focus on any one draft is tiny, making real mailing-list discussions difficult. - Have tools that remind the working group of upcoming deadlines, i.e., drafts that are supposed to be finished (ready for WGLC) within the next IETF cycle. - Encourage authors to meet those deadlines and have mechanisms in place that encourage meeting deadlines (such as getting preferred airtime or put-back-at-end-of-queue). - Track all WGLCs in the I-D tracker. - Formally assign early reviewers (say, after -01) within the working group; we do this for conference papers all the time, with deadlines and automated reminders. (I maintain the EDAS tool set for this.) Right now, we sometimes ask for shows-of-hand, but there is usually limited follow-up. - For larger groups, consider a working group "architecture" call: a period of discussion where attention is focused on one draft, with the intent of resolving any architectural and big-picture issues, but not focusing on issues of formatting or other mechanical details. The WGLC is then for making sure that the draft is ready to ship. The working group would be encouraged to read the "mid-call" draft ahead of the period and all other draft discussion would be discouraged. - Provide an issue tracker for -01+ drafts, integrated with the I-D tracker. - For status overviews at WG meetings, provide time-in-service for all drafts, compare with charter deadline and indicate a list of priority drafts that should receive most of the WG attention. Henning on both Henning's remarks and one of Brian's slides. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Keeping this IETF's schedule in the future...?
On 3-aug-2005, at 15:09, Pekka Savola wrote: Add an extra 15 mins for lunch, it makes it so less 'rushed'. That would be a very good idea. Personally, I don't see much need for lengthening the lunch; I can see how having more time for lunch would be beneficial, but I'm not sure if a mere additional 15 minutes will do the trick, and going out during the middle of the day for two hours or more with our current level of scheduling difficulties seems severely suboptimal to me. having the break at 1.5 hrs makes the lunch (hopefully) more focused at the essentials (gather the company quickly; find food _close_ by; order; talk; eat; get back). In Holland we're not used to eating a full meal for lunch. It occurs to me that we could save a lot of time by having some kind of light lunch available at the meeting rather than rush out, order and eat quickly and rush back. Opinions from those with a different culinary culture...? I have yet to experience the benefits of the changed last slot/dinner order (nothing too interesting in the last slot from my point of view, so I went out to discover Paris) but I think it makes a lot of sense. The argument that it makes dinner time inconvenient isn't very relevant as most participants are outside their home timezone in the first place. But regardless of that, IMHO the breaks could be reduced to 15 mins or so. That would allow us at least 2-3 additional 1hr slots, which would probably be very useful due to numerous scheduling conflicts at least I've experienced. Ah, you mean per meeting rather than per day. :-) I'd have thought 30 minutes would be too long to, but it turns out this allows sessions to run late 10 minutes without trouble, which is much better than people rushing out so they don't miss the cookies the second the break starts. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: project management (from Town Hall meeting)
At 10:05 04/08/2005, Henning Schulzrinne wrote: I would never suggest adopting a 4-year project schedule, but would suggest a number of simple project management techniques and goals: - As part of WG chair training, train WG chairs in basic project management techniques and indicate that driving progress is an important role. I doubt that this is going to solve anything. All basic project management techniques assume that a project has a deadline and that the people working on it have some incentive to get the work done. This is not the case for ID's: we continue working on them until there is rough consensus, no matter how long it takes. The authors are volunteers, if other activities pop up and work on the ID has to be postponed, there is nothing the WG chair can do. The real question is: how can we set realistic deadlines and get commitment from people to get the work done by the deadline, even if they are interrupted. Only when we have answered this question, it makes sense to start looking at tools to support this process. - Avoid massive number of parallel efforts in working groups. Instead, focus on a small number of drafts and get them out in less than a year from draft-ietf-*-00. (They might start as draft-personal- if they are exploratory.) This is another result of doing work with volunteers. If somebody is interested in a topic but not in another, then there is nothing that can stop him from working on the first topic, even if it might be beneficial for overall progress to finish the topic first. Henk -- Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The NetherlandsThe NetherlandsMobile: +31.6.55861746 -- Look here junior, don't you be so happy. And for Heaven's sake, don't you be so sad. (Tom Verlaine) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Effecting major infrastructure change RE: I'm not the microphone police, but ...
On 3-aug-2005, at 16:09, Hallam-Baker, Phillip wrote: For the cases where there is a major infrastructure change that needs to be achieved I would like to see a more interactive process. At present the development model is a bunch of boffins go out into a shed, build something and then ask the customer if they like it. This process has not really worked for IPv6 or DNSSEC and I don't think it is likely to work for BGPSecurity either. Unfortunately, there doesn't seem to be a better way to do it. (Having a new standard imposed by the government would be more efficient, but still not "better".) What kind of trouble are you expecting with BGP security, by the way? One problem here is that there is no way that any shed is ever going to be big enough to fit in all the parties that might have a stake in the outcome. That's a feature. The people are in the shed to brainstorm or work out boring but important details. Neither of those work in groups that are big enough encompass all possible stakeholders. The people in the shed don't automatically get consensus, they have to convince the larger group that their work has merit. So when they come up with something bad, they've mostly wasted their own time and know better in the future. Rather than treating the inputs from other organizations as individual contributions I would like to see groups that have major infrastructure change have a process available for formally soliciting input from the various consortia where the stakeholders whose participation is essential tend to meet. Sounds an awful lot like the way ICANN does things. Although this way of doing things allows for additional decisiveness, it also adds a lot of contention after the fact. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: project management (from Town Hall meeting)
I doubt that this is going to solve anything. All basic project management techniques assume that a project has a deadline and that the people working We do have deadlines: charters, and external customers (implementors, other SDOs). on it have some incentive to get the work done. This is not the case for ID's: we continue working on them until there is rough consensus, no matter how long it takes. The authors are volunteers, if other activities pop up and work on the ID has to be postponed, there is nothing the WG chair can do. This is not quite true: authors are not volunteers in the normal soup-kitchen-volunteer sense. In most cases, authors are paid by their companies to do the work. This is not a hobby for most contributors. Even more classical volunteer organizations, like IEEE (the non-standards-part) and ACM, set deadlines and have mechanisms to deal with volunteers (true volunteers in that case) that can no longer perform. For example, journals routinely drop editors that don't perform their (unpaid, volunteer) duties. This is another result of doing work with volunteers. If somebody is interested in a topic but not in another, then there is nothing that can stop him from working on the first topic, even if it might be beneficial for overall progress to finish the topic first. Part of managing for success in any "volunteer" organization is to channel volunteer energy. Henning ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: project management (from Town Hall meeting)
Hi, ext Henk Uijterwaal wrote: At 10:05 04/08/2005, Henning Schulzrinne wrote: I would never suggest adopting a 4-year project schedule, but would suggest a number of simple project management techniques and goals: - As part of WG chair training, train WG chairs in basic project management techniques and indicate that driving progress is an important role. I doubt that this is going to solve anything. All basic project management techniques assume that a project has a deadline and that the people working on it have some incentive to get the work done. This is not the case for ID's: we continue working on them until there is rough consensus, no matter how long it takes. The authors are volunteers, if other activities pop up and work on the ID has to be postponed, there is nothing the WG chair can do. I hope you're not saying I-Ds have no deadlines. Sorry, but they do. Sure we're a voluntary organization, and technical quality is the first order of priority. But that does *not* mean that it is OK to work on a particular draft only six weeks per year (around the f2f meetings), or that it's OK to have an author disappear for six months, or that each and every crazy idea sent to the mailing list needs to be incorporated in late stages of the work, resulting in constant feature creep. Voluntary does not prohibit an incentives system, nor does it disallow project managers (the WG chairs) equipped with carrots and sticks. The real question is: how can we set realistic deadlines and get commitment from people to get the work done by the deadline, even if they are interrupted. By using the tools and conventions for WGs that Henning was proposing. Only when we have answered this question, it makes sense to start looking at tools to support this process. - Avoid massive number of parallel efforts in working groups. Instead, focus on a small number of drafts and get them out in less than a year from draft-ietf-*-00. (They might start as draft-personal- if they are exploratory.) This is another result of doing work with volunteers. If somebody is interested in a topic but not in another, then there is nothing that can stop him from working on the first topic, even if it might be beneficial for overall progress to finish the topic first. I think there is a misconception here about what "volunteer" means. I've worked in other voluntary organizations, and let me tell you, if you're a junior basketball coach but don't show up for practice, or decide to coach tennis unannounced for the next few months, you get replaced pretty quickly. Cheers, Aki Henk -- Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The NetherlandsThe NetherlandsMobile: +31.6.55861746 -- Look here junior, don't you be so happy. And for Heaven's sake, don't you be so sad. (Tom Verlaine) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
The plenary and the nomcom-term and review panel proposals
Four observations on the plenary discussion of my drafts... As I said at the end, I had not planned to come to the microphone at all. I wanted to listen. What I heard included... (1) To repeat what I did say (since it was apparently hard to hear) I see, once again, the problem that it has become very hard to introduce a concept into this community. If one tries to do so via a comment on a mailing list, there is never enough detail for anyone to really evaluate it (or the message is so long that almost no one reads it). If the concept is presented in an I-D, then the document is torn to shreds for not having enough detail for anyone to evaluate it. On the other hand, if details are provided in the initial document, even as an example to show that a plausible set of details is possible, the community (often including especially the IESG, immediately focuses in on the details and picks at them, ignoring the general concept and the usually-better question of how to adjust the concept and fill in any blanks. This behavior has a corollary along the "we cannot handle complexity" dimension. If one writes a single draft that covers the several aspects of a problem, it is attacked as "too long, too complex, and covering too many issues" and told it should be broken up into smaller pieces. If it is broken up (the set of issues here are now two and I have been advised to produce a third that identifies the principles only), then people complain that having several drafts at once is too much to deal with. That way of handling things, especially things that some people apparently just do not want to deal with, applies, I think, to both process proposals and our technical work. It is not good news if we actually want to get things done. (2) Several comments, during and after the discussion and most precisely framed by Spencer Dawkins, that I may have made an incorrect assumption about transition. The text more or less assumes that the review panel membership would be new and the IESG membership would be left in place. Perhaps the current IESG membership are most skilled in document review rather than the sort of WG leadership and steering functions that I had in mind -- the functions I think we had in the early 1990s. If that were the case, then we should resolve the detail of the IESG being larger than the review panel, shift the current IESG members onto the review panel, and repopulate the steering/coordination/management entity (probably calling it something other than "IESG"). (3) A comment from an IESG member that the notion would probably add work, since the document provides for documents rejected by the review panel to cycle back through the IESG. To me, this is one of the "sample detail" issues identified above. If the IESG wants to be explicitly in that loop, and the community wants that, then "back to the IESG as the submitting body" is the right model. I had anticipated their involvement at that point as lightweight, with the AD reviewing the comments and passing them on to the WG, but not assuming today's role of negotiator with the WG (or between the WG and the review panel). I think that negotiator role, after a document goes out for IETF Last Call, is the source of several of our problems and needs to be eliminated. For those who are reading this without having read the document, please note that rejection of a document by the review panel is intended to be A Big Deal. The document suggests a process that would focus on getting good-quality, pre-reviewed, documents to the review panel --with shared responsibility between the WG and the IESG's steering/managing function for being sure that happens-- with the review panel only organizing a final check. If the IESG believes that being in the "return" loop would be burdensome, then the proposal can easily be adapted to that belief. The change would be to have the review panel return the document directly to the WG, with the AD involved only as part of WG management. The IESG would then be involved again only as part of routine WG oversight and when the WG concluded that it was ready to resubmit the document. I will make that change for -01 unless others object. As a particularly strong variation, one could have the review panel return the document to the WG and then require either a "new benchmarks" or recharter activity since "rework a rejected document" would not be on the WG's pre-rejection charter. Again, from my point of view, these are details that can be sorted out and tuned if the community likes and wants the general concept. If the community does not, there is no point wasting the time to generate and debate those details. (4) I heard at least one IESG member say something that sounded suspiciously like: "We are really busy and have all of these technical documents to review. If you really want to discuss changes and process proposals, we wil
Re: On standards review panel and division of work
Hi, Pekka (but not only Pekka), If I understood Margaret last night, she was at least somewhat comfortable with a hard split between area management and technical review, so I'd like to at least ask one question... In discussions with John Klensin, I (and I think we) both assumed that the addition of an Standards Review Panel would mean that that the IESG participants remained on the IESG. But now I'm wondering - if we have a future-SRP and a future-IESG, which one of these does the current IESG more closely resemble? I'm trying to figure out if we're really adding a Standards Review Panel, because the existing IESG is spending too much time on standards review, or whether the existing IESG is spending a LOT of time on standards review, so we're really adding an Internet Engineering Steering Group... Spencer ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: project management (from Town Hall meeting)
At 11:07 04/08/2005, Henning Schulzrinne wrote: I doubt that this is going to solve anything. All basic project management techniques assume that a project has a deadline and that the people working We do have deadlines: charters, and external customers (implementors, other SDOs). I haven't counted the number of times were deadlines were missed this week alone with no consequences. For example, in a WG I attended this morning, the chair asked a person about a document he promised to write. The person answered that he'd do this in the next month. The chair replied that he said that last time as well. Some laughter followed, but that was the end of it. This is not quite true: authors are not volunteers in the normal soup-kitchen-volunteer sense. In most cases, authors are paid by their companies to do the work. I agree. But companies change priorities and with that the time people can spend on ID's. In this case, there is little we can do. I can see a solution (have get commitment from employers before assigning work to a person) but this will require a major change in the basic way we work. For example, journals routinely drop editors that don't perform their (unpaid, volunteer) duties. Yes, but I rarely see this happen in the IETF. Henk -- Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The NetherlandsThe NetherlandsMobile: +31.6.55861746 -- Look here junior, don't you be so happy. And for Heaven's sake, don't you be so sad. (Tom Verlaine) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: On standards review panel and division of work
--On Thursday, August 04, 2005 09:35 +0300 Pekka Savola <[EMAIL PROTECTED]> wrote: ... I do not think this is a show-stopper though; as many details in the proposal, things like these can be modified. In this case, I believe the problem can be easily addressed by giving the ADs the power to initiate the review requests to the review panel -- and encouraging them to do so. This would have several benefits: * if the expectation would be that drafts would be brought before the full IESG only in exceptional cases, the load and duplication ... I don't see any disadvantages, except that if there hasn't been sufficient cross-area review before requesting the review panel to review, they might have to shuttle the documents back and forth more often. This approach might also call for IETF-wide vetting of also WG-produces informational/experimental documents, if they would be reviewed by fewer people, but if this would be needed, it could be easily added later on and isn't worth considering at this point. See my note posted a short time ago (which was written before seeing yours). But, yes.This is exactly the thing I was commenting about in that note. It is, at some level, a detail. It can be tuned in any of a number of ways. I picked one, not quite at random. You suggest a different one above. I think we need to decide the concept is worthwhile (I'm not sure there is consensus on that yet), and then sort through these details. IMO, the "I don't like that detail so the proposal is invalid and should not be considered" approach is just not a productive way to proceed. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: project management (from Town Hall meeting)
I haven't counted the number of times were deadlines were missed this week alone with no consequences. For example, in a WG I attended this morning, the chair asked a person about a document he promised to write. The person answered that he'd do this in the next month. The chair replied that he said that last time as well. Some laughter followed, but that was the end of it. I would consider this a problem (cultural and otherwise), not a desirable state of affairs. If you mean that this requires more than just adding tools, I agree. I tend to believe the old saw that "we manage what we measure". Currently, we have a creeping bias of low expectations and no good way to measure if things are getting worse or better. In volunteer organizations, organizations that don't ask anything of their members tend to get what they ask for. (There have been interesting economics papers on why mainstream, low-commitment churches in the West have had difficulties keeping members. But I digress.) I agree. But companies change priorities and with that the time people can spend on ID's. In this case, there is little we can do. In extremis, WG chairs can re-assign the work to some other party or parties. If no other party is interested in doing the work, the draft must not be all that important after all. Forcing a do-or-die decision avoids wasting time of all parties concerned. I suspect that this will also trigger a discussion between employer and employee which will magically make time available. I can see a solution (have get commitment from employers before assigning work to a person) but this will require a major change in the basic way we work. I don't see "exported" commitments as useful since they won't be enforceable unless you add a performance bond. No, I'm not currently suggesting performance bonds... Yes, but I rarely see this happen in the IETF. Maybe that's a bug, not a feature. It is currently difficult to pull the plug since the tardy author can easily say "all other documents are late, why pick on me?". As a meta comment, saying that culture cannot change is the first and most obvious sign of a dying organization. I'm not claiming that you're claiming immutability, but I do hear variations on this in various remarks. Henning ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: project management (from Town Hall meeting)
On Thu, 4 Aug 2005, Henk Uijterwaal wrote: This is another result of doing work with volunteers. If somebody is interested in a topic but not in another, then there is nothing that can stop him from working on the first topic, even if it might be beneficial for overall progress to finish the topic first. Well, at least there is a mitigation factor (in theory). Set the maximum amount of documents that can be worked in parallel. If folks want their own document added as a WG document, they'll have to work on the existing documents out of the door first. (Obviously, this is a tool WG chairs can already use; I'd certainly be interested if the model has been executed successfully or unsuccessfully.) This also requires that documents with ineffective editors get raplaced reasonably quickly so there's always progress going on (and the proposers of new work can't say, "but the existing ones aren't going anywhere [because the editor isn't doing the job]"). -- Pekka Savola "You each name yourselves king, yet the Netcore Oykingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: project management (from Town Hall meeting)
on 2005-08-04 10:05 Henning Schulzrinne said the following: > I would never suggest adopting a 4-year project schedule, but would > suggest a number of simple project management techniques and goals: ... > - Have tools that remind the working group of upcoming deadlines, > i.e., drafts that are supposed to be finished (ready for WGLC) within > the next IETF cycle. I'm already planning to add something like this to the WG status pages, as part of providing some management tools for the chairs. I have some code in place, but I'm not ready to release anything yet. Hopefully before IETF-64, though. ... > - Provide an issue tracker for -01+ drafts, integrated with the I-D > tracker. I'm considering as part of the tools work setting up an issue tracker for each WG as part of the WG status page. It will be closely integrated with the WG mailing list. It should also be able to do some integration with the I-D tracker, although it's not immediately obvious to me exactly what kind of integration with the I-D tracker would be beneficial here. Could you expand on this? Henrik ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
unsubscribe
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: None To: ietf@ietf.org Subject: Ietf Digest, Vol 16, Issue 17 Send Ietf mailing list submissions to ietf@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www1.ietf.org/mailman/listinfo/ietf or, via email, send a message with subject or body 'help' to [EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] When replying, please edit your Subject line so it is more specific than "Re: Contents of Ietf digest..." Today's Topics: 1. Re: project management (from Town Hall meeting) (Henning Schulzrinne) 2. Re: project management (from Town Hall meeting) (Aki Niemi) 3. The plenary and the nomcom-term and review panel proposals (John C Klensin) 4. Re: On standards review panel and division of work (Spencer Dawkins) 5. Re: project management (from Town Hall meeting) (Henk Uijterwaal) 6. Re: On standards review panel and division of work (John C Klensin) 7. Re: project management (from Town Hall meeting) (Pekka Savola) 8. Re: project management (from Town Hall meeting) (Henning Schulzrinne) -- Message: 1 Date: Thu, 04 Aug 2005 05:07:49 -0400 From: Henning Schulzrinne <[EMAIL PROTECTED]> Subject: Re: project management (from Town Hall meeting) To: Henk Uijterwaal <[EMAIL PROTECTED]> Cc: ietf@ietf.org Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed > I doubt that this is going to solve anything. All basic project management > techniques assume that a project has a deadline and that the people working We do have deadlines: charters, and external customers (implementors, other SDOs). > on it have some incentive to get the work done. This is not the case for > ID's: we continue working on them until there is rough consensus, no matter > how long it takes. The authors are volunteers, if other activities pop up > and work on the ID has to be postponed, there is nothing the WG chair can > do. This is not quite true: authors are not volunteers in the normal soup-kitchen-volunteer sense. In most cases, authors are paid by their companies to do the work. This is not a hobby for most contributors. Even more classical volunteer organizations, like IEEE (the non-standards-part) and ACM, set deadlines and have mechanisms to deal with volunteers (true volunteers in that case) that can no longer perform. For example, journals routinely drop editors that don't perform their (unpaid, volunteer) duties. > This is another result of doing work with volunteers. If somebody is > interested in a topic but not in another, then there is nothing that > can stop him from working on the first topic, even if it might be > beneficial for overall progress to finish the topic first. Part of managing for success in any "volunteer" organization is to channel volunteer energy. Henning -- Message: 2 Date: Thu, 04 Aug 2005 12:11:49 +0300 From: Aki Niemi <[EMAIL PROTECTED]> Subject: Re: project management (from Town Hall meeting) To: ext Henk Uijterwaal <[EMAIL PROTECTED]> Cc: ietf@ietf.org Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hi, ext Henk Uijterwaal wrote: > At 10:05 04/08/2005, Henning Schulzrinne wrote: > >> I would never suggest adopting a 4-year project schedule, but would >> suggest a number of simple project management techniques and goals: >> >> - As part of WG chair training, train WG chairs in basic project >> management techniques and indicate that driving progress is an >> important role. > > > I doubt that this is going to solve anything. All basic project management > techniques assume that a project has a deadline and that the people working > on it have some incentive to get the work done. This is not the case for > ID's: we continue working on them until there is rough consensus, no matter > how long it takes. The authors are volunteers, if other activities pop up > and work on the ID has to be postponed, there is nothing the WG chair can > do. I hope you're not saying I-Ds have no deadlines. Sorry, but they do. Sure we're a voluntary organization, and technical quality is the first order of priority. But that does *not* mean that it is OK to work on a particular draft only six weeks per year (around the f2f meetings), or that it's OK to have an author disappear for six months, or that each and every crazy idea sent to the mailing list needs to be incorporated in late stages of the work, resulting in constant feature creep. Voluntary does not prohibit an incentives system, nor does it disallow project managers (the WG chairs) equipped with carrots and sticks. > The real question is: how can we set realistic deadlines and get commitment > from
Review panel's role
On Thu, 4 Aug 2005, John C Klensin wrote: (2) Several comments, during and after the discussion and most precisely framed by Spencer Dawkins, that I may have made an incorrect assumption about transition. The text more or less assumes that the review panel membership would be new and the IESG membership would be left in place. Perhaps the current IESG membership are most skilled in document review rather than the sort of WG leadership and steering functions that I had in mind -- the functions I think we had in the early 1990s. If that were the case, then we should resolve the detail of the IESG being larger than the review panel, shift the current IESG members onto the review panel, and repopulate the steering/coordination/management entity (probably calling it something other than "IESG"). Personally, I don't think changing the proposal in this aspect is worth the effort. Changing people around seems more trouble than electing new ones. The existing IESG people, if they felt the review panel is more suited for them, could very well apply to the review panel, and if selected, the nomcom would pick the IESG replacement. In a year or two, everything would be settled in any case. The people will find the roles they're interested in. (But this wasn't my maint point in replying..) (3) A comment from an IESG member that the notion would probably add work, since the document provides for documents rejected by the review panel to cycle back through the IESG. To me, this is one of the "sample detail" issues identified above. If the IESG wants to be explicitly in that loop, and the community wants that, then "back to the IESG as the submitting body" is the right model. I had anticipated their involvement at that point as lightweight, with the AD reviewing the comments and passing them on to the WG, but not assuming today's role of negotiator with the WG (or between the WG and the review panel). I think that negotiator role, after a document goes out for IETF Last Call, is the source of several of our problems and needs to be eliminated. For those who are reading this without having read the document, please note that rejection of a document by the review panel is intended to be A Big Deal. The document suggests a process that would focus on getting good-quality, pre-reviewed, documents to the review panel --with shared responsibility between the WG and the IESG's steering/managing function for being sure that happens-- with the review panel only organizing a final check. I'm troubled with the assumption that the review panel rejection is A Big Deal. This has unstated assumptions on what kind of people you'd expect to be on the review panel and/or what kind of review is expected. As an occasional reviewer myself, a few observations: * All the indepth reviews I have done have resulted in issues, * If I haven't found a problem or a request for clarification, I haven't paid sufficient attention to the review, and * IMHO there is nothing more frustrating than finding problems (not maybe critical ones) which don't get fixed for one reason or another (e.g., because it isn't worth the time to respin the document, giving that comment would be a "big deal", ...). Scientific reviews certainly have "accept", "reject", or "accept with modifications". Maybe forcing "yes, business as usual" or "no, A Big Deal" is intentional -- to encouraging the reviewers to perform less in-depth reviews (with more responsibility on the chairs and the IESG) so that they'd only complain of the most horrid problems, to lessen the load, to encourage earlier participation, make sure the majority of the docs go through without issues, etc. As how to address this, a few observations: * the review panel's review function has to be roughly equivalent to what review the IESG is doing today, so that the IESG can "give up" most of its review with good confidence. * to achieve this, I think we need "accept", "reject", "tentative accept" resolutions where in all cases the panel could include feedback on things that were noted. * whether or not the review panel (or the reviewers) check the revised documents after "tentative accept", whether the checking responsibility is with the AD(s), or something else is an interesting detail point which probably isn't relevant at this point. Hope this helps in getting a better understanding on what the role of the panel could be. -- Pekka Savola "You each name yourselves king, yet the Netcore Oykingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: On standards review panel and division of work
I think the concept of separating the responsibility for final document review and approval from the responsibility for chartering and managing working workings. Yes, there are some tricky details. But it looks like they are solvable and the approach leads to improvement in several regards. Yours, Joel M. Halpern At 06:09 AM 8/4/2005, John C Klensin wrote: See my note posted a short time ago (which was written before seeing yours). But, yes.This is exactly the thing I was commenting about in that note. It is, at some level, a detail. It can be tuned in any of a number of ways. I picked one, not quite at random. You suggest a different one above. I think we need to decide the concept is worthwhile (I'm not sure there is consensus on that yet), and then sort through these details. IMO, the "I don't like that detail so the proposal is invalid and should not be considered" approach is just not a productive way to proceed. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Review panel's role
Speaking only for myself, and at the slogan level, I'm troubled with the assumption that the review panel rejection is A Big Deal. This has unstated assumptions on what kind of people you'd expect to be on the review panel and/or what kind of review is expected. As an occasional reviewer myself, a few observations: * All the indepth reviews I have done have resulted in issues, * If I haven't found a problem or a request for clarification, I haven't paid sufficient attention to the review, and * IMHO there is nothing more frustrating than finding problems (not maybe critical ones) which don't get fixed for one reason or another (e.g., because it isn't worth the time to respin the document, giving that comment would be a "big deal", ...). I'm troubled with the fact that at least 70 percent of our documents get at least one DISCUSS - which means that at least one AD thought the document had a big enough problem that approving the document in its current form was not the right thing to so. I know it eludes most of us, most of the time, that almost every standards action we have seen for as long as we have been in the IETF has been for Proposed Standards, and (look at 2026 if you think I'm kidding) these are SUPPOSED to be specifications at an early stage of maturity. We need to get to the point where we forward specifications that don't bounce back most of the time. I haven't said it out loud, but I hope that a Standards Review Panel might be able to tackle early and cross-area review - with help from the community - which the IESG was NOT able to tackle (see ICAR). So, I'm not asking the Standards Review Panel to approve junk. I'm asking the community to support getting to the point where most of our documents that reflect WG concensus are not going to bounce back in late review. We aren't there yet. We desperately need to be "there". In My Opinion. Spencer ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: project management (from Town Hall meeting)
the I-D tracker, although it's not immediately obvious to me exactly what
kind of integration with the I-D tracker would be beneficial here. Could
you expand on this?
Not much linkage: any I-D automatically has an issue tracker associated
with it and there is a link from the I-D tracker to the issue tracker
screen. I would also find a quick summary statistic useful, akin to some
of the sourceforge-like pages:
draft-ietf-fubar-67.txt 17 open issues
draft-ietf-barfu-17.txt no issues
where the "17 open issues" text links to the issue tracker. ("No issues"
means that nobody has posted any.")
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Re: Review panel's role
I think it would be useful to analyze the nature of current DISCUSS
comments before drawing conclusions from the 70% figure. They apparently
range from simple typos ("expand acronyms") to differences of opinion
("WG chose X, AD prefers Y; both X and Y are at least plausible") to
adding various disclaimers to fundamental design problems ("broken").
Unless we write like lawyers writing product warranties, we will always
have differences of opinion as to which disclaimers are important enough
to call out explicitly and how strongly, regardless of how much
pre-approval review is done.
Spencer Dawkins wrote:
Speaking only for myself, and at the slogan level,
I'm troubled with the assumption that the review panel rejection is A
Big Deal. This has unstated assumptions on what kind of people you'd
expect to be on the review panel and/or what kind of review is expected.
As an occasional reviewer myself, a few observations:
* All the indepth reviews I have done have resulted in issues,
* If I haven't found a problem or a request for clarification, I
haven't paid sufficient attention to the review, and
* IMHO there is nothing more frustrating than finding problems (not
maybe critical ones) which don't get fixed for one reason or
another (e.g., because it isn't worth the time to respin the
document, giving that comment would be a "big deal", ...).
I'm troubled with the fact that at least 70 percent of our documents get
at least one DISCUSS - which means that at least one AD thought the
document had a big enough problem that approving the document in its
current form was not the right thing to so.
I know it eludes most of us, most of the time, that almost every
standards action we have seen for as long as we have been in the IETF
has been for Proposed Standards, and (look at 2026 if you think I'm
kidding) these are SUPPOSED to be specifications at an early stage of
maturity.
We need to get to the point where we forward specifications that don't
bounce back most of the time. I haven't said it out loud, but I hope
that a Standards Review Panel might be able to tackle early and
cross-area review - with help from the community - which the IESG was
NOT able to tackle (see ICAR).
So, I'm not asking the Standards Review Panel to approve junk. I'm
asking the community to support getting to the point where most of our
documents that reflect WG concensus are not going to bounce back in late
review. We aren't there yet. We desperately need to be "there".
In My Opinion.
Spencer
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
RE: project management (from Town Hall meeting)
> > - Provide an issue tracker for -01+ drafts, integrated with the I-D > > tracker. > > I'm considering as part of the tools work setting up an issue > tracker for each WG as part of the WG status page. It will be > closely integrated with the WG mailing list. That would be excellent. When introducing issue trackers, it is essential to consider how things are archived, and the mail list archives are our archives. Having a tracker system generally available and integrated with the WG mailing lists would give us a consistent way of working and archiving. /L-E ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Review panel's role
I think it would be useful to analyze the nature of current DISCUSS
comments before drawing conclusions from the 70% figure. They
apparently range from simple typos ("expand acronyms") to
differences of opinion ("WG chose X, AD prefers Y; both X and Y are
at least plausible") to adding various disclaimers to fundamental
design problems ("broken").
I agree completely with Henning. If I understood Allison in the
plenary last night, she was saying that most DISCUSSes don't really
result in much change (Allison, if I misunderstood, please correct
me).
My point is that each of these DISCUSSes kept a specification from
being approved for at least one two-week telechat cycle. I believe, in
the absence of data, that adding delays to a project makes it easier
to stretch out other delays, so "two weeks" is the minimum amount of
time one would wait before a specification would be reballoted, but if
a document editor is on vacation for a week and doesn't provide
updated text immediately, the actual delay can be longer.
I would like to get out of this situation.
Given that the AUTH48 delay is averaging something like a month (did I
get this data point right from the plenary last night?), I'm hoping
that getting crisper and more predictable in the approval cycle will
also encourage working groups to get crisper and more predictable in
their part of the process.
Spencer
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Re: Review panel's role
On Thu, 4 Aug 2005, Spencer Dawkins wrote:
My point is that each of these DISCUSSes kept a specification from
being approved for at least one two-week telechat cycle. I believe,
in the absence of data, that adding delays to a project makes it
easier to stretch out other delays, so "two weeks" is the minimum
amount of time one would wait before a specification would be
reballoted, but if a document editor is on vacation for a week and
doesn't provide updated text immediately, the actual delay can be
longer.
Documents don't need to be reballoted [in IESG] to be approved (after
being revised). This is up to the nature of the comments/changes and
the AD's confidence that the discusses have been addressed to the
satisfaction of commenters, and that new text doesn't have issues.
If time is of the essence, the chair or whoever could certainly take
up the document from the editor; I've done so personally in a couple
of cases.
On Thu, 4 Aug 2005, Henning Schulzrinne wrote:
I think it would be useful to analyze the nature of current DISCUSS
comments before drawing conclusions from the 70% figure. They
apparently range from simple typos ("expand acronyms") to
differences of opinion ("WG chose X, AD prefers Y; both X and Y are
at least plausible") to adding various disclaimers to fundamental
design problems ("broken").
Exactly. As I read it, the review panel proposal included "yes" and
"no". If you say "yes", the document is shipped as-is.
It is (IMHO) important to be able to fix problems, even if relatively
minor, even if you would like to say "yes" or would have confidence
that the problems could be fixed in a day or two.
There are many levels of issues, for example:
- "there is a significant architectural problem in the doc", NO (or
big discuss)
- "there are major issues which require at least significant
clarification/discussion"
- there are relatively important issues which need to be fixed but
are so straightforward that the WG (and the editor in particular)
can probably do it without further dialogue.
- there are typos or other things affecting readability, and
sometimes even the clarity of the document.
- probably a lot more different classes of issues..
To me, having reviews which wouldn't report any issues would meant
that with high probability, such reviews wouldn't be sufficiently
indepth. Finding issues is one sign of a good review -- if the issues
found are minor, this is also often a sign of a document in a good
shape. Discarding the issues doesn't seem good, though if they are
minor, the amount of dialogue/energy needed should be minimized.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oykingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Re: project management (from Town Hall meeting)
on 2005-08-04 14:59 Henning Schulzrinne said the following:
>> the I-D tracker, although it's not immediately obvious to me exactly what
>> kind of integration with the I-D tracker would be beneficial here. Could
>> you expand on this?
>
> Not much linkage: any I-D automatically has an issue tracker associated
> with it and there is a link from the I-D tracker to the issue tracker
> screen. I would also find a quick summary statistic useful, akin to some
> of the sourceforge-like pages:
>
> draft-ietf-fubar-67.txt 17 open issues
> draft-ietf-barfu-17.txt no issues
>
> where the "17 open issues" text links to the issue tracker. ("No issues"
> means that nobody has posted any.")
Ah, right. This makes sense to me, and should be easy to put in place
also with the issue trackers not being implemented as part of the I-D
tracker.
Henrik
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Re: Review panel's role
Two observations, just my opinion...
--On Thursday, August 04, 2005 15:18 +0200 Spencer Dawkins
<[EMAIL PROTECTED]> wrote:
I think it would be useful to analyze the nature of current
DISCUSS comments before drawing conclusions from the 70%
figure. They apparently range from simple typos ("expand
acronyms") to differences of opinion ("WG chose X, AD
prefers Y; both X and Y are at least plausible") to adding
various disclaimers to fundamental design problems
("broken").
I agree completely with Henning. If I understood Allison in
the plenary last night, she was saying that most DISCUSSes
don't really result in much change (Allison, if I
misunderstood, please correct me).
Well, as long as we don't remove the "editor" function from "RFC
Editor" I hope there is _never_ an IESG DISCUSS on "expand
acronyms". If there is, we are doing something seriously wrong
and wasting time, probably a month or more (AD reads document to
that level, writes up DISCUSS, enters it in tracker, negotiates
with author, slides to the next telechat...). The good news is
that, while I could be wrong, my subjective impression is that
those happen rarely if at all these days. The bad news is that
these DISCUSSes are mostly more substantive, and that brings us
to...
My point is that each of these DISCUSSes kept a specification
from being approved for at least one two-week telechat cycle.
I believe, in the absence of data, that adding delays to a
project makes it easier to stretch out other delays, so "two
weeks" is the minimum amount of time one would wait before a
specification would be reballoted, but if a document editor is
on vacation for a week and doesn't provide updated text
immediately, the actual delay can be longer.
I would like to get out of this situation.
There is another element of this, which intersects with NEWTRK
and Spencer's earlier note. While we haven't been taking
advantage of them, there are really strong reasons for a two (at
least)-stage standards process. One of them is the ability to
get those early-stage specifications that Proposed Standards are
supposed to be out the door.
Conceptually, I think we ought to be adding a new section to
most Proposed Standards. That section is exactly what 2026
indirectly calls for in its prohibition on known technical
deficiencies, reading that is "we know about them and know how
to fix them". Perhaps we should be letting things go out with
an "Areas of Unresolved Controversy" section in which questions
and issues that are not absolutely fatal showstoppers, to a
proposal could just be identified in a Proposed Standard, the
thing shipped, and those issues resolved before the
specification could go to Draft (or, in a two-step process, Last
or whatever it is called).
This is not yet another process change suggestion, just a
suggestion that we need to, again, think of Proposed Standards
as what 2026 and the term "proposed" imply, such that the
response to finding a slightly-important problem is to note it
and move on, rather than aspiring to have every specification
perfect, even pre-implementation specifications.
Of course, one could get the same effect by declaring all of
today's Proposed Standards to be Experimental, taking the "note
and move on" approach to them, and then having a one-stage
standards track that requires implementation and deployment
experience to get to stage 1.
john
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Re: Review panel's role
Hi, Pekka, I rarely if ever argue with you about protocol stuff, because you're pretty good at protocols, and our process IS a protocol, but I do see "returned to clear DISCUSS" items on the IESG telechat agendas. So, I bet you're right, but there is running code that we actually DO end up sliding to the next telechat, at least some of the time. Spencer Documents don't need to be reballoted [in IESG] to be approved (after being revised). This is up to the nature of the comments/changes and the AD's confidence that the discusses have been addressed to the satisfaction of commenters, and that new text doesn't have issues. If time is of the essence, the chair or whoever could certainly take up the document from the editor; I've done so personally in a couple of cases. In all honesty, there are a lot of things that you do that I wish we all did, and this is one of them :-) Spencer ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Review panel's role
On Thu, 4 Aug 2005, Spencer Dawkins wrote: I rarely if ever argue with you about protocol stuff, because you're pretty good at protocols, and our process IS a protocol, but I do see "returned to clear DISCUSS" items on the IESG telechat agendas. So, I bet you're right, but there is running code that we actually DO end up sliding to the next telechat, at least some of the time. FWIW, I've seen this in basically two scenarios: - the "discussing ADs" have proved to be unresponsive, either in 1) actually (not) dicussing the comment for one reason or another, or 2) verifying that the new version addresses their DISCUSS. The trick of the shepherding AD is to force re-review of the spec by putting it back on the agenda. (This is what I've seen in most cases, and yes, it's a problem -- I've also mailed the IESG about it.) - the changes have been very extensive (and possibly partially the above in verifying whether they address the issues), and re-reviewing the document at the IESG has been considered appropriate. -- Pekka Savola "You each name yourselves king, yet the Netcore Oykingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Review panel's role
(note is long - summary: Review panel SHOULD, in my opinion, be able to
send back documents to WG without it being a Big Deal. At least once.)
--On 4. august 2005 09:08 -0400 Henning Schulzrinne <[EMAIL PROTECTED]>
wrote:
I think it would be useful to analyze the nature of current DISCUSS
comments before drawing conclusions from the 70% figure. They apparently
range from simple typos ("expand acronyms") to differences of opinion
("WG chose X, AD prefers Y; both X and Y are at least plausible") to
adding various disclaimers to fundamental design problems ("broken").
I don't know if Bill's database extract contains the actual DISCUSS text,
but the analysis would at least be interesting.
The category I remember seeing most often was "you have not explained how
this works" - this might be because it was not written clearly enough,
because there were states/events that the WG/author had not described,
because the explanation was in other documents not available to reviewers,
or because the WG had chosen to ignore that particular issue in the
document - sometimes because the WG had failed to get consensus on it, and
preferred to paper over the issue by not mentioning it.
In at least one case I remember, my DISCUSS saying "I don't see how this
works" resulted in a technical change in the document; the WG effectively
said "No, we don't see how this can work either - we'd better decide".
I don't remember many recent DISCUSSes based on a fundamental design issue;
the perception that protocols with fundamental design problems (like
"broken security") would not pass the IESG might be a reason for the lack
of such DISCUSSes - putting the quality input where it should be (in the
WG), but enforced by a strong end-game filter function (in the IESG).
And that's a Good Thing.
But - I don't remember all DISCUSS texts.
Harald
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Re: Review panel's role
Dear Harald, I agree, with one edit - s/to WG/to WG early in the process/. (note is long - summary: Review panel SHOULD, in my opinion, be able to send back documents to WG without it being a Big Deal. At least once.) The part where I stroke out about us continuing to think that documents coming to a Full Stop in the IESG, or in the SRP, being the common path we optimize for is that the Review Panel, as described in the current draft, is a LATE review entity, and we don't like late surprises (for example, the words "guess again" when the WG thinks it's through). I honestly hope the SRP spends some time spinning up an ICARish mechanism for EARLY review, and that the SRP spends its time reading reviews from ICARish reviewers that say, "these guys used to be idiots, but they've gotten a LOT smarter - please check the 02 and 04 text in section 6.3 for proof". And the SRP can spend its time spot-checking drafts that have been seriously CARDed (in the SIR sense), and adjourn early to the bars. And what a wonderful world that would be... Spencer ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: "The IETF has difficulty solving complex problems"
Dear Scott, could we phrase it differently? I submit that we could qualify (along with your own wording) "complex" changes as bringing a "revolution". In that case the problem becomes simpler: to try to tink if there is a way to make the "revolution" a simple "evolution". I will take an example. The Internet faces balkanisation. Balkanisation results from the unsatisfied general need for partitionning. Sovereignty, multilingualism, bandwidth management, risk containment, etc. call for it. Let analyse what is partitionning: it is to change the Internet architectural default parameters from "mono" to "multiple" (one single DNS, one single governance, one single IANA, one language, one ASCII, etc.) while staying homogenous and preserving end to end interoperability. Once you have accepted that, partionning is no more a "revolution" IETF cannot tackle and a balkanisation a fate to be accepted. This is only a parameting "evolution" to work on (and test) which will permit the huge added value of a stable, consistant, secure, simplicity, innovative, end to end respectful compartmentailisation. Just beware: before every ship on earth is compartmentatilised for security and strenght, we known the Titanic case. Experimentation is such needed before we can fully use externets (compartimented external networks look-alike), "the _usage_ networks _within_ the network of the logical and physical networks". Today, I do not know anything the IETF cannot cope with. Except accepting RFC 1958 principle that there is only one thing which will not change: that everything may change. And that architecture comes before painting :-). Even ways to get funded while staying protected from commercial funding implications (RFC 3869) could be achieved. jfc At 07:05 04/08/2005, Scott W Brim wrote: This conjecture was disturbing, but calling it a feature was even more disturbing. After a bit of pondering, and wondering what different groups in the IETF might mean by "complex", my first thought was that the IETF has never, ever solved one. For example, we do QoS in small pieces that don't fit together well. Some claim that CIDR was such a solution but imho it was just a tweak on what we already had. Our routing protocols have been fertile ground for evolution but not revolution -- the path vector idea came directly from deprecating EGP "metrics", we still aren't very stable and our policy capabilities are frustrating. However, after talking to a few people I thought that perhaps we are very good at solving complex problems but we don't recognize our greatness. Again let me take QoS as an example. The problem is huge and essentially intractable because of all the competing goals. What we have done, without a lot of architectural planning that I am aware of, is to find ways to divide the problem up where there is minimum coupling across the boundaries (see footnote (*)). That lowers the complexity greatly. It is a lot cheaper to have independent, apparently "unarchitected" solutions for different kinds of traffic and situations. I want us to understand what our skills are and use them consciously. I don't know if we will have time tonight, but I'd like to hear from the IESG/IAB on the foundation for Brian's statement and what was initially a negative assessment of our skill. Let's look at some example problems and think about what we have done poorly and well. I predict we are better than we think, but that we are hard to satisfy. We may think of some of the things we have done as crude hacks but they are actually pretty good solutions. Look at tunnels, for example. They are kind of abhorrent when thought of in isolation but turn out to be an appropriate means to reduce complexity in specific situations. Reducing complexity through cutting up the problem at the right points is implicit now. We could make it one of our explicit basic paradigms. As a corollary to making it explicit, we should be aware of where we use this kind of decoupling and be vigilant about it. Some users of the IETF "product set" want to reintroduce coupling that we have eliminated. Be sure the trade-offs are explicitly examined. swb (*) like Chuang Tzu's butcher ... "The joints have openings, And the knife's blade has no thickness. Apply this lack of thickness into the openings, And the moving blade swishes through, With room to spare! ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Review panel's role
In message <[EMAIL PROTECTED]>, "Spencer Dawkins" writes: >Hi, Pekka, > >I rarely if ever argue with you about protocol stuff, because you're >pretty good at protocols, and our process IS a protocol, but I do see >"returned to clear DISCUSS" items on the IESG telechat agendas. So, I >bet you're right, but there is running code that we actually DO end up >sliding to the next telechat, at least some of the time. > I think the detailed minutes will clarify this, but there's no one answer. Often, the DISCUSSing AD will clear a DISCUSS offline, in which case things proceed on request of the sponsoring AD. This is often the case for relatively simple issues, especially when dealt with promptly. If a document takes a while to come back, or if the changes are complex, it can be returned to the agenda so that the changes can be, well, discussed. Maybe the objecting AD isn't happy enough, but the sponsoring AD thinks they might be persuadable by the other ADs. That's been known to happen. A document with multiple substantive DISCUSSes often comes back, because the changes can be interdependent. Finally -- and this is painful -- sometimes the objecting AD doesn't respond to private requests to clear a DISCUSS. Putting the document on the agenda is a forcing function. This last one shouldn't happen, but it does. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
work on diagnostics
Re the plenary thread now on user experience, and the apparently related topic of diagnostics, folks might be interested in some R&D done in Internet2 on "end-to-end diagnostics": http://middleware.internet2.edu/e2ed/ NSF funded this work because of the observation that many of the programs they fund develop and deploy network-dependent distributed applications, which typically end up being hard to diagnose, ultimately affecting the science and the scientists. I have to say the experience of the folks doing this work was that despite everyone appreciating the importance of the topic, it's hard to get anyone (users or developers) very interested in diagnostics ... so if anyone wants to follow up with them I'm sure they'd appreciate it. - RL "Bob" ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
IETF Chair, General Area, process and complexity
Hi, in John's formulation, the process work of the general area withers away - or at least moves to a different corner of the world. so what happens to the general area? one suggestion is to axe it. my suggestion would be for that role to be staffed by a generalist who is comfortable with complexity in its many network manifestations. this area could then house those groups that need to deal with complex issues that now often get force fit into the more specific areas. a. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: "The IETF has difficulty solving complex problems"
> This conjecture was disturbing, but calling it a feature was > even more disturbing. After a bit of pondering, and > wondering what different groups in the IETF might mean by > "complex", my first thought was that the IETF has never, ever > solved one. For example, we do QoS in small pieces that > don't fit together well. Some claim that CIDR was such a > solution but imho it was just a tweak on what we already had. I think that it is fairly apparent that every institution has great difficulty solving complex problems. But what seems to be the real topic of discussion here is the difficulty of establishing an overaching architectural vision. This is a difficult challenge in any context, individuals who are capable of articulating such a vision are very rare, they are the type of people who are in the running for the Turing award. But even then only some of the Turing award winners/contenders I have worked with are capable of such an overarching vision. Another problem is that in the institutional context past success is frequently the cause of continuing falure. When Walt Disney ran his studio the animators never used story boards. This tradition was carried on for almost 20 years after Disney died but none of the cartoons produced as a result became classice. One of the first changes Eisner made was to introduce storyboards. After talking to the old timers he realized that Walt had always used a story board but he kept it in his head. The problem with continuing the legacy of people like Vint Cerf, Bob Metcalf, David Clark, Jon Postel is that the problems that we face today tend to be the very ones that require changes to the original overarching pronciples to be considered. To take an example from the security world, the security problems that can be solved through the end to end principle have already been solved using it. What we now face are the problems that require exceptions. The 80/20 rule is a good one, the problem is that when the 80% is solved the original triage now works against you. If you do not consider a change of approach when you come to the 20% you will have problems. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: "straightforward, reasonable, and fair"
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Keith Moore > or for that matter _Atlas Shrugged_? (not that I agree with Rand on > everything, but she had this one pegged) I beg to differ, the Middle ages demonstrated amply that the vast majority of the populace are not going to complain if Atlas decides to take a break. If Atlas expects gratitude then more fool him. Today there are plenty of people who are pretty much demanding that Atlas take a break and they show absolutely no sign of being concerned about any consequences, nor do they display any capability to recognize those consequences already apparent. If Atlas refuses to take a break some of them are quite prepared to murder him the way the Atheneans murdered Socrates. I have no problem with placing the onus on those making a proposal to pursuade the IESG that the proposal is understood and articulated in a coherent fashion. I do have a problem when the pushback is of the form 'I have a bad feeling about this' with no further explanation or 'I want you to cast this proposal in a form that promotes deployment of my pet project'. Where I do have a very serious problem is when dealing with a WG chair who is clearly using his position to promote his own predjudices above the group consensus. As a matter of practical experience this situation cannot be dealt with when a WG chair is also an AD, even if in another area. The AD of the Chocholate area is not very likely to remove a WG chair who is also the AD of the Strawberry area. Doing so is going to make is much more difficult for Chocholate AD to work with the Strawberry AD on the IESG in a collegial manner. I think that there needs to be an explicit prohibition on ADs also being WG chairs. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
IETF Meeting Wiki (Was: Re: Completely out of scope: Restaurant reccomendation)
I've received about 10 positive and 1 negative comments to the idea of the tools team providing a meeting Wiki. Accordingly, a Wiki is now available from the prototype tools menu at the top left of http://tools.ietf.org/ . Welcome to fill it with content! Henrik on 2005-08-02 19:44 Henrik Levkowetz said the following: > Sounds like something the Tools Team could provide. Should I set up > one? > > Henrik > > On 2005-08-02 11:13 Clint Chaplin said the following: >> So, who is going to volunteer to set up said wiki? I'm not >> technically proficient >> >> On 8/2/05, Olaf M. Kolkman <[EMAIL PROTECTED]> wrote: >>> >>> >>> PS. Somebody suggested that it would be nice to have a meeting Wiki >>> for recommendations on restaurants, stories about pickpockets, and >>> other non process and non technical cruft. signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
