Re: improving WG operation
--On May 1, 2005 9:04:12 AM -0700 Dave Crocker [EMAIL PROTECTED] wrote: in general I think the issue is stricter meeting planning and management, where the goals and process are more explicit. Sorry for coming very late to this discussion. I might suggest scheduling a (preferably voice) conversation between the AD and the chairs of each working group before an IETF meeting to discuss the issues and objectives surrounding the next wg meeting. I'm finding that voice chats with IRTF RG chairs have been very useful for me to sync up on the RG activities and to give some nudges on moving forward. --aaron ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: a way toward homograph resolution ? (was improving WG operation)
This cacologic however might be a good way to solve the IDN homograph issue and the phishing problem. I have been spending most of my time on the phishing problem for three years. I have yet to see a phishing gang use the DNS IDN loophole for a phishing attack. This is probably because the issue was an administrative one, the cert should never have issued and in the wake of the paper the CAs I have talked to have all corrected the issue. The lookalike DNS name problem was known before the design of SSL started, remember Micros0ft.com? Today the phishing gangs use bigbank-security.com or bigbank-corp.com or something similar. They are not going to use IDN DNS names until the application support is much much more comprehensive by which time the strategy will have changed. So in summary no, 'solving' the homolog issue is irrelevant to current phishing issues and by the time it is relevant I hope that we would no longer think it is a good idea to try to train users to recognise DNS or X.500 names as security indicata. We need to make security much more informative and usable if we want it to be used. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: improving WG operation
Tom Wouldn't a system of mutual endorsements (a web of trust), Tom suitably loudly broadcast, be an alternative to elaborate Tom committee procedures? Yes, but it would not really be the IETF. There's IETF in theory and IETF in practice. Also note that I believe that a discussion of whether this alternative is a good idea should probably move off the ietf list fairly quickly. I agree. As I said, I'm trying to strongly tend to return to my seat. I object to the implied assertion that IETF *couldn't* go in this direction and remain IETF. As I also said: I think this time in history is a unique opportunity to do so. I'm mostly repeating myself, so: thanks for listening. -t ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: improving WG operation
But if you aren't interested, why are you here? What's your interest? I don't understand your point. Are you here to convince the rest of us that the IETF is irrelevant? Absolutely not. Nearly the opposite. I hope that if you look back at some of my other messages in this thread that's clear. You're complaining that some application-layer stuff like IM isn't as orderly as you'd like. Disorder isn't good for the users, either. Its not just a personal view of orderliness. And it isn't good for the market to have such unnecessary and gratuitous disorder. That's why standards of any form exist. I'm not so sure IETF can help user's other than by producing very good, easily accessed documents with available reference implementations. An endorsement/trust-based system for calling attention to good standards seems like all you've ultimately got -- why not institutionalize *that*? Why *isn't* the rest of the governance simply noise? Why *isn't* the rest of the governance simply a game a professional organization has agreed to play that will ultimately turn it into just another consortium? Isn't the rule-mongering just a very indirect attempt to find rules that coincidentally create the effects an endorsement/trust system would render in a more naked form? What's the value add of anything beyond an endorsement/trust system? My answers to those questions are clear and that's why I say: strike while the iron is hot -- while there are still recognizable names who roughly essentially deserve trust? -t ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: improving WG operation
On Tue, 10 May 2005, Tom Lord wrote: But if you aren't interested, why are you here? What's your interest? I don't understand your point. Are you here to convince the rest of us that the IETF is irrelevant? Absolutely not. Nearly the opposite. I hope that if you look back at some of my other messages in this thread that's clear. You're complaining that some application-layer stuff like IM isn't as orderly as you'd like. Disorder isn't good for the users, either. Its not just a personal view of orderliness. And it isn't good for the market to have such unnecessary and gratuitous disorder. That's why standards of any form exist. I'm not so sure IETF can help user's other than by producing very good, easily accessed documents with available reference implementations. The IETF doesn't produce documents that are meant to be accessible to users. Nor does it produce reference implementations. IETF documents are meant to be accessible to engineers and operators, creating and running interoperable services of various types. One and possibly two implementations are usually required for a standard to be acceptable. The point of this is to require that specifications be both implementable and complete. An endorsement/trust-based system for calling attention to good standards seems like all you've ultimately got -- why not institutionalize *that*? The trust-based system we have has a track record of obtaining good specifications. We have institutionalized that, vaguely though it might be. This doesn't mean this process can't be improved, nor that it shouldn't be critically examined. But I don't see that this has anything to do with calling attention to good standards. The IETF has no marketing or promotion department to call attention to anything it does. It is all through word of mouth and the interaction with participants. I don't think such a department is necessary. Why *isn't* the rest of the governance simply noise? Why *isn't* the rest of the governance simply a game a professional organization has agreed to play that will ultimately turn it into just another consortium? Isn't the rule-mongering just a very indirect attempt to find rules that coincidentally create the effects an endorsement/trust system would render in a more naked form? What's the value add of anything beyond an endorsement/trust system? My answers to those questions are clear and that's why I say: strike while the iron is hot -- while there are still recognizable names who roughly essentially deserve trust? I'd offer one point: Name recognition has nothing to do with trust. In the past few years, we've seen some very recognizable and previously highly trusted names turn out to be untrustworthy in a number fields, endeavors, and organizations. Whether someone is still trustworthy is also something that needs to be critically examined now and again. An organization's trust assets only remain assets if they remain trustworthy. Trusted staff isn't the only thing going for the IETF, but it is a critical component. But untrustworthy staff can be replaced without damage so long as they are replaced promptly. It is usually delay in replacement of trusted staff that creates the most damage for organizations that depend on trust. So far as striking while the iron is hot, well, urgency is usually and historically a sign of weak technical arguments that won't hold up to careful and critical scrutiny. There is nothing here that needs attention so urgently we can't analyze the problem and the proposed solutions. So far as I am aware, in _every_ case where urgency was cited as a reason for foregoing analysis, it has been found both that there wasn't any urgency, and that the proposal was seriously flawed. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: improving WG operation
On 22:45 10/05/2005, Dean Anderson said: The IETF doesn't produce documents that are meant to be accessible to users. Nor does it produce reference implementations. IETF documents are meant to be accessible to engineers and operators, creating and running interoperable services of various types. One and possibly two implementations are usually required for a standard to be acceptable. The point of this is to require that specifications be both implementable and complete. Dean, the IETF users are the ones who use the IETF deliverables. And the Internet is made of the adherence to these deliverable (which do not make the best documentation around). So, you cannot know or decide who will be the users. (may be you refer in your mind to end users? There are none on the Internet because it is not a centralised network. Just remember that Internet users have designed P2P, VoIP, NATs, etc. for some and that others have more processing and communication powers than the whole ATT 20 years ago) and you never know who will need what (even if 99.99% will never read an RFC, they will all read RFC quotes and they must be clear and consistent with what their consultant, their ISP, their operator will tell them). What I mean is there is no Internet gnosis, there should only be an Internet gospel. There is no shame in it, but the IETF mechanic seems to be more: - a user comes with a working project - IETF starts maintaining it and documenting it what helps its integration and scalability - if the whole common thing is accepted and works it can become a standard. jfc ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: improving WG operation
On 01:50 11/05/2005, Hallam-Baker, Phillip said: Just remember that Internet users have designed P2P, VoIP, NATs, etc. for some and that others have more processing and communication powers than the whole ATT 20 years ago) and you never know who will need what (even if 99.99% will never read an RFC, they will all read RFC quotes and they must be clear and consistent with what their consultant, their ISP, their operator will tell them). What I mean is there is no Internet gnosis, there should only be an Internet gospel. Exactly, do I have to send an engineer to every IETF WG meeting just to make sure that they don't decide to delete some feature of some protocol that I am depending on? They do not not only delete. I suggest you just come to the WG-ltru where they have decided to document RFC 2277 charsets into RFC 3066 langtags. So you can enjoy charset conflicts, something you never though about, I presume. You cannot stop progress. jfc ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: improving WG operation
Hi - From: JFC (Jefsey) Morfin [EMAIL PROTECTED] To: Hallam-Baker, Phillip [EMAIL PROTECTED] Cc: ietf@ietf.org Sent: Tuesday, May 10, 2005 5:29 PM Subject: RE: improving WG operation ... They do not not only delete. I suggest you just come to the WG-ltru where they have decided to document RFC 2277 charsets into RFC 3066 langtags. So you can enjoy charset conflicts, something you never though about, I presume. You cannot stop progress. ... I guess Jefsey is upset because the WG rejected his proposal to expand our scope to include charsets. The ltru WG is most emphatically *not* confusing charsets with language tags. Randy, ltru co-chair ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
a way toward homograph resolution ? (was improving WG operation)
On 04:43 11/05/2005, Randy Presuhn said: From: JFC (Jefsey) Morfin [EMAIL PROTECTED] To: Hallam-Baker, Phillip [EMAIL PROTECTED] Cc: ietf@ietf.org Sent: Tuesday, May 10, 2005 5:29 PM Subject: RE: improving WG operation ... They do not not only delete. I suggest you just come to the WG-ltru where they have decided to document RFC 2277 charsets into RFC 3066 langtags. So you can enjoy charset conflicts, something you never though about, I presume. You cannot stop progress. ... I guess Jefsey is upset because the WG rejected his proposal to expand our scope to include charsets. The ltru WG is most emphatically *not* confusing charsets with language tags. I am not upset :-). To the countrary I find extremely interesting that some people were able to rename charsets scripts in order to insert charsets into languages descriptions while claiming they dont (cf. above). Obviously they are unhappy when I expose the trick. Anyway the result is great fun: people will be prevented from accessing a page they know to read, if they do not know the language. This cacologic however might be a good way to solve the IDN homograph issue and the phishing problem. If we revert from those famous scripts to what they are, i.e. unicode partitions, hence stable and well documented charsets (http://www.unicode.org/Public/4.1.0/ucd/Scripts.txt) , using them browsers can expose the homographs not related to the page charset in IDNs, and kill the risks of phishing. This only calls for the browsers to extract the charset, I mean the script name from the langtag, call this file, read the list of codes points in the charset/associated to the script, and display the URL accordingly, indicating the characters which are no part of the script/charset. This relieves the ccTLD/TLD Manager from responsibilities he cannot fulfil at 3+level. There are howver still (minor) points to address: - there are some minor disparities between the script name in the langtag, and the script name in the script.txt file should be reduced over time. I suppose that if this is a major issue, there will be help. - the script.txt file is currently supported on the Unicode site. Even in caching it (92 K) it will be called everytime people will start their browser. This may therefore represent several billions of access a day. - the WG-ltru only realy wants to address XML issues, related to old XML libraries. Some coordination with other WGs or interests could be fruitful. They plan the language tags registry to extend to scripts and to register them. I suppose other WGs could benefit from this (all those involved in a way or another with internationalisation and languages). jfc ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: improving WG operation
At 06:24 09/05/2005, Keith Moore wrote: All I mean is that, for higher level protocols, letting people do what they will (the market decides) seems to me to be the best option. there are cases when this is true. I don't think the cases are as simply described as higher level protocols or applications. Unfortunately never true with IANA. Once a registry is set-up it prevents a better one to address the same topic, even if disregarded by most of the users it will be used by some and will stay around. That will make up-grading its legacy a huge amount of convincing and probably years of delays for the market. jfc ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: improving WG operation (was Re: Voting (again))
Jari Arkko wrote: Hi Keith, Keith, you have been advocating a model where the IETF would be stricter in allowing what work be taken up, in order to ensure that we can actually deliver. But I share the same opinion as John L that we should rather try to shape the IETF so that it can deliver what the world needs. My primary criterion when arguing whether IETF should or should not take up a WG was always, in some sense, whether the Internet needed IETF to be involved in and supporting this effort. It involved both an assessment of how much harm would result from a botched design (in particular, a design that didn't respect the Internet environment and other protocols on the net), and of whether IETF could expend the resources necessary to manage the group and whether it could bring the necessary expertise to the table. It also involved an assessment of whether the proposed protocol would actually be of benefit to the Internet long-term. All good criteria! I would probably add assessment of whether lack of the protocol would be of harm to the Internet long-term (assuming the protocol falls within our scope, as you correctly point out below). Here's an example: a protocol that is within IETF scope, but we suddenly stop maintaining it to respond to changing requirements, or open it up to vendor extensions without providing good abstractions that maintain interoperability. This is very close to the IESG's thinking about what we should and shouldn't charter. The yardstick is RFC 3935. We can always make mistakes, of course, and we need to think about what work is being done by other organisations. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Take it to the list [Re: improving WG operation]
(catching up on old stuff) Eliot Lear wrote: Margaret, The words I hate most when I am in a WG meeting are these: take it to the mailing list That is usually short for we can't agree in person so we'll now continue to disagree by email. Sometimes it's short for We are out of time. In fact, I think that's the common case. Other times it's We here today can't form a consensus, but in the IETF consensus is formed on the list anyway, so let's try that way when we've all had time to think. Debate has been shut off, and usually prematurely because there is something else on the agenda. I'd rather that never happen. Yes, but it is bound to happen, unfortunately. I think it's fair to specify the parameters for a decision Even that may be non-trivial. But I agree, if it can be done in the time available, it should be. and then go to the mailing list so that people could evaluate different solutions based on those parameters, but simply blowing off a topic because the group cannot agree is a failure of leadership. I think it's rare; do you think it's frequent? Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: improving WG operation
A slight mod: The best technology doesn't always win: engineers don't always solve the right problem. Sometimes I think the IETF is making the tools (a.k.a - protocols) that make the Internet run. Sometimes the market doesn't want the tool that we made, or needed a took sooner than we could produce one. John The good thing about mobile email is that t9 forces you to be brief. --- original message --- Subject:Re: improving WG operation Sender: Sam Hartman [EMAIL PROTECTED] Date: 05/09/2005 2:44 am Tom == Tom Lord [EMAIL PROTECTED] writes: Tom All I mean is that, for higher level protocols, letting Tom people do what they will (the market decides) seems to me Tom to be the best option. Yes, using your example, IM protocols Tom fragment, interop suffers, there's lots of crap --- so what? I think our concern is that we have finite resources here in the IETF. If you want a market decides standards, go set up an industry consortium or go to a market decides standards body. The IETF works best when people bringing technologies to it buy into the idea of building rough consensus. So, if you want the market to decide, and you don't have a particularly good reason for being at the IETF, perhaps we're not the best place for you to do your work. One obvious question to ask is whether the IETF still has work to do and is still the right place for anything. My answer is simple: let the market decide;) ___ 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: improving WG operation
I'm not sure who said: I think our concern is that we have finite resources here in the IETF. If you want a market decides standards, go set up an industry consortium or go to a market decides standards body. The IETF works best when people bringing technologies to it buy into the idea of building rough consensus. My hypothesis is that (at today's scale of operation) tweaking governance does not contribute to building concensus: governance creates contention. Regarding IETF as a professional organization rather than an industry consortium: when the governance question gets hot, that seems to me to lead inevitably to turning the professional organization into a de facto consortium when industrial/governmental/NGO players start spending resources in efforts to dominate it, interrupt it, etc. The alternative to governance that I see is investment in communications and trust building. In one scenario: Alice working in her shop devises and implements a new protocol that she would like to share and see implemented elsewhere. The essential steps that seem to help are that Bob, Candice, and Dave -- all recognized, leading professionals with clearly contained and monitorable conflict of interest issues -- carefully review, comment on, and help refine her work. Also that the attention of potential implementors is drawn to this effort. Finaly that any party can observably endorse or object to the effort. For that scenario, the actions of Alice, Bob, Candice, Dave and potential implementors are entirely voluntary. It wouldn't matter if Esther, Fred, and Grace are trying to throw rocks, as one person put it -- the cooperators have their own little moderated mailing list and how much more than that, really, is necessary? Aside from the most basic of protections against process spam, *anyone* should be able to record their spec and call it a standard. The interesting questions all have to do with who agrees? and, for those questions, no central governance seems either necessary or helpful. Wouldn't a system of mutual endorsements (a web of trust), suitably loudly broadcast, be an alternative to elaborate committee procedures? Wouldn't that allow at least the more careful consumers for these documents to decide, individually, what kind of rough concensus, if any, has been reached? This would eliminate the IETF tag on a spec as a branding/marketing tool but that just seems to me to be a return towards being pragmatically realistic. In some sense, all working groups could be understood as voluntary associations. Such associations could happen anywhere. The values added by coming together under the IETF umbrella seem to me to be that many people watch this central communications hub and that, at least at this point in history, a subset of participants are clear thought-leaders whose endoursement carries a merit-based weight. If IETF continues down contentious paths, the value of clear thought-leaders will fade amidst the noise. Therefore, it seems to me, we are at a unique point in history where a shift to a system based more on a web-of-trust approach is both an option and a potential solution to a present problem. -t ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Take it to the list [Re: improving WG operation]
On Mon, 9 May 2005, Brian E Carpenter wrote: (catching up on old stuff) Eliot Lear wrote: Margaret, The words I hate most when I am in a WG meeting are these: take it to the mailing list That is usually short for we can't agree in person so we'll now continue to disagree by email. Sometimes it's short for We are out of time. In fact, I think that's the common case. Other times it's We here today can't form a consensus, but in the IETF consensus is formed on the list anyway, so let's try that way when we've all had time to think. Sometimes I have come to treat take it to the list as: we don't seem to have enough people in the room that actually care about this, as nobody comes to say anything on the mike. We'll just put the document (or the issue) on the pending list until anyone gets interested on the list, or until the next meeting when we'll have this discussion again. Yeah, that's a problem, but it's not clear which is better: the chairs more aggressively pursuing a timeliness (even though sufficiently many people don't seem to be paying attention or voicing strong opinions) so that issues or documents can be finished, or intentionally delaying work which hasn't garnered sufficient momentum (or the momentum has been lost). My personal take is that it's very important to finish the work that has been started on a timely fashion, but we might be more strict on accepting new work if we see a loss of interest. -- 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: improving WG operation
Tom == Tom Lord [EMAIL PROTECTED] writes: Tom Wouldn't a system of mutual endorsements (a web of trust), Tom suitably loudly broadcast, be an alternative to elaborate Tom committee procedures? Yes, but it would not really be the IETF. Note well that I'm not making any judgment of quality on how good an alternative it would be; I have not carefully considered the issue. Also note that I believe that a discussion of whether this alternative is a good idea should probably move off the ietf list fairly quickly. Tom Wouldn't that allow at least the more Tom careful consumers for these documents to decide, Tom individually, what kind of rough concensus, if any, has been Tom reached? Possibly; that's not clear to me. --Sam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: improving WG operation
On Sun, 8 May 2005, Sam Hartman wrote: Tom == Tom Lord [EMAIL PROTECTED] writes: Tom All I mean is that, for higher level protocols, letting Tom people do what they will (the market decides) seems to me Tom to be the best option. Yes, using your example, IM protocols Tom fragment, interop suffers, there's lots of crap --- so what? I think our concern is that we have finite resources here in the IETF. If you want a market decides standards, go set up an industry consortium or go to a market decides standards body. The market always decides. And people will always do what they will. If you want different standards, you can always go to another standards body. There are many to choose from. However, before the market can decide, standards must be chosen, and put forth. Standardizing what the big vendors want isn't really standardization. That's just rubber-stamping a big vendor. Since the big vendors can create their own defacto standards without the need for rubber stamps, such groups tend not to last too long. There may indeed be improvements to the IETF process, but the fundamental ideas have worked reasonably well, and radical divergence isn't necessary. It is sign of good health that people are seeking improvements. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: improving WG operation
On Sat, 7 May 2005, Tom Lord wrote: it's not that cut-and-dried. it can be very costly to users to let the market decide. sometimes the market doesn't decide, it just fragments. So? so let the market decide is a lousy rule. there's no justification for it. it's just the sort of thing that someone says when he fears competition from a better product. I agree with Keith. But how about: So... We all work very hard to create standards using a vendor-neutral, open process that work for many parties, not just a single vendor The original focus of IETF was to create and firm-up the Internet. That war was won. The internet evolves. New standards are created. Old standards are modified. That process doesn't stop. But if you aren't interested, why are you here? What's your interest? I don't understand your point. Are you here to convince the rest of us that the IETF is irrelevant? The IETF will end when people lose interest in its works. You're complaining that some application-layer stuff like IM isn't as orderly as you'd like. Disorder isn't good for the users, either. Its not just a personal view of orderliness. And it isn't good for the market to have such unnecessary and gratuitous disorder. That's why standards of any form exist. I don't see the connection between your complaint and the original focus. Now, refining a few core protocols -- that'd be great. Trying to be the government of all protocols -- huh? The SRFI process, in the world of Scheme programming, seems to me the more utilitarian approach to working on higher-level protocols: there's nearly nothing to fight over in that process. I suspect that the architecture of Scheme and Lisp has a lot to do with this. You have a few core language constructs and everything else is built on top of that. Try to take away CAR or CDR and you'd have big problems with consensus, I suspect. Better examples is the Common Lisp/Scheme schism. There can easily be many languages, but its harder to say there will be multiple BGP or TCP variants. Some order, beyond the you're welcome to create a code fork is necessary when you have different pieces of hardware that have to interoperate. A program only needs its particular runtime, and we can easilly have many runtimes for different languages. If you were making scheme/lisp hardware, there would be more concern about the compatibility of language primitives. (Didn't we already have this battle with LMI and Symbolics?) So I don't think the Scheme programming analogy works. But I agree that the consensus is a vague term. Most of the people who don't like it are the ones where the consensus didn't go their way. In any specific case, its hard to tell whether they have a valid complaint or not. I agree that's a problem. And partly because the definition and determination of consensus is so vague, there is sometimes genuine cause for suspicions about motives, politics, and such. However, putting together a simple voting process won't work either. Like democracy, its just about the worst thing there is, except for the alternatives. So I think collective judgement by the WG chairs and the IAB is the only way. I think trustworthy and honest WG chairs and IAB members are critically important, and a fair complaint resolution process is also important. -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: improving WG operation
it's not that cut-and-dried. it can be very costly to users to let the market decide. sometimes the market doesn't decide, it just fragments. So? so let the market decide is a lousy rule. there's no justification for it. it's just the sort of thing that someone says when he fears competition from a better product. The original focus of IETF was to create and firm-up the Internet. That war was won. You're complaining that some application-layer stuff like IM isn't as orderly as you'd like. I don't see the connection between your complaint and the original focus. Now, refining a few core protocols -- that'd be great. Trying to be the government of all protocols -- huh? The SRFI process, in the world of Scheme programming, seems to me the more utilitarian approach to working on higher-level protocols: there's nearly nothing to fight over in that process. -t ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: improving WG operation
so let the market decide is a lousy rule. there's no justification for it. People should generally reject religious fundamentalism, including what you said there. If you have an a priori case for this or that, fine, but you seem to be making a mystical argument for a wildly generalized claim. -t ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: improving WG operation
The original focus of IETF was to create and firm-up the Internet. That war was won. You're complaining that some application-layer stuff like IM isn't as orderly as you'd like. I don't see the connection between your complaint and the original focus. Even if that was the original focus, I don't think it is relevant any longer. I've been around IETF for 15 years and that has never been IETF's focus within that time. That doesn't mean the organization is nearing end-of-life, it means that as the Internet has changed, so has IETF. Now, refining a few core protocols -- that'd be great. Trying to be the government of all protocols -- huh? The IETF never has tried to be the government of all protocols. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: improving WG operation
so let the market decide is a lousy rule. there's no justification for it. People should generally reject religious fundamentalism, including what you said there. If you have an a priori case for this or that, fine, but you seem to be making a mystical argument for a wildly generalized claim. for some, let the market decide is a religious statement. it's generally based on an unexamined faith in market conditions as an effective way of making a good choice among competing technologies. there are cases where letting the market decide makes sense - but it's easy to find several cases where this is not so, and difficult to generally outline the set of cases where the rule does apply. there's no justification for citing let the market decide as a general rule, not even for applications, because there are too many cases where application functionality is severely compromised by poor market decisions. (which design shall we use for a bridge to cross the river between these cities? let's let the market decide!) the other justification for let the market decide is when the speaker believes that his financial interests will be better served by letting the market decide than in the absence of input from IETF, than by letting the market take such input into account. ultimately, the market decides in either case. the real intent of let the market decide within IETF is to try to keep individuals within IETF from influencing the market. the speaker presumably believes that the market will make a more favorable decision (for him) without IETF's input than with IETF's input. the speaker may hope that by exploiting some people's misguided faith in market conditions, and exploiting the tendency of the market to make poor decisions, he can silence those who would propose a better way to do it. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: improving WG operation
for some, let the market decide is a religious statement. it's generally based on an unexamined faith in market conditions as an effective way of making a good choice among competing technologies. I don't accept the ideological case for or against free markets. My point here is limited to the case in which a working group is unable to come to consensus over two disjoint proposals and each group refuses to compromise with the other. Agreement would certainly be the best outcome in the case where the differences are due to personality issues. But there are also cases where one proposal is in fact distinctly inferior, usually because the adherents are bought into some obsolete dogma or other. For example there is no way to negotiate a compromise between die hard adherents to the end-to-end security primciple and proposnents of an edge based security system. The two architectural views are entirely incompatible and cannot possibly be reconciled. What I have observed in these divisions is that it is actually quite rare to have two factions of implementers. What is much more common is that you have a group of folk who are building something and another group of rock throwers who won't build much more than a bunch of prototype code that only worksw with their own system. In other words letting the market decide comes down to who has the best code and the best deployment strategy. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: improving WG operation
From: Keith Moore moore@cs.utk.edu so let the market decide is a lousy rule. there's no justification for it. People should generally reject religious fundamentalism, including what you said there. If you have an a priori case for this or that, fine, but you seem to be making a mystical argument for a wildly generalized claim. for some, let the market decide is a religious statement. it's generally based on an unexamined faith in market conditions as an effective way of making a good choice among competing technologies. For some it may be so (I agree) but apparently not you are I. All I mean is that, for higher level protocols, letting people do what they will (the market decides) seems to me to be the best option. Yes, using your example, IM protocols fragment, interop suffers, there's lots of crap --- so what? It looks like it will probably sort out. Fretting over how best to impose governance over the situation doesn't obviously accomplish anything. There are faster, better, cheaper ways I think to get universally adapted standards in motion than wrangling with committees. The main practical utility of standards very high in the stack is that they are written clearly, widely reviewed, and generally agreeable to people. One doesn't need a complicated government to support the development of standards with that utility: a few mailing lists and archives do most of the trick. Processes in which there is nothing available to fight over seem like the most efficient to me. That this kind of anti-process process is even an option is a tribute to the historical success of IETF but it would be weird to postulate a need for IETF to do much more than what's already been done, imo, other than to maintain the lower layers. Surely there are grey areas but those don't strike me as obviously IETF's business. For example, since IM is used in life-critical applications, regulation may be in order -- but that's not a good role for IETF either. It's swell to have leading experts advise regulation but having that occur via IETF adds no value (and costs efficiency). the speaker may hope that by exploiting some people's misguided faith in market conditions, and exploiting the tendency of the market to make poor decisions, he can silence those who would propose a better way to do it. You are absolutely right, imo, that jerks regularly try the trick that you describe and that that's a serious problem that deserves attention. It's the conclusions you draw from that that I don't quite get. Anyway, thank you for the uptake and I am starting to feel overextended on my justification for posting to this list so, while I'm not against replying further -- I'll be tending to return to my seat now. -t ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: improving WG operation
Tom == Tom Lord [EMAIL PROTECTED] writes: Tom All I mean is that, for higher level protocols, letting Tom people do what they will (the market decides) seems to me Tom to be the best option. Yes, using your example, IM protocols Tom fragment, interop suffers, there's lots of crap --- so what? I think our concern is that we have finite resources here in the IETF. If you want a market decides standards, go set up an industry consortium or go to a market decides standards body. The IETF works best when people bringing technologies to it buy into the idea of building rough consensus. So, if you want the market to decide, and you don't have a particularly good reason for being at the IETF, perhaps we're not the best place for you to do your work. One obvious question to ask is whether the IETF still has work to do and is still the right place for anything. My answer is simple: let the market decide;) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: improving WG operation
Hallam-Baker, Phillip said: for some, let the market decide is a religious statement. it's generally based on an unexamined faith in market conditions as an effective way of making a good choice among competing technologies. I don't accept the ideological case for or against free markets. My point here is limited to the case in which a working group is unable to come to consensus over two disjoint proposals and each group refuses to compromise with the other. Agreement would certainly be the best outcome in the case where the differences are due to personality issues. But there are also cases where one proposal is in fact distinctly inferior, usually because the adherents are bought into some obsolete dogma or other. For example there is no way to negotiate a compromise between die hard adherents to the end-to-end security primciple and proposnents of an edge based security system. The two architectural views are entirely incompatible and cannot possibly be reconciled. actually I disagree with you on that point (I agree with most of the rest of the above). there is at least sometimes a role for perimeter-based security in addition to end-to-end security. the trick is to understand the strengths and weaknesses of each as they apply to a realistic threat model, not to assume a priori that either one can exclusively do the job. in my experience the disagreement between die hard adherents usually amounts to an underlying disagreement about the threat model - where both sides may have oversimplified it. What I have observed in these divisions is that it is actually quite rare to have two factions of implementers. What is much more common is that you have a group of folk who are building something and another group of rock throwers who won't build much more than a bunch of prototype code that only worksw with their own system. yes, but often this is because it's much easier to build something that implements a naively simple version of a protocol than to design and implement a protocol that will actually work well in a realistic range of scenarios that will be encountered in wide-scale deployment. that's why running code by itself isn't worth much anymore. In other words letting the market decide comes down to who has the best code and the best deployment strategy. depends on what you mean by best. if you mean the strategy that gets a lousy product out into the market in the shortest amount of time and attempts to lock in customers, you're right. if you mean the strategy that provides the most long-term benefit to the community, you're wrong. there's no substitute for engineering. we would never consider building a bridge, building, ship or large aircraft, without careful understanding of the problem to be solved, multiple design/analysis/feedback cycles, etc. the investment in these is quite obviously so great that we want to minimize the potential to invest that much in a poor design. and yet protocol designers will happly invest similar sums - or even more - of their customers' money in poor designs. of course, sooner or later the market will probably figure out that investing money in half-baked protocols or implementations of those protocols is a poor idea. the market does learn, it just takes so long to do so that its errors are very expensive for everyone. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: improving WG operation
People should generally reject religious fundamentalism, including what you said there. If you have an a priori case for this or that, fine, but you seem to be making a mystical argument for a wildly generalized claim. for some, let the market decide is a religious statement. it's generally based on an unexamined faith in market conditions as an effective way of making a good choice among competing technologies. For some it may be so (I agree) but apparently not you are I. All I mean is that, for higher level protocols, letting people do what they will (the market decides) seems to me to be the best option. there are cases when this is true. I don't think the cases are as simply described as higher level protocols or applications. it depends, for example, on whether competing apps interfere with each other or with other valuable network facilities, whether particular solutions will do harm to networks and/or end systems when deployed (say, due to poor security), and on the size of the market for a single solution vs. the size of markets for fragmented solutions. it's a bit like an argument that there shouldn't be any standards for automobiles. which leads to more pollution, higher accident rates, higher casualties, higher insurance rates and/or more expensive vehicles for everyone. there are corrective mechanisms for some of these (as in, people will tend to favor cars that have lower insurance rates) but some of an individual's risks due to automobiles aren't influenced by his own decisions so much as others' decisions. Yes, using your example, IM protocols fragment, interop suffers, there's lots of crap --- so what? It looks like it will probably sort out. Fretting over how best to impose governance over the situation doesn't obviously accomplish anything. well, nobody is talking about governance, since we don't have any enforcement mechanisms. There are faster, better, cheaper ways I think to get universally adapted standards in motion than wrangling with committees. it's pretty difficult to build something that works well in the diverse environments in the Internet without extensive discussions among experienced people with a wide variety of interests. to the extent that it happens, it's either luck (rare) or genius (even rarer). The main practical utility of standards very high in the stack is that they are written clearly, widely reviewed, and generally agreeable to people. One doesn't need a complicated government to support the development of standards with that utility: a few mailing lists and archives do most of the trick. again, nobody is talking about a government. we're talking about a mechanism to support engineering work among diverse and often-competing participants, that will produce results in which users/customers can have a high degree of confidence. Processes in which there is nothing available to fight over seem like the most efficient to me. that's because you aren't considering the cost _after_ that process. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: improving WG operation
--On Wednesday, 04 May, 2005 14:23 -0400 Marshall Eubanks [EMAIL PROTECTED] wrote: ... It might be time to revist some of these tools for interactive collaboration. Smart is a Canadian company; maybe we should get them as a sponosor for IETF 64. Now _that_ would be way cool. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: improving WG operation
It might be time to revist some of these tools for interactive collaboration. Smart is a Canadian company; maybe we should get them as a sponosor for IETF 64. Now _that_ would be way cool. maybe. however, rather than our starting with an interesting in some set of tools that fall into an interesting, albeit large and vague -- area, perhaps we should figure out what we need to do that we can't reasonably do now. tools have their own expense, and we already have quite a few. adding useful ones would be... useful. adding ones that are not highly useful would be more hassle that they are worth. given email, jabber and multi-casting voice/video, what additional collaborative processes might be helpful for getting IETF face-to-face meetings more productive? i believe this sub-thread was triggered by an interest in something like a real whiteboard that could be digitally captured and shared. Is that the function we need a tool for? are there others? d/ --- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: improving WG operation
--On Saturday, 07 May, 2005 12:08 -0700 Dave Crocker [EMAIL PROTECTED] wrote: ... given email, jabber and multi-casting voice/video, what additional collaborative processes might be helpful for getting IETF face-to-face meetings more productive? i believe this sub-thread was triggered by an interest in something like a real whiteboard that could be digitally captured and shared. Is that the function we need a tool for? are there others? Yes, real whiteboards (or equivalent) were what started the subthread. And yes, ones that could be captured and shared would, IMO, enhance the process, especially for remote participants, and especially since we have largely dropped video (which might permit remote participants to look at on-screen materials). I could, of course, be wrong, but I don't know how to find out without trying it. And I responded strongly to Marshall's suggestion because those digital-capable whiteboards are not cheap and, unlike VGA projectors, are hard or impossible to obtain from the local rent-a-computer or hotel AV facility. Whether it is worth the experiment --and I acknowledge that experiments, like tools, have their own costs-- I'm happy to leave to whatever community consensus emerges. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: improving WG operation
Behalf Of Keith Moore So, if there is indeed the IETF community expectation that the WG gets to pick at least some of its own chairs, then rfc3710 needs to be revised to reflect this. not necessarily. a significant part of the community can expect something and there still not be rough consensus about it. I think it is time to redefine consensus. What we need for a standard is a group of people with a reasonable degree of skill in the art who agree on a common plan. That is not necessarily the same as 'working group consensus'. For example if there is a protocol where there is a divergence of opinion on the correct way to proceed and one group can agrree on a coherent plan then it goes forward. If there are two groups with coherent plans then the way forward depends on whether we are talking about an infrastructure protocol such as BGP or DNS or an application protocol. If we are talking about infrastructure protocols then I think that is a case where the IESG needs to step in sooner rather than later. If we are talking about application protocols let the market decide. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: improving WG operation
I think it is time to redefine consensus. What we need for a standard is a group of people with a reasonable degree of skill in the art who agree on a common plan. no. the protocol doesn't just affect those with a reasonable degree of skill in the art. (as if one could define which art were relevant...) That is not necessarily the same as 'working group consensus'. For example if there is a protocol where there is a divergence of opinion on the correct way to proceed and one group can agrree on a coherent plan then it goes forward. no. at least, not with the expectation that the work will ever be found acceptable. if there is a divergence of opinion it is highly likely (though not certain) that there is a fundamental lack of understanding on both sides that needs to be resolved before real progress can be made. any work done without that understanding is likely to be flawed and the investment in that work likely to be wasted. If there are two groups with coherent plans then the way forward depends on whether we are talking about an infrastructure protocol such as BGP or DNS or an application protocol. If we are talking about infrastructure protocols then I think that is a case where the IESG needs to step in sooner rather than later. If we are talking about application protocols let the market decide. it's not that cut-and-dried. it can be very costly to users to let the market decide. sometimes the market doesn't decide, it just fragments. users either don't end up with a coherent solution or they end up with an overly complex solution that doesn't interoperate well - IM is a good example. that and the argument of let the market decide is constantly used by market leaders as a way to try to derail standards that might compete with their (usually poor) proprietary solutions. it should be taken as a sign of weakness on the part of those who say it. what you appear to be trying to do is to increase the number of ways in which people can derail the process. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: improving WG operation
what you appear to be trying to do is to increase the number of ways in which people can derail the process. And more power to him. IETF was a great success. It's reaching end-of-life. it's not that cut-and-dried. it can be very costly to users to let the market decide. sometimes the market doesn't decide, it just fragments. So? -t ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: improving WG operation
what you appear to be trying to do is to increase the number of ways in which people can derail the process And more power to him. IETF was a great success. It's reaching end-of-life. people still seem to find its work useful, at least in some areas. if you don't feel it's worth your time, you are free to spend your time elsewhere. it's not that cut-and-dried. it can be very costly to users to let the market decide. sometimes the market doesn't decide, it just fragments. So? so let the market decide is a lousy rule. there's no justification for it. it's just the sort of thing that someone says when he fears competition from a better product. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: improving WG operation
Keith, - The working group gets to pick at least some of its own chairs. Sorry, but I do not think the last bullet is correct. I was talking about community expectation, which is not always consistent with what is written in the RFCs just like implementations of networking protocols are not always consistent with the RFCs. Such situation requires revised RFCs. So, if there is indeed the IETF community expectation that the WG gets to pick at least some of its own chairs, then rfc3710 needs to be revised to reflect this. Which includes *clearly* spelling out the process by which the WG gets to pick at least some of its own chairs. In fact, perhaps some folks from the IESG (e.g., Brian) would comment on this topic... Yakov. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: improving WG operation
So, if there is indeed the IETF community expectation that the WG gets to pick at least some of its own chairs, then rfc3710 needs to be revised to reflect this. not necessarily. a significant part of the community can expect something and there still not be rough consensus about it. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: improving WG operation
Keith Moore wrote: It seems to me that the fundamental problem is that most of the meeting has not read most of the drafts let alone the latest version under discussion. I think that's a symptom; a more fundamental problem is that WGs are trying to do too many things at once. I've lost track of how many times I've seen a WG a) take valuable meeting time to have a presentation about a draft that is only peripherally related to the WG's current task How many of those have been at the suggestion, or _insistance_, that an individual or other WG's work be 'checked' in that WG? b) get a show of hands how many people think this draft should be a WG work item? The art of asking a survey question is key; there have been a number of recent docs accepted as standards-track simply because issues of should this even be a WG issue, is this the best doc to lead that issue, and should this doc be informational, BCP, or standards-track were all asked at once. c) accept the draft as a WG work item without any discussion of whether doing so will affect the WG's ability to get other work done, or the WG's ability to give adequate attention to the work already accepted Or whether it is the WG or the IESG that has the real interest in the area of work. When a doc hasn't even been read by a handful of people - even after _multiple_ requests _at_ repeated WG meetings, it's amazing when the result is a call for decision on what to do. I've said it before: sometimes silence speaks for itself. Joe signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: improving WG operation
I think that's a symptom; a more fundamental problem is that WGs are trying to do too many things at once. I've lost track of how many times I've seen a WG a) take valuable meeting time to have a presentation about a draft that is only peripherally related to the WG's current task How many of those have been at the suggestion, or _insistance_, that an individual or other WG's work be 'checked' in that WG? I've never seen an AD insist that a WG devote valuable face-to-face meeting time to checking work that was peripheral to the WG's interest. OTOH, I have seen WGs saddled with trying to make some other group's work into something sane - it's a thankless job, but sometimes a necessary one. (mDNS comes to mind most readily here). c) accept the draft as a WG work item without any discussion of whether doing so will affect the WG's ability to get other work done, or the WG's ability to give adequate attention to the work already accepted Or whether it is the WG or the IESG that has the real interest in the area of work. When a doc hasn't even been read by a handful of people - even after _multiple_ requests _at_ repeated WG meetings, it's amazing when the result is a call for decision on what to do. Why is that amazing? Yes, sometimes silence speaks for itself, but there's nothing wrong with asking the question - so long as lack of response isn't taken for yes. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: improving WG operation
Keith Moore wrote: I think that's a symptom; a more fundamental problem is that WGs are trying to do too many things at once. I've lost track of how many times I've seen a WG a) take valuable meeting time to have a presentation about a draft that is only peripherally related to the WG's current task How many of those have been at the suggestion, or _insistance_, that an individual or other WG's work be 'checked' in that WG? I've never seen an AD insist that a WG devote valuable face-to-face meeting time to checking work that was peripheral to the WG's interest. Check again, please. I personally have been asked to take items to WGs that I've already presented them to repeatedly - even at the meeting adjacent to a Last Call. OTOH, I have seen WGs saddled with trying to make some other group's work into something sane - it's a thankless job, but sometimes a necessary one. (mDNS comes to mind most readily here). Sure - and that's where the process works. Since it's hard to know that ahead of time, why are you complaining about the check? c) accept the draft as a WG work item without any discussion of whether doing so will affect the WG's ability to get other work done, or the WG's ability to give adequate attention to the work already accepted Or whether it is the WG or the IESG that has the real interest in the area of work. When a doc hasn't even been read by a handful of people - even after _multiple_ requests _at_ repeated WG meetings, it's amazing when the result is a call for decision on what to do. Why is that amazing? Yes, sometimes silence speaks for itself, but there's nothing wrong with asking the question - so long as lack of response isn't taken for yes. That's the amazing part - the question was something akin to any objection to taking this as a WG item? Joe signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: improving WG operation
I've never seen an AD insist that a WG devote valuable face-to- face meeting time to checking work that was peripheral to the WG's interest. Check again, please. I personally have been asked to take items to WGs that I've already presented them to repeatedly - even at the meeting adjacent to a Last Call. Okay, so maybe that was a botch. But surely you can find a quicker and more effective way to remedy that botch than by whining about it endlessly here? And if you couldn't figure out how to do that by yourself, why couldn't you ask some people with more experience working in and/or with IESG? (and did the AD really insist that you bring this up in a _face-to- face_ WG meeting, or is that just how you and/or the WG chair chose to interpret it?) Why is this one botch evidence of such a fundamental problem with the IETF process that it needs to be altered in a way that there's plenty of reason to believe will work far worse than what we have? Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: improving WG operation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Keith Moore wrote: I've never seen an AD insist that a WG devote valuable face-to- face meeting time to checking work that was peripheral to the WG's interest. Check again, please. I personally have been asked to take items to WGs that I've already presented them to repeatedly - even at the meeting adjacent to a Last Call. Okay, so maybe that was a botch. But surely you can find a quicker and more effective way to remedy that botch than by whining about it endlessly here? And if you couldn't figure out how to do that by yourself, why couldn't you ask some people with more experience working in and/or with IESG? (and did the AD really insist that you bring this up in a _face-to- face_ WG meeting, or is that just how you and/or the WG chair chose to interpret it?) What's the difference if it eats time you perceive as wasted post-facto? Why is this one botch evidence of such a fundamental problem with the IETF process that it needs to be altered in a way that there's plenty of reason to believe will work far worse than what we have? Keith It isn't - the point is that wasting valuable face-to-face time at WGs doing cross-area checks is one of the points of the face-to-face meetings. Whether time is wasted is easy to assert post-facto, but short of avoiding cross-area review and entrusting it solely to the mythical omniscient, wise, and prudent AD, what's the alternative to erring on the side of wasting time? Joe -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCemKJE5f5cImnZrsRAkHvAKDzDMlq05212BtWTl9JG6x1Nl8Z5QCg+4IY Q9gqIezLhsbghQmjCoPg7NI= =vEEo -END PGP SIGNATURE- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: improving WG operation
John, I was thinking about whiteboards too. I'll check with the secretariat if smth like this would be possible. Thanks. -- Alex http://www.psg.com/~zinin Monday, May 2, 2005, 9:30:00 AM, John C Klensin wrote: --On Monday, 02 May, 2005 05:43 -0700 Alex Zinin [EMAIL PROTECTED] wrote: Margaret, Dave, et al- Based on the discussion started in the IESG, one thing we are going to try to do in Paris is have a couple of smaller rooms with a different chair setup--herringbone instead of the theater style, a couple more radio microphones, and appropriate-size (smaller than huge) projector screens. I'm working with the secretariat on this. Alex, Given other discussions on this list, might I suggest that those rooms also be equipped, if possible, with some mechanism by which interactions within the group/meeting can easily be recorded: Any of overhead projectors with foils and markers, flip charts with markers, or whiteboards would all do the job and all have been mentioned. As others have pointed out, these things can, in theory, all be done in powerpoint, but I suggest that few of us are efficient enough with it to be able to do pictures and serious mark-up in real time (independent of whether we can transcribe text or not). Or, if that isn't feasible for Paris, could it be considered for Vancouver? thanks, john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: improving WG operation
On Wed, 4 May 2005 10:44:06 -0700 Alex Zinin [EMAIL PROTECTED] wrote: John, I was thinking about whiteboards too. I'll check with the secretariat if smth like this would be possible. Thanks. There are, of course, a number of companies which make products for group interaction. Some that I like (and I have no connection with these) are eLLuminate, which makes a nice java based platform for sharing information on a desktop (we tested this a while back on Windows, OS X and Linux with good results) and Smart Technologies (which makes a set of really cool smart whiteboards). Of course, there is a learning curve for anything, and none of this is free. Even if we used VRVS, which we could probably get from CalTech for free, IMHO it would be a full time job for someone to get and keep all of this running for every WG at an IETF meeting. It might be time to revist some of these tools for interactive collaboration. Smart is a Canadian company; maybe we should get them as a sponosor for IETF 64. Regards Marshall Eubanks -- Alex http://www.psg.com/~zinin Monday, May 2, 2005, 9:30:00 AM, John C Klensin wrote: --On Monday, 02 May, 2005 05:43 -0700 Alex Zinin [EMAIL PROTECTED] wrote: Margaret, Dave, et al- Based on the discussion started in the IESG, one thing we are going to try to do in Paris is have a couple of smaller rooms with a different chair setup--herringbone instead of the theater style, a couple more radio microphones, and appropriate-size (smaller than huge) projector screens. I'm working with the secretariat on this. Alex, Given other discussions on this list, might I suggest that those rooms also be equipped, if possible, with some mechanism by which interactions within the group/meeting can easily be recorded: Any of overhead projectors with foils and markers, flip charts with markers, or whiteboards would all do the job and all have been mentioned. As others have pointed out, these things can, in theory, all be done in powerpoint, but I suggest that few of us are efficient enough with it to be able to do pictures and serious mark-up in real time (independent of whether we can transcribe text or not). Or, if that isn't feasible for Paris, could it be considered for Vancouver? thanks, john ___ 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: improving WG operation
Other organizations have proponents explain what they are proposing. IMO this leads to a better quality of discussion. Those other organizations often do *all* their work and take all decisions in their face2face meetings, while our main venue is our WG mail list, and face2face meetings are only complimentary, where we can get higher bandwidth for discussion, and resolve tricky issues. The mistake we (as chairs) often do is when we do not plan meetings based on what issues actually require face2face meeting time, but instead just make an agenda covering all ongoing WG items (and documents), and often also completely new individual contributions that are not in our charter. The latter sometimes motivates taking face2face agenda time, but that should still be done first when the item (based on an internet draft) has already been discussed on the mailing list so that the WG is aware of it. If face2face time then is needed to get a better understanding and discussion about the issues, then that would be good use of face2face time. /L-E ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: improving WG operation
Dave, do you have any thoughts about how we can change the IETF culture from presentation to interaction (with or without slides). This is something that the IESG has been talking about, among others, but I'm not sure that we've come up with any really concrete ways to provoke/encourage this change. Margaret, in general I think the issue is stricter meeting planning and management, where the goals and process are more explicit. Of course, good wgs already do that. Off the top of my head: 1. Require that the meeting have a web-posted agenda -- and really enforce the requirement. So, this makes sure others have a chance to evaluate what is going to take place. No agenda a week in advance; no meeting. 2. Require that the deliverables of the meeting be pre-stated and prioritized. 3. Have the agenda include statements about how the deliverables will be met. I guess this is something on the order of stating what the meeting process will be. Hence, interaction with the participants is a component of that process. d/ --- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: improving WG operation
People can and do use powerpoint slides in many ways. Some folks will rework text in real-time, based on interaction with the participants. Some folks just talk their slides rather than actually engaging with the participants. A thing to keep in mind is that slides and the jabber activity can be incredibly helpful to folks for whom English not their native language. I think that, in fact, the issue is not powerpoint-vs-no-powerpoint. I think it is exactly and only the concern you raise: meetings need to be for working group interaction. If that is the clear goal and if the meeting is run with that goal enforced, then none of the trappings matter. I completely agree with this. And, I've been to plenty of non-interactive lectures that didn't involve any slides. Dave, do you have any thoughts about how we can change the IETF culture from presentation to interaction (with or without slides). This is something that the IESG has been talking about, among others, but I'm not sure that we've come up with any really concrete ways to provoke/encourage this change. Margaret ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: improving WG operation
Margaret, Dave, et al- Based on the discussion started in the IESG, one thing we are going to try to do in Paris is have a couple of smaller rooms with a different chair setup--herringbone instead of the theater style, a couple more radio microphones, and appropriate-size (smaller than huge) projector screens. I'm working with the secretariat on this. -- Alex I think that, in fact, the issue is not powerpoint-vs-no-powerpoint. I think it is exactly and only the concern you raise: meetings need to be for working group interaction. If that is the clear goal and if the meeting is run with that goal enforced, then none of the trappings matter. I completely agree with this. And, I've been to plenty of non-interactive lectures that didn't involve any slides. Dave, do you have any thoughts about how we can change the IETF culture from presentation to interaction (with or without slides). This is something that the IESG has been talking about, among others, but I'm not sure that we've come up with any really concrete ways to provoke/encourage this change. Margaret ___ 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: improving WG operation
Margaret, The words I hate most when I am in a WG meeting are these: take it to the mailing list That is usually short for we can't agree in person so we'll now continue to disagree by email. Debate has been shut off, and usually prematurely because there is something else on the agenda. I'd rather that never happen. I think it's fair to specify the parameters for a decision and then go to the mailing list so that people could evaluate different solutions based on those parameters, but simply blowing off a topic because the group cannot agree is a failure of leadership. So, in answer to the question you asked Dave, I would agree with him about [1] and [2] in his message. I don't fully understand [3]. I would go a bit further to say that the agendas should be approved by an AD. Why? Because it forces the AD to pay attention to the group. No group should run on auto-pilot. Any AD that cannot do this with little or no effort, should spend more time with the WG in question. The AD gets to approve the order. If agenda bashing shows that the chair missed something, then there was a failure on the mailing list, and corrective action should be taken to fix the problem. I would not penalize a WG for not getting to the end of its agenda. That, in fact, is a call for an interim meeting, perhaps. I would add one more thing. We need whiteboards, ones with erasers. it used to be that we had them years and years ago. Being able to draw out solutions and list and reorder problems is a good thing. So, a not so fictitious example: The ISMS WG is currently struggling to choose between one of three architectures for integrated SNMP security models. A call for consensus has been issued, and thus far there is none. The reason there is none is that people do not yet agree on the underlying requirements, IMHO. This is all good fodder for an in person meeting. If neither mailing list nor in person meeting can solve the problem, then the AD needs to step in and do something. Prior to the meeting there should be a short summary of the issues, pro and con for each alternative, as well as proposed evaluation criteria. The meeting may be a good venue to expand or contract those criteria. Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: improving WG operation
It seems to me that the fundamental problem is that most of the meeting has not read most of the drafts let alone the latest version under discussion. There is a fundamental IETF tenet that nothing is explained but there is a false assumption that the people in the meetings have read the drafts. Whenever I've seen the chair ask how many hve read the draft, it is usually 5%. I think this is a key issue but the solution is not obvious. Nobody can read the number of drafts that are issued for a meeting. Not even for the subset of attended WGs. Other organizations have proponents explain what they are proposing. IMO this leads to a better quality of discussion. But this limits the number of topics that can be worked on in a week to far less than the IETF tries to cover. Steve Silverman -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Margaret Wasserman Sent: Sunday, May 01, 2005 10:10 AM To: Dave Crocker Cc: ietf@ietf.org Subject: Re: improving WG operation People can and do use powerpoint slides in many ways. Some folks will rework text in real-time, based on interaction with the participants. Some folks just talk their slides rather than actually engaging with the participants. A thing to keep in mind is that slides and the jabber activity can be incredibly helpful to folks for whom English not their native language. I think that, in fact, the issue is not powerpoint-vs-no-powerpoint. I think it is exactly and only the concern you raise: meetings need to be for working group interaction. If that is the clear goal and if the meeting is run with that goal enforced, then none of the trappings matter. I completely agree with this. And, I've been to plenty of non-interactive lectures that didn't involve any slides. Dave, do you have any thoughts about how we can change the IETF culture from presentation to interaction (with or without slides). This is something that the IESG has been talking about, among others, but I'm not sure that we've come up with any really concrete ways to provoke/encourage this change. Margaret ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ This message was passed through [EMAIL PROTECTED], which is a sublist of [EMAIL PROTECTED] Not all messages are passed. Decisions on what to pass are made solely by IETF_CENSORED ML Administrator ([EMAIL PROTECTED]). ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: improving WG operation
It seems to me that the fundamental problem is that most of the meeting has not read most of the drafts let alone the latest version under discussion. I think that's a symptom; a more fundamental problem is that WGs are trying to do too many things at once. I've lost track of how many times I've seen a WG a) take valuable meeting time to have a presentation about a draft that is only peripherally related to the WG's current task b) get a show of hands how many people think this draft should be a WG work item? c) accept the draft as a WG work item without any discussion of whether doing so will affect the WG's ability to get other work done, or the WG's ability to give adequate attention to the work already accepted Now there are certainly cases in which a WG needs to generate lots of documents in order to fulfill its mission. But to the extent that new work items are identified in the manner described above, it probably indicates a lack of planning. It should be possible to identify early on which topics need to be addressed by WG documents and which ones are either peripheral to the WG's mission or need to wait until the primary deliverables are completed. The initial charter is generally too early to do this, but it would be reasonable for such a work plan to be one of the first deliverables of the initial charter. Once that work plan is established, WGs need to push back on taking on additional work. And the push back probably needs to come from the chairs, or if the chairs won't do it, the ADs. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: improving WG operation
--On Monday, 02 May, 2005 09:56 -0400 Steve Silverman [EMAIL PROTECTED] wrote: It seems to me that the fundamental problem is that most of the meeting has not read most of the drafts let alone the latest version under discussion. There is a fundamental IETF tenet that nothing is explained but there is a false assumption that the people in the meetings have read the drafts. Whenever I've seen the chair ask how many hve read the draft, it is usually 5%. I think this is a key issue but the solution is not obvious. Nobody can read the number of drafts that are issued for a meeting. Not even for the subset of attended WGs. If it were true that no one can read the drafts relevant to work they are actually materially concerned with (a slightly different definition than yours), and I suggest it is not, then WGs are trying to do too much, and handle too many documents, at once. Others have made that point. As far as the 5% is concerned, we have, it seems to me, a choice: * We can decide to focus on the people who are doing the work and making real contributions. If they have read the drafts, fine. If most of them have not, then it is time to cancel the meeting after that show of hands. Those who are not usefully contributing don't count at all. * We can decide that the people who haven't done the reading shouldn't be in the room and either evict them or impose admission requirements for participation in a WG. Note that many of the other groups to which you refer have such admission requirements, whether they are taken seriously or not. Other organizations have proponents explain what they are proposing. IMO this leads to a better quality of discussion. But this limits the number of topics that can be worked on in a week to far less than the IETF tries to cover. It also, often, leads to much more superficial evaluation of what is being standardized than the IETF has traditionally been willing to tolerate. Note that we still expect most work to be done on mailing lists and between meetings, not in face-to-face no one things about this in between, then we get together and try to make standards meetings. I think either model can be viable, but they are different... and there are still significant contributors to the IETF who have no set foot in a face-to-face IETF meeting in years (if ever). john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: improving WG operation
--On Monday, 02 May, 2005 05:43 -0700 Alex Zinin [EMAIL PROTECTED] wrote: Margaret, Dave, et al- Based on the discussion started in the IESG, one thing we are going to try to do in Paris is have a couple of smaller rooms with a different chair setup--herringbone instead of the theater style, a couple more radio microphones, and appropriate-size (smaller than huge) projector screens. I'm working with the secretariat on this. Alex, Given other discussions on this list, might I suggest that those rooms also be equipped, if possible, with some mechanism by which interactions within the group/meeting can easily be recorded: Any of overhead projectors with foils and markers, flip charts with markers, or whiteboards would all do the job and all have been mentioned. As others have pointed out, these things can, in theory, all be done in powerpoint, but I suggest that few of us are efficient enough with it to be able to do pictures and serious mark-up in real time (independent of whether we can transcribe text or not). Or, if that isn't feasible for Paris, could it be considered for Vancouver? thanks, john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: improving WG operation
As others have pointed out, these things can, in theory, all be done in powerpoint, but I suggest that few of us are efficient enough with it to be able to do pictures and serious mark-up in real time (independent of whether we can transcribe text or not). A simple, ad hoc, and useful approach is to make sure someone takes a picture as legacy-technology renditions -- paper, whiteboard, whatever -- are created, and then uploads it or emails it to an agreed-to location. It is procedurally a bit awkward, but already fits into existing practise, albeit not for this purpose. And it does not require any formal support. d/ --- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: improving WG operation
Margaret Choose the right chairperson (or having chosen one, train them). I have heard you speak of the roles of the WG chair (and of the editors of I-Ds) and think your ideas are absolutely right. The WGs that I find less effective are those where the chairs, for all their undoubted engineering skills, are less effective at the role of chairmanship of meetings, a role which starts with the agenda, ends with the minutes, and involves making the most effective use of the 'face time' in between. Tom Petch - Original Message - From: Margaret Wasserman [EMAIL PROTECTED] To: Dave Crocker [EMAIL PROTECTED] Cc: ietf@ietf.org Sent: Sunday, May 01, 2005 4:09 PM Subject: Re: improving WG operation People can and do use powerpoint slides in many ways. Some folks will rework text in real-time, based on interaction with the participants. Some folks just talk their slides rather than actually engaging with the participants. A thing to keep in mind is that slides and the jabber activity can be incredibly helpful to folks for whom English not their native language. I think that, in fact, the issue is not powerpoint-vs-no-powerpoint. I think it is exactly and only the concern you raise: meetings need to be for working group interaction. If that is the clear goal and if the meeting is run with that goal enforced, then none of the trappings matter. I completely agree with this. And, I've been to plenty of non-interactive lectures that didn't involve any slides. Dave, do you have any thoughts about how we can change the IETF culture from presentation to interaction (with or without slides). This is something that the IESG has been talking about, among others, but I'm not sure that we've come up with any really concrete ways to provoke/encourage this change. Margaret ___ 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: improving WG operation
- The working group gets to pick at least some of its own chairs. Sorry, but I do not think the last bullet is correct. I was talking about community expectation, which is not always consistent with what is written in the RFCs just like implementations of networking protocols are not always consistent with the RFCs. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: improving WG operation
Keith, [clipped...] 2. There is a considerable cultural inertia within IETF that largely dictates how working groups operate, and which is extremely difficult to change. For instance, community expectations include: - If there is a BOF held and sufficient constituency identified for a working group, the working group must be chartered. - The working group gets to pick at least some of its own chairs. Sorry, but I do not think the last bullet is correct. To the contrary, (quoting from rfc3710): The AD, with the advice of the IESG, is also responsible for selecting chairs for the working group which the AD thinks will be up to the task. Nowhere it mentioned that the WG gets to pick at least some of its own chairs. Yakov. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: technical supervisors (was: improving WG operation)
On Sat, 30 Apr 2005, Keith Moore wrote: The concept of Technical Supervisors could be tried on two or three working groups and refined based on experience. Initially the supervisors might be appointed by the AD and confirmed by IESG; eventually there might be a separate mechanism for nominating and vetting potential supervisors. Ideally a working group would keep the same supervisor as long as it is chartered, though it would be possible to change a WG's supervisor - particularly one who wasn't doing his job well. Supervising a WG shouldn't require more than say 2 hours per week. There would need to be some way to recognize the contributions of WG supervisors, and perhaps some incentives for taking on a job with low visibility and minimal creative input. What you write could probably be accomplished as a 'Technical Advisor' that some WGs have and is listed in the charter pages ? The key point here is that such technical supervisors should have broad experience (preferably have been on the IESG, or have been exposed to the work, e.g., by being a chair of a WG which produced a lot of documents) to be able to have sufficient cross-area insight. The most difficult issue would probably be the coordination between the supervisors and chairs, and to a lesser degree, the ADs -- of course depending how much authority and micromanagement of document editors the supervisor would be required to do. Personally, if each WG had just one Techical Advisor which would be committed to reviewing the specifications early, and who would be at the disposal of the chairs if there are doubts, we could be much better off -- especially if a WG wouldn't have experienced chairs. -- 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: technical supervisors (was: improving WG operation)
What you write could probably be accomplished as a 'Technical Advisor' that some WGs have and is listed in the charter pages ? it could be an expansion of that role. in my mind, such people would have explicit authority to specify the agenda for WG discussions, and some explicit responsibilities to the responsible AD that may not be defined at present. The key point here is that such technical supervisors should have broad experience (preferably have been on the IESG, or have been exposed to the work, e.g., by being a chair of a WG which produced a lot of documents) to be able to have sufficient cross-area insight. yes, I'm generally thinking senior IETF people who are familiar with the processes, and who are also familiar with engineering disciplines (whether by education or experience using them) The most difficult issue would probably be the coordination between the supervisors and chairs, and to a lesser degree, the ADs -- of course depending how much authority and micromanagement of document editors the supervisor would be required to do. it certainly implies a significant change to the role of WG chair, and I can imagine some chairs not wanting to give up that much control. the thing to do is to cultivate an effective working relationship between the chair and supervisor, where the chair sees the supervisor as someone who helps the WG's progress more quickly and helps the WG make its case to IESG. but I see the supervisor as ultimately responsible to the AD rather than to the WG, so there's some inherent conflict there. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: technical supervisors (was: improving WG operation)
Keith, This _is_ going to be a terse reply, since others have covered much of what I would have. But the topics are complex. Three observations... (1) My observation about whining had more to do with the general tone of many of these discussions, in this round and earlier, rather than anything about what you may or may not have said specifically. Please don't take that categorization personally or, even generally, as more than a warning about S/N ratios and ways to make progress (or the lack thereof). (2) We have repeatedly tried variations on this theme. The area advisor got that title because the secretariat couldn't modify the relevant templates to include both responsible AD (as we moved to two-AD areas with split, rather than shared, responsibility) and the notion of someone senior who keeps a close eye on a WG, advising the chair and WG but reporting to the AD. A different variation might have been called designated leadership developer/coach. I think these ideas have worked well sometimes and not at all in others. The fact that we have tried variations should not imply that we should avoid trying another, but may call for some serious thought about why the previous attempts have not always worked effectively. (3) I've commented earlier on my concerns about adding intermediate layers of management or review and won't repeat those remarks here. john --On Saturday, 30 April, 2005 01:40 -0400 Keith Moore moore@cs.utk.edu wrote: wow...I keep wanting to make terse replies, but there never seems to be a way to address the subject with a short answer. I'm sorry you see these explanations as whining. I believe that we have to recognize that part of our problem is how WGs operate before we can be willing to solve that problem. So I try to describe that problem in a way that people will recognize it. Maybe people already realize that we have this problem and I don't actually need to illustrate it. As for solutions - I have been thinking about possible solutions for several years. But I'm much better at protocol engineering than I am at engineering management or social structures, so I don't have much confidence in my ideas for how to solve the problem. Recently I've begun to suspect that a good answer to some of these problems might involve a layer of management between IESG and working groups - a set of people who had responsibility to give some technical oversight to working groups, monitor their progress, and keep the ADs up-to-date on the state of things. I say oversight rather than direction because direction would be too strong a term. I don't see the supervisor (let's call him a supervisor for now) ... ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: improving WG operation (was Re: Voting (again))
Keith, you have been advocating a model where the IETF would be stricter in allowing what work be taken up, in order to ensure that we can actually deliver. But I share the same opinion as John L that we should rather try to shape the IETF so that it can deliver what the world needs. My primary criterion when arguing whether IETF should or should not take up a WG was always, in some sense, whether the Internet needed IETF to be involved in and supporting this effort. It involved both an assessment of how much harm would result from a botched design (in particular, a design that didn't respect the Internet environment and other protocols on the net), and of whether IETF could expend the resources necessary to manage the group and whether it could bring the necessary expertise to the table. It also involved an assessment of whether the proposed protocol would actually be of benefit to the Internet long-term. What I didn't try to assess (much) was whether IETF's reputation would be enhanced by its involvement in that particular WG. Part of the reason why I believe so is that despite its problems, I think the IETF produces the best technology and highest quality. I want to use IETF multimedia, IETF network access control mechanisms, IETF security and not something else. This won't be easy of course, but I think we can do it. We are extremely good engineers and we've been able to produce scalable technology and useful, complexity reducing abstractions. Maybe time to apply some of that for our organization as well? I don't think that IETF inherently produces the best technology and highest quality in every area of Internet protocol design. We cannot be good at everything. I may be dated in my awareness of our participants' expertise, but I doubt we have enough of the best designers of cryptographic algorithms, audio or video codecs, forward error correction codes, radio transmission methods, etc. There's a reason we leave valuable technical work to IEEE, 3GPP, W3C, etc. We have to specialize, as they do. The Internet is too vast and diverse for all of its technical work to be done by one organization. For me the selection criteria (in brief) have to do with whether the protocols in question impact the core Internet protocols or protocols traditionally developed in IETF, or whether the protocols in question need input from those with the most expertise from core or traditional IETF protocols. Those are fairly elastic criteria that cover a lot of ground, but not everything. For instance, we don't need to be involved much in B2B transaction processing as long as those guys can use existing protocols like TCP or HTTP in a way that works well for them and doesn't adversely impact the Internet. We might say things like don't run everything over port 80 or don't place too much faith in perimeter security but we don't need to try to take over all of their protocol design. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: improving WG operation (was Re: Voting (again))
Hi Keith, Keith, you have been advocating a model where the IETF would be stricter in allowing what work be taken up, in order to ensure that we can actually deliver. But I share the same opinion as John L that we should rather try to shape the IETF so that it can deliver what the world needs. My primary criterion when arguing whether IETF should or should not take up a WG was always, in some sense, whether the Internet needed IETF to be involved in and supporting this effort. It involved both an assessment of how much harm would result from a botched design (in particular, a design that didn't respect the Internet environment and other protocols on the net), and of whether IETF could expend the resources necessary to manage the group and whether it could bring the necessary expertise to the table. It also involved an assessment of whether the proposed protocol would actually be of benefit to the Internet long-term. All good criteria! I would probably add assessment of whether lack of the protocol would be of harm to the Internet long-term (assuming the protocol falls within our scope, as you correctly point out below). Here's an example: a protocol that is within IETF scope, but we suddenly stop maintaining it to respond to changing requirements, or open it up to vendor extensions without providing good abstractions that maintain interoperability. Part of the reason why I believe so is that despite its problems, I think the IETF produces the best technology and highest quality. I want to use IETF multimedia, IETF network access control mechanisms, IETF security and not something else. This won't be easy of course, but I think we can do it. We are extremely good engineers and we've been able to produce scalable technology and useful, complexity reducing abstractions. Maybe time to apply some of that for our organization as well? I don't think that IETF inherently produces the best technology and highest quality in every area of Internet protocol design. We cannot be good at everything. I may be dated in my awareness of our participants' expertise, but I doubt we have enough of the best designers of cryptographic algorithms, audio or video codecs, forward error correction codes, radio transmission methods, etc. There's a reason we leave valuable technical work to IEEE, 3GPP, W3C, etc. We have to specialize, as they do. The Internet is too vast and diverse for all of its technical work to be done by one organization. For me the selection criteria (in brief) have to do with whether the protocols in question impact the core Internet protocols or protocols traditionally developed in IETF, or whether the protocols in question need input from those with the most expertise from core or traditional IETF protocols. Those are fairly elastic criteria that cover a lot of ground, but not everything. For instance, we don't need to be involved much in B2B transaction processing as long as those guys can use existing protocols like TCP or HTTP in a way that works well for them and doesn't adversely impact the Internet. We might say things like don't run everything over port 80 or don't place too much faith in perimeter security but we don't need to try to take over all of their protocol design. I am in agreement with all what you say here. Just pointing out that even with specialization, we may have quite a lot to do. --Jari ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: improving WG operation
Keith, Let me offer a different perspective here as well and, in the process, explain why I keep coming back to the IESG. Going back almost to the dawn of IESG time, the IESG has had one constant and primary responsibility. That is to manage the WGs and the WG process. Under today's rules, they determine or ratify which WGs get created, who chairs them and how they are otherwise managed, what tasks and benchmarks go into charters, how many and which documents a WG can work on at a time (and whether they work on documents serially or in parallel), and when to shut them down. They have _huge_ latitude in how to manage WGs and the decisions they make about that management process, including a wide range of options about reporting, review of benchmarks, actions or the lack thereof when targets are not met, and so on. WGs, and WG leadership, have no independent existence: the IESG, and under some circumstances, individual ADs can dispose of them as needed. Personally, I think that is as it should be. [...] But, from that perspective, there is no WG problem or problem WG. There is only an IESG management problem. Without quoting your entire message, let me say that I do agree at least partially with this. But while at least in theory, IESG has all of the authority and mechanisms it needs to change working group behavior, let me explain why, in practice, I don't think IESG can make the changes that are necessary. There are many things that IESG cannot do with working groups, for a variety of reasons. 1. WG participants are volunteers. For the purpose of this discussion it matters not whether they are volunteering their own personal time and energy or whether their employers are volunteering the time and energy. The IESG can name WG chairs (assuming it can find willing victims) but it cannot hire or fire participants based on their qualifications, nor can it do much to create incentives to fill particular positions with especially qualified people. This is generally as it should be; however, it removes some of the mechanisms by which managers in the real world produce high-quality output. 2. There is a considerable cultural inertia within IETF that largely dictates how working groups operate, and which is extremely difficult to change. For instance, community expectations include: - If there is a BOF held and sufficient constituency identified for a working group, the working group must be chartered. - The working group gets to pick at least some of its own chairs. - Charter prose that attempts to scope the working group or dictate how the working group operates is irrelevant once the working group is chartered. - Charter milestones are meaningless (in the sense that they are so poorly defined as to be useless - like publish version -00 of document X) and irrelevant (in that their dates can be ignored). - Certain charter requirements, such as (poorly named) requirements documents, are viewed as meaningless hoops to jump through rather than tools to help the working group refine its scope and better understand its problem. Whenever possible, requirements documents are written _after_ the protocol specification, so that the requirements won't appear inconsistent with the protocol. - Discussion is held and decisions are taken on mailing lists, which are largely unstructured. Any issue can be raised at any time; any argument can devolve into a rathole and continue as long as its participants want until it's explicitly terminated by the chair. - 90% of meeting time consists of powerpoint presentations which may or may not be relevant to the work currently being undertaken by the group. The goal in scheduling the meeting is to allow as many presentations as time permites. Any discussion taken during presentations should consist of questions about the presentations. Time remaining after presentations can be used for discussion, if anyone is still awake. - It's normal and acceptable for meeting participants to occupy themselves during meeting time reading their mail, browsing the web, chatting, or playing games on laptops. Wireless net access is mandatory. - Any document produced by a WG must be considered by IESG, and IESG is required to either approve the document or tell the WG, very specifically, what it takes to fix the document - even if the document violates the terms of the charter. - IESG should provide near-immediate turnaround on a WG's document, no matter how long or poorly written it is. 3. Relatively few working group participants seem to have engineering backgrounds or understand how to use engineering disciplines to straightforwardly develop and refine a specification to the point that there is high confidence that - the goals and
Re: improving WG operation
Keith, We largely agree on most of what is in your note, but let me make a few additional observations... --On Friday, 29 April, 2005 14:49 -0400 Keith Moore moore@cs.utk.edu wrote: Keith, Let me offer a different perspective here as well and, in the process, explain why I keep coming back to the IESG. Going back almost to the dawn of IESG time, the IESG has had one constant and primary responsibility. That is to manage the WGs and the WG process. Under today's rules, they ... Without quoting your entire message, let me say that I do agree at least partially with this. But while at least in theory, IESG has all of the authority and mechanisms it needs to change working group behavior, let me explain why, in practice, I don't think IESG can make the changes that are necessary. There are many things that IESG cannot do with working groups, for a variety of reasons. 1. WG participants are volunteers. For the purpose of this discussion it matters not whether they are volunteering their own personal time and energy or whether their employers are volunteering the time and energy. The ... Now, again, in theory IESG can specify all of this to the Nth degree, and there are occasions where IESG has specified most of these things (one at a time) and made them stick. But it is generally unable to specify most of those things most of the time and make them stick. It's possible to view this as a scaling problem, but I think it's more enlightening to view it as a cultural or education problem. Our culture hasn't developed or accepted the skill set that it really needs to do work on this scale (even though some of the individuals do have engineering skills, and others have intuition that serves them quite well), and our culture has acquired a number of bad habits that are counterproductive. We agree. How do you propose that gets fixed (see below)? So I don't think that IESG is in a good position to fix these problems, even though it is in a good position to implement the fixes once they are understood and accepted by the community. The real trick is getting the community to be willing to change its way of operating, and getting the community to understand that acquiring additional discipline in developing protocols will produce better output more quickly - once we get used to it. Ok, we have gotten ourselves into a bit of a mess in how we handle some things. Whether one agrees with your specific list or not, or with the relative importance of particular points, it is clear that no one (on or off the IESG) can wave a magic wand and make things perfect. It is also clear that at least some of the issues you identify meet my criteria (and Dave's) of having real impacts on the efficiency, timeliness, and quality of our processes and results. Others probably don't. I suggest that whining, bemoaning our fate, generally sitting around being miserable, or even casting blame without identifying solutions, are not only not productive in getting us to better and more timely results, but may actively distract us and divert resources from improvements. It seems to me that there are only three paths out of here: (1) We know there are other standards bodies out there that, by their definitions (although not necessarily by ours) are successful. They have formulas for getting things done, formulas that involve memberships (usually at a price), at least presumed technical qualifications and approval mechanisms for participation in working groups, very specific voting rules at almost every level, including rules about voting by multiple people from one company, institution, or country, and so on. They have very specific management and organizational models and rituals. They also tend to be characterized by very strong professional secretariats who end up doing a lot of the management work that we have assigned to the IESG (or let the IESG accumulate). The IETF community has traditionally had doubts about the quality and/or timeliness of the results from those bodies, but they do manage to get documents out. We could stop what we are doing and emulate them in a greater or lesser number of ways. (2) We know that there are standards-producing consortia out there. The classic version involves a body organized for the benefit of a particular cluster of companies, with rather expensive memberships and participation by people who are not affiliated with those companies only on a very restricted basis. They often have elaborate rules for sharing of intellectual property and about contributions to the consortium as well. (Note that some consortia, by plan or incremental evolution, have started to more strongly resemble the above standards bodies, or other creatures, sometimes even the IETF -- don't get confused by labels). They typically have management arrangements that, among other things, end up dictating their work plans. The IETF community has
Re: improving WG operation
As you know, I'm personally a pretty strong believer in the oh, you haven't read the documents, go to the back of the room and be quiet school of WG meeting leadership. I've gotten a lot of pushback for that, and been called several bad names, but it has never come from the IESG. I'll venture to suggest that anyone who thinks about both the scarcity of meeting time and the aggregate cost of such meeting -- include the cost of the time of the participants -- will agree with you that the meeting needs to focus on deliverables, rather than education. There are, of course, exceptions, but they are just that, exceptional. PowerPoint itself is another issue. I, personally, hate it for IETF WG- like meetings, not because of all of the cliche reasons, but because it discourages real interaction. People can and do use powerpoint slides in many ways. Some folks will rework text in real-time, based on interaction with the participants. Some folks just talk their slides rather than actually engaging with the participants. A thing to keep in mind is that slides and the jabber activity can be incredibly helpful to folks for whom English not their native language. I think that, in fact, the issue is not powerpoint-vs-no-powerpoint. I think it is exactly and only the concern you raise: meetings need to be for working group interaction. If that is the clear goal and if the meeting is run with that goal enforced, then none of the trappings matter. d/ --- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Time to charter (was: Re: improving WG operation (was Re: Voting (again)))
But, again, to even think about that, the IESG is going to need a lot of support and bottom-up direction. John, Let me suggest that there has already been quite a bit of that. It has not been any sort of overwhelming, unified, shout-in-a-single-voice, but there really have been quite a few IETF participants calling for just what you suggest. So far, there have been two problems: As always, the IETF also has lots of voices objecting to any particular proposal. So the ability to achieve any sort of meaningful progress requires much more, ummm... active management than we tend to prefer. (There is a wg chair technique of asserting what the specific consensus is, and then saying that that assertion will hold unless there is rough consensus AGAINST. This is an example of such active management. Of course, that sounds a lot like a wg chair dictating things and it only works if, in fact, the wg group is eager to make forward progress and gives the chair strong support to be assertive in this way.) The IESG has not been willing to take a real leadership role in effective substantive structural or process changes, to address core issues. It has, instead, deferred things to working groups and then mostly ignored them, and it has spent many months focusing on administrative changes. We do not have the sort of cohesive, self-motivating community we had 10+ years ago. We have a community that really does look to the IESG for leadership. After the Kobe revolt, change did come from the grassroots. The IETF leadership merely had to avoid trying to stand in its way. But we do not have that IETF. We have one that is far more diffuse and, therefore, far less cohesive about how to get things done. Absent any other grass-roots effort, real change is going to depend upon the IESG getting serious about it. d/ --- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: improving WG operation (was Re: Voting (again))
John C Klensin [EMAIL PROTECTED] wrote: Going back almost to the dawn of IESG time, the IESG has had one constant and primary responsibility. That is to manage the WGs and the WG process. Under today's rules, they determine or ratify which WGs get created, who chairs them and how they are otherwise managed, what tasks and benchmarks go into charters, how many and which documents a WG can work on at a time (and whether they work on documents serially or in parallel), and when to shut them down. They have _huge_ latitude in how to manage WGs and the decisions they make about that management process, including a wide range of options about reporting, review of benchmarks, actions or the lack thereof when targets are not met, and so on. You've covered an awful lot of territory there: - creating / shutting down WGs -- clearly must be IESG responsibility. - who chairs WG -- feels more like an Area Director responsibility. The IESG should require ADs to report on WG progress; the AD should have the right to deal with WG chairs s/he trusts. - how they are otherwise managed -- whazzat? WG chairs should be responsible to ADs. End-runs around WGCs (other than formal appeals) tend to be harmful. - what goes into charters -- the IESG must take responsibility for the initial charter, but not all updates should need IESG action. - how many documents a WG can work on -- silly-season... Clearly, taking on a new task should be a charter revision, which might require IESG action; but splitting a task between two Document Editors shouldn't even require notice to the AD. - whether documents can be worked on in parallel -- micromanagement. For the AD to specify this would be seriously unwise: for the IESG to even talk about it is a waste of time or worse. WGs, and WG leadership, have no independent existence: the IESG, and under some circumstances, individual ADs can dispose of them as needed. I've never been comfortable with the idea that the IESG can solve a problem by dissolving a WG. That said, there is a clear need for something like a probationary status, where a WG loses (temporarily) its right to submit documents as WG submissions until some defect is corrected; and at some point, actually loses its right to any AD oversight at all. IMHO, surprise dissolutions of WGs are not helpful. Personally, I think that is as it should be. While the community has periodically discussed constraints on WG behavior and management (including one or two that I have written), none have ever been approved: the IESG continues to be able to look at WGs and their work on a case-by-case basis and to make case-by-case decisions. My personal view is that they (the IESG) should have a little more guidance from the community to aid them in making tough decisions and to assure them of backing when such decisions are made, but that wouldn't change the essential nature of the situation very much. I'm not really sure what the community _could_ do to offer much guidance here; and I don't think community support of IESG decision has much meaning. The question is whether an IESG action is going to result in a long-winded appeal process; and there's remarkably little that anyone can do about that. But, from that perspective, there is no WG problem or problem WG. There is only an IESG management problem. Either the number and complexion of WGs is such that the IESG can manage them effectively, or it isn't. If it isn't, only the IESG can be responsible. Except that I see the bottleneck at the AD/WGC interface, I agree. Either WGs are sufficiently well chartered and managed so that the review processes we have work adequately well or they aren't. Either way, the IESG bears ultimate responsibility: they determine the charters, the management structure, the review requirements or lack thereof at various intermediate points, and so on. I'm not sure it's helpful to look at it that narrowly. I think I quite agree with John Klensin that if charters, structure, and review requirements are done right, corrective actions will become obvious. I don't agree, however, that our selection process for IESG members does anything to ensure sufficient expertise to get charters, structure, and review requirements right on the first try. I think we need a mechanism to notice that something needs correction, and get independent review of charters, structure, and review requirements when problems appear. Now, it is reasonable to say the IESG doesn't have bandwidth to do that job well and still review documents for standardization. Certainly a reasonable question: but I don't choose to give an opinion on it at present... But it doesn't seem to me that saying we have all of these out of control WGs and need to concentrate on fixing them and not on looking at the IESG or even focus our attention on WG operation is productive: if the WGs are not under control, then,
technical supervisors (was: improving WG operation)
wow...I keep wanting to make terse replies, but there never seems to be a way to address the subject with a short answer. I'm sorry you see these explanations as whining. I believe that we have to recognize that part of our problem is how WGs operate before we can be willing to solve that problem. So I try to describe that problem in a way that people will recognize it. Maybe people already realize that we have this problem and I don't actually need to illustrate it. As for solutions - I have been thinking about possible solutions for several years. But I'm much better at protocol engineering than I am at engineering management or social structures, so I don't have much confidence in my ideas for how to solve the problem. Recently I've begun to suspect that a good answer to some of these problems might involve a layer of management between IESG and working groups - a set of people who had responsibility to give some technical oversight to working groups, monitor their progress, and keep the ADs up-to-date on the state of things. I say oversight rather than direction because direction would be too strong a term. I don't see the supervisor (let's call him a supervisor for now) telling the group what technical decisions to make. I do see the supervisor making sure that the group investigates important issues - setting short-term milestones and an agenda for the group. What I'm thinking is that the person in charge of supervising a WG ends up consulting with the chair and/or document authors on a regular basis (say, every three or four weeks) and agreeing on the next set of near-term goals and deliverables for that WG. The supervisor might say you need to understand and document the nature of the disagreement between these two concerns or you need to pick a mandatory-to-implement encryption algorithm, or you need to solicit cross-area review for this issue or you need to analyze whether this ABNF grammar can be implemented with only one symbol of look-ahead or defer that question for now, the thing you have to decide before you do anything else is how much you are going to constrain yourself to be backward compatible with this legacy protocol that we all know is broken. As I see it, the supervisor would offload some of the present Chair's duties and some of the present Responsible AD's duties. The chairs would still be responsible for managing the group discussion and making sure process rules were followed. The ADs would still approve charter changes (overall goals, long-term milestones), review documents before publication, and be the first level of appeal. The supervisor would try to make sure that important issues were identified and dealt with early, and in plenty of time to get them resolved before the specification is finalized; he would also make sure that measurable progress was being made every few weeks and report progress or lack thereof to the AD. Another part of the supervisor's job would be to ensure that when the document finally goes to IESG, neither the WG nor the IESG are surprised by how the other reacts to it. Along with the specification presented to IESG should be supporting material to give the IESG confidence in the document, for example: a list of goals and requirements (written before the specification); a list of changes to those goals and requirements with the rationale for each change; a list of issues and contentious design choices that arose, how each was resolved, and why; what kinds of review the specification was subjected to, the results of that review, and what changes (if any) were made based on that feedback; documentation of any analysis that was done on the protocol; description of early implementations (prototypes) and how they differ from the final specification. This material would take the place of the writeup that an AD is now expected to do before a document from his working group goes to IESG ballot. Similarly for face-to-face meetings - the Chair would preside, but the supervisor would work out the agendas of face-to-face meetings in consultation with the Chair. The meeting time would be used to reach closure on divisive issues. The supervisor would be expected to NOT have a strong interest in the outcome of the WG (other than to see that quality work is done), nor to closely follow or regularly participate in group discussion. His job would be to keep a higher-level perspective on things. When identifying issues that must be resolved he could state an opinion but must clearly separate his opinion from the description of the issue. WGs would be allowed to push back on an issue definition if they thought it unreasonably constrained the resolution, and suggest an alternate way of framing the issue. The concept of Technical Supervisors could be tried on two or three working groups and refined based on experience. Initially the supervisors might be appointed by the AD and
improving WG operation (was Re: Voting (again))
On Apr 28, 2005, at 2:12 AM, John Loughney wrote: Keith, You've raised these points, over a number of years, but I wonder if it would be useful to explore implications of some of your comments: 2. IESG's scaling problems are a direct result of low-quality output from working groups, and we can't do much to address that problem by changing how IESG works. 3. I don't think we can make IESG significantly larger, I don't think we can dispense with final document review and keep document quality up, and I don't think that additional reviewers can signficantly relieve IESG of the need to do final review. I do think that additional reviewers could be very valuable in giving WGs feedback from early drafts, keeping them on the right track, and keeping IESG informed about the status of the WGs. I also think that a document that has enjoyed such review and feedback throughout its life cycle will be much easier for IESG to review, and that (without any changes to IESG's organization or process) it will be harder for IESG to reject such documents without sound technical justification. Here, in the Problem WG and other places, you've raise the point that increasing the IESG probably won't help. You've implied that we probably have too many working groups and too many drafts in the working groups. The implications of these are that the IETF has too much work in too many areas to be effective. I believe the IETF could perhaps take on more work if it improved the process by which working groups operate. This would lessen IESG's burden by giving them better documents to work with; it might also reduce the average duration of a WG, making more room for others. The industry wouldn't mind that either. One of the problems that some WGs have is that they take on too many drafts, which both hinders the ability of the working group to finish its more important work and imposes additional burdens on IESG. I also think that IETF could use its resources more effectively if it exercised more care about which working groups it chartered. For instance, IMHO we've wasted a lot of effort trying to come up with short-term workarounds for NATs, without any of them providing a migration path away from NATs. If I understand some of Dave's and John K's comments, they are willing to entertain thoughts on how to do things better ( differently) in order to ensure that the IETF remains relevant. As am I. But I would like to see attention focused on working group operation, which I believe is our biggest source of problems. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: improving WG operation (was Re: Voting (again))
Keith, Let me offer a different perspective here as well and, in the process, explain why I keep coming back to the IESG. Going back almost to the dawn of IESG time, the IESG has had one constant and primary responsibility. That is to manage the WGs and the WG process. Under today's rules, they determine or ratify which WGs get created, who chairs them and how they are otherwise managed, what tasks and benchmarks go into charters, how many and which documents a WG can work on at a time (and whether they work on documents serially or in parallel), and when to shut them down. They have _huge_ latitude in how to manage WGs and the decisions they make about that management process, including a wide range of options about reporting, review of benchmarks, actions or the lack thereof when targets are not met, and so on. WGs, and WG leadership, have no independent existence: the IESG, and under some circumstances, individual ADs can dispose of them as needed. Personally, I think that is as it should be. While the community has periodically discussed constraints on WG behavior and management (including one or two that I have written), none have ever been approved: the IESG continues to be able to look at WGs and their work on a case-by-case basis and to make case-by-case decisions. My personal view is that they (the IESG) should have a little more guidance from the community to aid them in making tough decisions and to assure them of backing when such decisions are made, but that wouldn't change the essential nature of the situation very much. But, from that perspective, there is no WG problem or problem WG. There is only an IESG management problem. Either the number and complexion of WGs is such that the IESG can manage them effectively, or it isn't. If it isn't, only the IESG can be responsible. Either WGs are sufficiently well chartered and managed so that the review processes we have work adequately well or they aren't. Either way, the IESG bears ultimate responsibility: they determine the charters, the management structure, the review requirements or lack thereof at various intermediate points, and so on. I think we agree at least partially on this, because I certainly endorse the position that we could use resources more effectively if [we] exercised more care about which working groups [were] chartered. But, again, the IESG makes those decisions: all the community can do, at least under the current structure, is to give them advice and feedback, both about individual proposed WGs and charters and about keeping the totals tolerable. But they are chartered to decide, and, if they don't get it right, the problem belongs to them, not to the participants in an ill-advised WG. That isn't an easy job by any means. I assume that, for every WG we have, there are at least a handful of members of the community who believe that WG contains the most important work the IETF is doing. But someone has to start making those hard decisions and, as responsibilities are now handed out and groups chartered, the IESG is the lucky group. Now, it is reasonable to say the IESG doesn't have bandwidth to do that job well and still review documents for standardization. But that statement doesn't fix the WGs. It might be justification for moving document review to some other body --presumably not delegated by the IESG but selected by the Nomcom to fulfill that role. Or it might be justification for the IESG shrinking back the number of WGs to the point that they did have time and bandwidth to do both jobs well (and maybe even have lives and day jobs). Or we might think about a management structure that shifts the IESG's historical management function wrt WGs elsewhere. But it doesn't seem to me that saying we have all of these out of control WGs and need to concentrate on fixing them and not on looking at the IESG or even focus our attention on WG operation is productive: if the WGs are not under control, then, IMO, the IESG, as the body with the management responsibility, needs to acknowledge that fact and then either needs to fix it or make suggestions to the community as to how we can fix it together. If they are not convinced that working group operations is the problem, then there is either no problem or an IESG problem. john --On Thursday, 28 April, 2005 09:17 -0400 Keith Moore moore@cs.utk.edu wrote: I believe the IETF could perhaps take on more work if it improved the process by which working groups operate. This would lessen IESG's burden by giving them better documents to work with; it might also reduce the average duration of a WG, making more room for others. The industry wouldn't mind that either. One of the problems that some WGs have is that they take on too many drafts, which both hinders the ability of the working group to finish its more important work and imposes additional burdens on IESG. I also think that IETF could use its resources more effectively if it
Re: improving WG operation (was Re: Voting (again))
I certainly endorse the position that we could use resources more effectively if [we] exercised more care about which working groups [were] chartered. But, again, the IESG makes those decisions: More care about chartering is cited periodically, and I agree that it is needed. But we seem able to get neither a clear, concrete sense of what it means to use more care, nor the community resolve to pursue it. Not really. On John's latter point that the IESG makes those decisions, I suggest that it is at the core of at least two serious problems: One is that is abrogates the community's responsibilities and the second is that it guarantees that the IESG remains overburdened. More and more, we see the general IETF community lacking a sense of responsibility for the health and utility of the IETF. Well, how can we feel responsible if we are disenfranchised? That is what it means to have others making the important decisions. The more we march down the path of having a classic, hierarchical authority structure, the more the IETF looks and acts like any other stiff, bureaucratic, unproductive standards group. The IETF's origins in rough consensus translated into community action and community responsibility. That goes directly against the idea that it is some elite oligarchy's authority to make the decisions. There is a long way between the highly centralized authority structure we now have, and the mayhem of an extreme literal democracy, where everybody 'votes' on everything. But the original style of the IESG was to facilitate processes of developing community consensus. Such a description is fundamentally at odds with a model that has that the IESG have primary authority for making the decisions. On the question of burden, the issue is simple: ADs often feel sufficiently essential, to what they view as the necessary details of an outcome, that they are more and more inclined to inject themselves into it. (One of the more poignant examples of this is when an AD gets sucked into ensuring quality by participating in the working group as if they were a primary technical contributor. At that point they are an individual advocate for particular details, and they cease to be able to perform their higher-level job of oversight.) Others in this thread have cited the IESG's job as assessing community consensus. This, I think, should be viewed as the core job of the IESG: coordinating macro processes based on assessments of community rough consensus (and looking for ways to develop it.) After all, any successful output from the IETF depends upon community adoption. In that regard, the rough consensus model is really the process of acquiring community ownership of the output, with the expectation that the ownership makes it more likely they will actually use it. Take away real community involvement in the decision and we lose the benefit of facilitating adoption. For all this, the technical expertise of an AD remains extremely important, but not as the basis for an AD decision. Rather, it permits the AD to see problems and recruit community concurrence that there is a problem. The AD may well have insight to its solutions, but frankly that should be viewed as an unexpected benefit. Good ideas come from lots of places; as good as any particular AD might be, no one can expect that they will have special insight that is better than all others. Yet today we almost require it. Certainly the recent structure and history of IETF process trains ADs to view their personal preferences as being an ultimate authority. That is, after all, what the power of a veto communicates. If an AD is unable to recruit rough consensus to their view, then what exactly is the benefit of their being given a veto? d/ --- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
