From problem-statement-bounces@alvestrand.no Tue Jul 1 00:25:55 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01139 for ; Tue, 1 Jul 2003 00:25:54 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0E9B8625DA; Tue, 1 Jul 2003 06:25:23 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from conure.mail.pas.earthlink.net (conure.mail.pas.earthlink.net [207.217.120.54]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5A9456230D for ; Tue, 1 Jul 2003 06:25:20 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by conure.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19XChX-000677-00; Mon, 30 Jun 2003 21:25:07 -0700 Date: Tue, 1 Jul 2003 00:21:27 -0400 From: Keith Moore To: avri Message-Id: <20030701002127.14887d72.moore@cs.utk.edu> In-Reply-To: References: <70696325.1057000829@p3.JCK.COM> X-Mailer: Sylpheed version 0.9.1 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: john-ietf@jck.com Cc: problem-statement@alvestrand.no Cc: moore@cs.utk.edu Subject: Re: appeal mechanisms was Re: Ombuds-process X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit ] > Mumble. Ok, I have filed an appeal, and it was successful in getting ] > an action changed. ] ] And you are most definitely not a regular participant and are most ] adept at the processes of the organization. You also have excellent ] command of the english language. And due to long term association ] with the I* know exactly what is relevant and what is not. You also ] share a cultural similarity to the majority of those who read and ] adjudicate the appeals. ] ] the fact that you think this is trivial easy and that anyone can do what you ] can do is indeed a significant part of the problem in my opinion. Those of ] us who can command the language to do what we want it to do (well I don't ] always succeed) and those of us who can play the process game, often think ] that everyone can do what we can do. It is not the case. Nobody has claimed that eloquence is necessary; it may even be a hinderance. For better or worse, IETF mostly communicates in English. Yes, this is a barrier to those who do not speak English well, but this problem is not limited to appeals. The cultural biases are harder to see for those of us who have been in the organization a long time (and for those of us who adapted to it quickly). if someone could help make the assumptions of "IETF culture" more explicit this would be a valuable contribution. Again, these biases cause problems in every area of IETF, not just appeals. Though I could understand a view that it's even more important to be considerate of such differences when evaluating appeals (and in my experience IESG has tried to do that). ] > Step 1: Produce a coherent and focused statement about ] > what is being appealed, what the issues are, and why the ] > action that was taken was wrong. Leave out any random ] > musings or accusations about, e.g., the eating habits or ] > parentage of IESG members and assumptions about their ] > evil motivations. This is often not an easy writing ] > job, but it is necessary. For better or worse, if the ] > IESG and IAB can't figure out what you are complaining ] > about, or if the appeal seems to be an excuse for a ] > personal attack, the appeal won't go anywhere unless the ] > problem is really, obviously, an abuse of judgment or ] > authority. ] ] Coherency is a value laden judgment and is often difficult for people. ] What is a lack of coherence to one is lack of understanding to another. ] I have often found that it takes me a lot of work to find the coherency ] in an argument. And the fault is often mine. If I look at the world ] one way, and the writer looks at it another, the language may be such that ] the beauty and coherence of the argument is lost on me. Simple statements are usually better. Yes, it often does take a lot of work to construct them, accustomed as we are to obsfucation. And there is the problem of knowing how much background to include, where failure to provide background can be taken as indication of a lack of expertise. But I don't think the purpose of an appeal is to compensate for the appellant's inability to explain a problem to a working group, and neither do I think we can expect those evaluating the appeal to read the appellant's mind. So we must ask the appellant to do the best he can to state his case, and ask the reviewing body to do the best it can to understand it, and hope this is sufficient. ] And sometimes a complaint is covered by some vitriol that is emotionally ] justifiable as it does happen that sometimes WG chairs and AD are not ] paragons of impartiality and virtue - even though I know we try to ] claim that all problems are systemic and have nothing to do with the people ] themselves or human nature. And yes, it would be better if they could ] put all hard feelings aside and write like lawyers but sometimes they ] can't. So, underneath there may be a real issue that requires a real ] solution and to ignore it would do harm to the complainant and sometimes ] even to the Internet itself. Indeed, and we should try to judge the appeal on its merits no matter how vitriolic it is. But it never hurts to make the appeal as clear and free from distractions as possible. ] These questions are indeed part of my reason for believing that the ] IETF needs some mechanism to make sure that all valid ] complaints do get a just and complete airing. I don't know of a better way to do this than to entrust this to the judgement of experts who have a wide range of expertise (reflecting the range of technical interests in the Internet) and who been carefully screened before being appointed to this job. ] > Step 2: Be absolutely clear about what remedy is desired ] > and expected, and be sure that it is within the ] > authority of the AD or IESG to grant and execute. ] > Leaving the IAB or IESG sitting around and saying to ] > each other "well, she is probably right, but what on ] > earth does she want us to do about it?" is not likely to ] > produce a useful and positive outcome. ] ] I also question whether the appellant must also have the solution. Agreed, but solving the underlying problem and recommending a remedy for the appeal are not the same thing. Indeed, this is one of the problems that makes an AD's job so difficult - he is expected to not merely object to something that's broken, but also to explain what it takes to fix it. So I'm very sympathetic to the notion that this is too much to ask of the appellant. (of course, that puts the burden back on IESG again...) But IMHO the appellant still has a burden to suggest a remedy, whether that be "don't approve this as Proposed" or "publish as Experimental" or "remand this to the working group for consideration of X" or whatever. Otherwise IESG is left to just guessing; it might struggle to justify a remedy of its own choosing far more onerous than that which would satisfy the appellant, or it might assume that a small correction would satisfy everyone when the appellant believes that a much larger correction is necessary (perhaps resulting in another, unnecessary, appeal). ] I think it is is incumbent on those resolving appeals to find the underlying ] problem. Or rather it is the responsibility of the IETF leadership, in some ] way and form, to make sure that the underlying issue is always brought ] forward. Well, it's certainly *somebody's* (not always the IETF leadership's) responsibility to bring these issues forward before a harmful decision is made. But one reason we have appeals is that we assume that there will occasionally be failures to carry out these responsibilities - whether by the IETF leadership, the WG leadership, or the rank and file. ] > This isn't either a complex procedure or rocket science... it is just ] > recognizing that presenting a clear case to the IESG and IAB is much ] > more likely to get careful attention and reasonable results. ] ] I disagree. Construction of a valid appeal is a complex problem for ] many. To the extent this is the case, I think it's mostly because clear communication is a complex problem for many, and I don't see what we can do about that. Of course an appellant is free to enlist the aid of others (maybe even SIRs) to help him make his case more clearly. ] And the process with its nuance of who get which appeal when and in ] which order can run people ragged. Actually I agree with this; in particular the procedures seem to assume that appeals will generally result from improper WG decisions, so it's fairly unclear how to apply them to AD decisions, IESG decisions, or other actions. ] I would really be interested in an analysis of the number of appeals that ] have been brought forth in last years, the number of successful ones and the ] reasons formally given for the unsuccessful ones. >From the appeals I've seen, I suspect such statistics would be meaningless. You need to evaluate the appeals on their merits. Keep in mind that appeals are disproportionally often (not always) raised by individuals who are unable to gain any significant support for their views, whether because of their social ineptitude, inability to express themselves clearly, inability to think clearly, or their inability to understand the technical issues. Of course the appeals must be evaluated on their merits (difficult though they may be to understand) regardless of who is raising them. But it's not reasonable to presume that a significant percentage of appeals are valid. From problem-statement-bounces@alvestrand.no Tue Jul 1 03:00:21 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16488 for ; Tue, 1 Jul 2003 03:00:20 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9A83C6256C; Tue, 1 Jul 2003 08:59:47 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from thunker.thunk.org (thunk.org [140.239.227.29]) by eikenes.alvestrand.no (Postfix) with ESMTP id ED06A6230D for ; Tue, 1 Jul 2003 08:59:45 +0200 (CEST) Received: from [66.92.109.27] (helo=think.thunk.org) authenticated as tytso by thunker.thunk.org with asmtp (tls_cipher TLSv1:DES-CBC3-SHA:168) (Exim 3.35 #1 (Debian)) id 19XF6z-00087o-00; Tue, 01 Jul 2003 02:59:33 -0400 Received: from tytso authenticated as tytso by think.thunk.org with local (Exim 3.35 #1 (Debian)) id 19XF6y-0007l2-00; Tue, 01 Jul 2003 02:59:32 -0400 Date: Tue, 1 Jul 2003 02:59:32 -0400 From: "Theodore Ts'o" To: Keith Moore Message-ID: <20030701065932.GB29772@think> References: <70696325.1057000829@p3.JCK.COM> <20030701002127.14887d72.moore@cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030701002127.14887d72.moore@cs.utk.edu> User-Agent: Mutt/1.5.4i Cc: john-ietf@jck.com Cc: problem-statement@alvestrand.no Cc: avri Subject: Re: appeal mechanisms was Re: Ombuds-process X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no On Tue, Jul 01, 2003 at 12:21:27AM -0400, Keith Moore wrote: > ] I would really be interested in an analysis of the number of appeals that > ] have been brought forth in last years, the number of successful ones and the > ] reasons formally given for the unsuccessful ones. > > From the appeals I've seen, I suspect such statistics would be > meaningless. You need to evaluate the appeals on their merits. > Keep in mind that appeals are disproportionally often (not always) > raised by individuals who are unable to gain any significant support > for their views, whether because of their social ineptitude, > inability to express themselves clearly, inability to think clearly, > or their inability to understand the technical issues. Of course > the appeals must be evaluated on their merits (difficult though they > may be to understand) regardless of who is raising them. But it's > not reasonable to presume that a significant percentage of appeals > are valid. I need to second this, strongly. Just because people are complaining doesn't mean that their complaints are valid. There *are* crackpots that attempt to participate in the IETF process, and while it will take a value judgement to decide whether their complaints are real, or are the products of a diseased mind, it is critical that we do so. If we make a process which is overly solicitous to all who complain, the net result may be far worse than if a few marginal complaints are not taken seriously because the author of the complaints happens to be incapable of expressing himself properly. - Ted From problem-statement-bounces@alvestrand.no Tue Jul 1 08:14:35 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12222 for ; Tue, 1 Jul 2003 08:14:30 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3B567621FA; Tue, 1 Jul 2003 14:13:59 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by eikenes.alvestrand.no (Postfix) with ESMTP id C68C761A93 for ; Tue, 1 Jul 2003 14:13:56 +0200 (CEST) Received: from [209.187.148.215] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.10) id 19XK1C-000O8n-00; Tue, 01 Jul 2003 07:13:54 -0500 Date: Tue, 01 Jul 2003 08:13:53 -0400 From: John C Klensin To: avri Message-ID: <117099670.1057047233@p3.JCK.COM> In-Reply-To: References: X-Mailer: Mulberry/3.1.0b3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: "problem-statement@alvestrand.no" Subject: Re: appeal mechanisms was Re: Ombuds-process X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit --On Tuesday, 01 July, 2003 09:42 +0900 avri wrote: >>> i certainly do not believe the existing process is a >>> mechanism that aids people in making appeals. >> >> Mumble. Ok, I have filed an appeal, and it was successful in >> getting an action changed. > > And you are most definitely not a regular participant and are > most adept at the processes of the organization. You also > have excellent command of the english language. And due to > long term association with the I* know exactly what is > relevant and what is not. You also share a cultural > similarity to the majority of those who read and adjudicate > the appeals. > > the fact that you think this is trivial easy and thatanyone > can do what you can do is indeed a significant part of the > problem in my opinion. Those of us who can command the > language to do what we want it to do (well I don't always > succeed) and those of us who can play the process game, often > think that everyone can do what we can do. It is not the case. Avri, I didn't say, and didn't mean to suggest, that there was anything trivial about it. I even said "This is often not an easy writing job, but it is necessary". And I understand that, for a non-native speaker of English, it may be exceptionally hard. But this really is an IETF community matter. If someone who wants to make an appeal finds the writing difficult, find someone else who might agree, get him or her to help with the writing, and then launch a joint appeal. If no one else can be found, it is questionable whether the IESG will be persuaded either. I have, personally, spent a good deal of time working with authors to improve the presentation and clarity of statements and I-Ds which I consider important -- sometimes many weeks on a single draft and occasionally even on drafts with which I disagree technically -- before, during, and after my time on the IESG and IAB. I don't think I am unique in that regard. [Excursion toward solution-space: as with recalls, there is a case to be made that appeals should be required to have at least a few "endorsers" or co-sponsors before getting past the "discussion with AD" or "discussion with IETF Chair" stages. The problem with presentation and "playing the process game" you identify points out what might be an additional advantage of that approach, since trying to gather endorsers might well gather up people who could help with presentation and process and would give them an extra incentive to help. On the other hand, it does raise the bar a bit.] Further, with regard to "playing the process"... _Any_ process can be "played", and some will be better at it than others. Even if we abandoned an appeal model and permitted anyone who could stand up and shout "I disagree" and thereby force an additional review (a terrible idea, but, perhaps, a useful example), some people would be better at shouting, while others --by personality or cultural norms-- would be reluctant to call that much attention to themselves. What, IMO, we should strive for is a process whose workings are sufficiently clear and public to make it usable by those who are not "insiders". How do we do that? I think we need to look as much at education about how the process actually works in practice and how to "work" it as to changing it for the sake of change. My note, which you believe is a symptom of the problem, was an attempt to help with exactly that explanation problem. I don't know how often it has been said explicitly, but it has long been understood within the IESG and IAB that appeals that are incoherent and that lack clear statements of requested remedies are unlikely to be useful. That doesn't imply they aren't considered carefully -- I have been amazed and pleased by the amount of time and energy both groups have put into trying to understand and respond carefully to appeals, even (or especially) the incoherent ones. But they are less likely to be "successful", largely because no one can figure out what "success" means (or what was intended by the author). So, now, with Keith's supplement to my not (with which I agree) I hope that the process is a bit less opaque and requires a bit less inside knowledge and, hence, "process working" skills, than it did before. I would have hoped that would have been considered progress and a positive move. Why haven't the IAB or IESG written those "steps" up as an I-D? I don't know. Perhaps one reason is that those steps look to them like common sense. Perhaps that is a misjudgment, especially when compared to cultural contexts in which it is normally inappropriate to ask for something in a direct way. If so, that is a problem/issue and someone should try to take on a writing job... and, if it is useful, my few paragraphs and Keith's might be a starting point for a draft. >> I've also been in the middle of the IAB review process for >> several of them. So, with your indulgence (I don't think >> this is a problem, and what I'm about to say isn't a >> solution), let me explain how to mount a successful appeal >> so it isn't a secret any more. >> >> Step 1: Produce a coherent and focused statement about >> what is being appealed, what the issues are, and why the >> action that was taken was wrong. Leave out any random >> musings or accusations about, e.g., the eating habits or >> parentage of IESG members and assumptions about their >> evil motivations. This is often not an easy writing >> job, but it is necessary. For better or worse, if the >> IESG and IAB can't figure out what you are complaining >> about, or if the appeal seems to be an excuse for a >> personal attack, the appeal won't go anywhere unless the >> problem is really, obviously, an abuse of judgment or >> authority. > > Coherency is a value laden judgment and is often difficult for > people. What is a lack of coherence to one is lack of > understanding to another. I have often found that it takes me > a lot of work to find the coherency in an argument. And the > fault is often mine. If I look at the world one way, and the > writer looks at it another, the language may be such that the > beauty and coherence of the argument is lost on me. I think we all have that problem, albeit possibly to different degrees. Some philosophers and linguists have, of course, argued that it is fundamental to human communications. In an IETF context, one remedy is a bit of discussion about whether an appeal is required and rational and whether one's understanding and presentation of the issue are adequate. Perhaps I should have included a "step 0", which might have been Discuss the perceived issue with colleagues and get their opinions as to whether the issue is worth appealing and, if so, what the key issues in the appeal really are. Again, if you can't convince anyone that the appeal is desirable, you probably won't be able to convince the IESG or IAB either. Speaking from personal experience, that has happened to me several times: I've seen actions that I am convinced are inappropriate or unjust, have contemplated filing an appeal, have discussed it with others, and have ultimately concluded that the amount of trauma associated with an appeal would not by justified by the possible outcome or remedy. Of course, one can't win sometimes -- I've been accused of abusing authority, or my "power" as a member of some in-group, by raising the possibility of an appeal and then not following through by actually initiating one. > And sometimes a complaint is covered by some vitriol that is > emotionally justifiable as it does happen that sometimes WG > chairs and AD are not paragons of impartiality and virtue - > even though I know we try to claim that all problems are > systemic and have nothing to do with the people themselves or > human nature. And yes, it would be better if they could put > all hard feelings aside and write like lawyers but sometimes > they can't. So, underneath there may be a real issue that > requires a real solution and to ignore it would do harm to the > complainant and sometimes even to the Internet itself. We are in complete agreement about this. I just don't see a process change --as distinct from a human nature change-- that would fix it... although discussion with colleagues and a bit of group effort in shaping the appeal might, again, help. > These questions are indeed part of my reason for believing > that the IETF needs some mechanism to make sure that all valid > complaints do get a just and complete airing. Again, I think we agree about this. I am just hesitant about piling on more process. And, as a reminder, my note wasn't about the belief that better ways to get valid complaints aired were unnecessary. I think they are necessary (although, personally, I hope they can be done informally -- perhaps using some of the methods hinted at above-- rather than requiring a new position with a potentially-complex authority relationship with the IESG). >> Step 2: Be absolutely clear about what remedy is desired >> and expected, and be sure that it is within the >> authority of the AD or IESG to grant and execute. >> Leaving the IAB or IESG sitting around and saying to >> each other "well, she is probably right, but what on >> earth does she want us to do about it?" is not likely to >> produce a useful and positive outcome. > > I also question whether the appellant must also have the > solution. Often one see something and 'knows' it is wrong, > but does not know the right solution. Or may have a valid > complaint but an invalid solution. Is the complaint therefore > worthless? And should the problem be ignored in that case? And the current procedures don't require that a proposed remedy be stated, perhaps for that reason. But I dread --and my perception has been that the IESG and IAB dread-- getting into a situation in which the proper response to an appeal is "Yes, we agree that Vlad is an often-abusive character who isn't gentle with those who disagree with him. So?" I also deliberately said "remedy" and not "solution". Suppose we have an appeal whose substance is "the solution the WG came up with is bad, because..., and doesn't really represent consensus, so the IESG shouldn't make it a standard". "XYZ should be the standard instead" might be a "solution", but the IESG would be on thin ice if it substituted its protocol judgment (and that of the appeal) for that of the WG. By contrast, "the IESG should return this matter to the WG, insist that it reconsider the technical matter and gets its act together procedurally, and consider whether the current chair is the right person to steer that process". That is a "remedy" for the particular problem -- it doesn't require knowing the solution. >> That is really all there is to it. Most, if not all, of the >> appeals that have dragged out for a long time and then >> produced results that either upheld the IESG in some >> lukewarm way or were satisfactory to no one showed symptoms >> consequent of omitting one of the steps above. If the IAB >> (or even the IESG) get an appeal that says "the problem is >> obvious, you can read all about it on the following 400 web >> pages and many megabytes of logs, AD Jones is a fool and has >> it in for me, and I'd like you to un-invent the wheel so I >> can patent it", that appeal probably isn't going anywhere >> even if the underlying issue is a problem that really does >> need fixing. > > Have there really been that many appeals asking that the wheel > be un-invented? There have not been that many appeals, total. But a non-trivial fraction of them have seemed to ask for turning back the clock and having a WG start over with a different set of assumptions and none of the intervening experience and discussions. That isn't ultimately much different from wanting to un-invent the wheel -- the same collective time machine or similar process would be needed. > I think it is is incumbent on those resolving appeals to find > the underlying problem. Or rather it is the responsibility of > the IETF leadership, in some way and form, to make sure that > the underlying issue is always brought forward. And I think that, in some cases at least, imposing that requirement on the "leadership" requires that they learn to read minds to understand the real intent of the appeal. I don't think that is a reasonable requirement. Worse, given the small number of people in the community who I think Keith referred to as "disturbed personalities", it increases the possibility of appeals as DoS attacks: I can imagine a cycle in which the IESG and IAB make a guess at the underlying issue and process the appeal, only to be faced with a second appeal whose substance is "you guessed wrong about the underlying issue, guess again". Everyone loses in such a process -- especially those who are trying to get unrelated work through the IESG or IAB. Regardless of how we characterize overload or the absence thereof, there really are only so many IESG or IAB cycles available in a given month, and appeals, handled carefully, take up a lot of them. >> This isn't either a complex procedure or rocket science... it >> is just recognizing that presenting a clear case to the IESG >> and IAB is much more likely to get careful attention and >> reasonable results. > > I disagree. Construction of a valid appeal is a complex > problem for many. And the process with its nuance of who get > which appeal when and in in which order can run people ragged. Again, if the function of some sort of Ombuds-process is to help people understand whether an appeal if plausible and to help in framing it if it is, then we are probably in agreement that one is needed. My only concerns on that front are that the level of topical understanding needed is such that one might require one or two such people per area, not just one for the IETF. And I think it is better done informally, precisely to encourage people to "shop" for a sympathetic listener. But those are issues about possible solutions. If the problem statement can be kept to "the appeals process is less effective than it should be because some people need assistance in preparing and shepherding effective appeals", I'd be in complete agreement with it. regards, john From problem-statement-bounces@alvestrand.no Tue Jul 1 08:21:26 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13512 for ; Tue, 1 Jul 2003 08:21:25 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E913A622A1; Tue, 1 Jul 2003 14:20:55 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by eikenes.alvestrand.no (Postfix) with ESMTP id B678461A93 for ; Tue, 1 Jul 2003 14:20:53 +0200 (CEST) Received: from [209.187.148.215] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.10) id 19XK7x-000OAI-00; Tue, 01 Jul 2003 07:20:53 -0500 Date: Tue, 01 Jul 2003 08:20:53 -0400 From: John C Klensin To: avri Message-ID: <117518632.1057047653@p3.JCK.COM> In-Reply-To: References: X-Mailer: Mulberry/3.1.0b3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: "problem-statement@alvestrand.no" Subject: Appeal records (was: Re: appeal mechanisms was Re: Ombuds-process) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit (Separating this off into a separate thread) --On Tuesday, 01 July, 2003 09:42 +0900 avri wrote: > I would really be interested in an analysis of the number of > appeals that have been brought forth in last years, the number > of successful ones and the reasons formally given for the > unsuccessful ones. Is a formal record kept of all appeals and > the deliberation on those appeals? Are those records open and > readily available to the IETF participants? I doubt that such records exist in a form that would be amenable to statistical analysis. Certainly the _decisions_ of the IAB on appeals have been public and, as far as I can recall, have always been recorded on the IAB's web pages. But keep in mind that the absolutely most effective of appeals are those in which someone has a semi-informal discussion with an AD or the IETF Chair, is persuasive about the subject, and gets a "yes, we should have thought of that, let me fix it" response... or is persuaded that the appeal-topic really isn't an issue. Those are the most successful of appeals in terms of quick action and minimal disruption, but they aren't likely to be recorded anywhere. The ones that actually get formal IESG or IAB action represent either process failures or irrational complaints and are unlikely to produce results --"successful" or not that are completely satisfactory to anyone. john From problem-statement-bounces@alvestrand.no Tue Jul 1 11:12:03 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03985 for ; Tue, 1 Jul 2003 11:12:02 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 92A5E621FB; Tue, 1 Jul 2003 17:11:32 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by eikenes.alvestrand.no (Postfix) with ESMTP id D041F621FA for ; Tue, 1 Jul 2003 17:11:30 +0200 (CEST) Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h61FBPg5002902; Tue, 1 Jul 2003 11:11:25 -0400 (EDT) Message-Id: <200307011511.h61FBPg5002902@rtp-core-1.cisco.com> To: Keith Moore In-reply-to: Your message of Mon, 30 Jun 2003 11:06:52 -0400. <20030630110652.7ff385eb.moore@cs.utk.edu> User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Tue, 01 Jul 2003 11:11:25 -0400 From: Eric Rosen Cc: problem-statement@alvestrand.no Subject: Re: appeal mechanisms was Re: Ombuds-process X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list Reply-To: erosen@cisco.com List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Keith> But whenever a WG submits a document that the WG's AD doesn't like, Keith> in most cases this is because the WG has failed to get broad Keith> consensus on a document. Well, I understand that that's your story and you're sticking to it. But can you provide a reason for anyone to believe this? Or do you mean it to be a tautology, i.e., "broad consensus" means "the AD likes it"? Keith> to some degree engineering judgement is and must be subjective, so it Keith> may be perfectly valid for an AD to reject a document on such Keith> grounds. In areas where different engineers might reasonably come to different judgments, it is not appropriate for the IESG to substitute its own judgment for the WG consensus. From problem-statement-bounces@alvestrand.no Tue Jul 1 11:37:58 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04772 for ; Tue, 1 Jul 2003 11:37:58 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 42EF8621FB; Tue, 1 Jul 2003 17:37:28 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from swan.mail.pas.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by eikenes.alvestrand.no (Postfix) with ESMTP id F0404621B8 for ; Tue, 1 Jul 2003 17:37:26 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by swan.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19XNBt-0005dp-00; Tue, 01 Jul 2003 08:37:09 -0700 Date: Tue, 1 Jul 2003 11:33:27 -0400 From: Keith Moore To: erosen@cisco.com Message-Id: <20030701113327.69a199f1.moore@cs.utk.edu> In-Reply-To: <200307011511.h61FBPg5002902@rtp-core-1.cisco.com> References: <20030630110652.7ff385eb.moore@cs.utk.edu> <200307011511.h61FBPg5002902@rtp-core-1.cisco.com> X-Mailer: Sylpheed version 0.9.1 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Cc: moore@cs.utk.edu Subject: Re: appeal mechanisms was Re: Ombuds-process X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit ] Keith> But whenever a WG submits a document that the WG's AD doesn't like, ] Keith> in most cases this is because the WG has failed to get broad ] Keith> consensus on a document. ] ] Well, I understand that that's your story and you're sticking to it. But ] can you provide a reason for anyone to believe this? The AD is trying to make sure that the document is of high technical quality and does not cause problems. The surest way for the document to cause problems is for the WG to fail to consider interests outside of the immediate focus of the WG. This happens all the time. ] Or do you mean it to ] be a tautology, i.e., "broad consensus" means "the AD likes it"? ADs don't like things that cause problems for them, and some of the most difficult problems are those which require them to play Solomon and sort out conflicts between distant interests. So an AD is much more likely to like a document if there is a broad consensus supporting it. And believe it or not, ADs are sensitive to public opinion, so if an AD has a personal bias against a document a broad supporting consensus is likely to cause the AD to set aside that bias. ] Keith> to some degree engineering judgement is and must be subjective, so it ] Keith> may be perfectly valid for an AD to reject a document on such ] Keith> grounds. ] ] In areas where different engineers might reasonably come to different ] judgments, it is not appropriate for the IESG to substitute its own judgment ] for the WG consensus. That's where you're dead wrong. WGs are too narrowly focused to be entrusted to impose their own judgement on the whole community. But a WG that takes the trouble to do its homework and accomodate outside interests is far more likely to be able persuade an AD (and the IESG as a whole) that it's proposal is in the interest of the whole community. Keith From problem-statement-bounces@alvestrand.no Tue Jul 1 11:52:47 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05194 for ; Tue, 1 Jul 2003 11:52:46 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3833D6256C; Tue, 1 Jul 2003 17:52:16 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mx-out.daemonmail.net (mx-out.daemonmail.net [216.104.160.39]) by eikenes.alvestrand.no (Postfix) with ESMTP id 19F896238A for ; Tue, 1 Jul 2003 17:52:11 +0200 (CEST) Received: from mx0.emailqueue.net (localhost.daemonmail.net [127.0.0.1]) by mx-out.daemonmail.net (8.9.3p2/8.9.3) with SMTP id IAA04910 for ; Tue, 1 Jul 2003 08:52:08 -0700 (PDT) (envelope-from spencer@mcsr-labs.org) Received: from (216.62.6.129 [216.62.6.129]) by mail.varaha.com with SMTP id tG10LHE0 Tue, 01 Jul 2003 08:52:08 -0700 (PDT) Message-ID: <00dd01c33fe8$bb5861c0$8100000a@DFNJGL21> From: "Spencer Dawkins" To: References: <20030630110652.7ff385eb.moore@cs.utk.edu><200307011511.h61FBPg5002902@rtp-core-1.cisco.com> <20030701113327.69a199f1.moore@cs.utk.edu> Date: Tue, 1 Jul 2003 10:52:09 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: Re: appeal mechanisms was Re: Ombuds-process X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Spencer Dawkins List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Dear Keith, I thought today's quote from John Klensin on the appeals process was helpful in a broader sense: > I also deliberately said "remedy" and not "solution". Suppose > we have an appeal whose substance is "the solution the WG came > up with is bad, because..., and doesn't really represent > consensus, so the IESG shouldn't make it a standard". "XYZ > should be the standard instead" might be a "solution", but the > IESG would be on thin ice if it substituted its protocol > judgment (and that of the appeal) for that of the WG. By > contrast, "the IESG should return this matter to the WG, insist > that it reconsider the technical matter and gets its act > together procedurally, and consider whether the current chair is > the right person to steer that process". That is a "remedy" > for the particular problem -- it doesn't require knowing the > solution. I think there is a distinction between "this is the wrong answer" and "this is the wrong answer, and the right answer is ...". Spencer ----- Original Message ----- From: "Keith Moore" To: Cc: ; ; Sent: Tuesday, July 01, 2003 10:33 AM Subject: Re: appeal mechanisms was Re: Ombuds-process > > ] Keith> to some degree engineering judgement is and must be subjective, so it > ] Keith> may be perfectly valid for an AD to reject a document on such > ] Keith> grounds. > ] > ] In areas where different engineers might reasonably come to different > ] judgments, it is not appropriate for the IESG to substitute its own judgment > ] for the WG consensus. > > That's where you're dead wrong. WGs are too narrowly focused to be entrusted > to impose their own judgement on the whole community. But a WG that takes > the trouble to do its homework and accomodate outside interests is far more > likely to be able persuade an AD (and the IESG as a whole) that it's proposal > is in the interest of the whole community. > > Keith From problem-statement-bounces@alvestrand.no Wed Jul 2 09:01:38 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14394 for ; Wed, 2 Jul 2003 09:01:36 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BFB7F623CD; Wed, 2 Jul 2003 15:01:05 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by eikenes.alvestrand.no (Postfix) with ESMTP id DC83F622A1 for ; Wed, 2 Jul 2003 15:01:02 +0200 (CEST) Received: from [209.187.148.215] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.10) id 19XhEL-0006Aw-00; Wed, 02 Jul 2003 08:01:01 -0500 Date: Wed, 02 Jul 2003 09:01:00 -0400 From: John C Klensin To: Dave Crocker , "problem-statement@alvestrand.no" Message-ID: <57264892.1057136460@p3.JCK.COM> In-Reply-To: <194231154582.20030626134133@brandenburg.com> References: <3EDDA77F.8050700@piuha.net> <3EDDA77F.8050700@piuha.net> <5.1.0.14.2.20030607123251.047d9aa0@mail.windriver.com> <174132382475.20030607215256@brandenburg.com> <20030624160713.3ef09588.moore@cs.utk.edu> <194231154582.20030626134133@brandenburg.com> X-Mailer: Mulberry/3.1.0b3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: Complex Problems (Was: Re: Discipline of Internet Protocol Engineering) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Dave, I've needed to let this set of messages season a bit in the hope of saying something coherent and not repeating myself too much. I think one needs to distinguish between "adequate understanding of the problem" and "overly broad attempts at a solution". For the latter, we are, I think, pretty much in agreement: attempts to engineer large, integrated, complex solutions have rarely been successful in the IETF (or, perhaps, anywhere else). But, when we take a complex _problem_ and say "well, we understand the lower-right-corner of it, so let's 'solve' that" often leads us into a solution that doesn't integrate well with the other pieces when those come along. That poor integration can constrain opportunities and solutions going forward or can force us toward incompatible changes, neither of which is good. Clearly, it is important to find a balance, since the quest for comprehensive and perfect understanding of every problem would result in our never actually getting anything done (if one were cynical, one might make that observation about this WG as well as about the IETF's technical/engineering work). But "this piece will work, so let's do it" needs, IMO, to be carefully balanced with "and _what_ problem is it solving?". And we need to have clear explanations and a reasonable consensus about the latter. I suggest that failure to take that step has gotten us into a lot of trouble in some areas in the past and that may be where my views and Keith's intersect. With that distinction between problem analysis and solutions, let's look at some of your examples... --On Thursday, 26 June, 2003 13:41 -0700 Dave Crocker wrote: >... > Solving a big, complicated problem by trying to develop a > single, coherent specification -- no matter how many > documents; the point is about making all the bits of work > proceed in lock-step -- is a well-known way to ensure failure. > One only needs to look at OSI in general, and X.400 in > particular. (And by way of anticipating one of the rat-holes, > I'll note that X.400 achieved the rare success of having too > much be integrated all at once, but still lack core bits of > functionality.) And I would suggest that the failure in X.400 was that they lost track of the problem analysis (which was actually pretty good, IMO, in the early stages of that work) in the process of trying to accommodate too many different views and "solution" ideas. They also left two or three important issues out of that problem analysis: a reasonable migration path from earlier systems (including, later on, a reasonable migration path from earlier versions of X.400) and general usability (aggravated by the fact that there were already deployed systems that were easier to use). A possible additional important issue was that we already had deployed and successful experience with more or less peer to peer email systems, while the analysis that led to X.400 assumed a highly-structured "email provider" environment. I imagine that the missing "core bits of functionality" to which you refer fall into one of those areas, but might be additional ones in which the problem analysis failed to be adequate (and tracked into the final results). By contrast, regardless of the development method, X.400 turned out to be fairly modular and composed of separable pieces, as evidenced by the number of times people have successfully used some pieces of the system and not others. It is arguably better in that regard than SMTP, which assumes --in its handling of Received fields if nothing else-- some semblance of 822 header/body structure in the messages that are being transported. > The usual logic for explaining this problem is that the > complexity of juggling all the issues, across the entire > service, simply buries the development effort. At best, it > ensures that the work is produced much, much later, often > after the market has found an alternate solution. (And that > is, most certainly, what happened to OSI. I can elaborate on > this is some detail, if anyone really challenges this point.) No disagreement on this. But it is possible to do modular development against a systems-level problem understanding. The only additional requirement that introduces is that the little-piece development proposals must be examined against a "does this foul up anything else in the system" criterion. And that is, IMO, one which we have too often managed to bypass. > Breaking down a complex problem into smaller pieces that are > individually useful does two things that are quite good: > > 1) It permits each piece of work to be useful, even if some > other piece of work has a persistent problem; Yes, as long as those individual pieces don't prevent each other from working, or overconstrain parts of the problem for which pieces are not yet developed. > and 2) it > permits turning the crank on the specification engine more > quickly and more frequently. This means that we get > operational experience more quickly and can then, quickly, > refine the specifications to match actual field knowledge. > With large, integrated efforts, the inter-dependencies mean > that the whole of the work is not useful until the most > problematic part is completed. Again, up to a point. I would have said "until the boundaries of the most problematic parts are understood sufficiently to be reasonably confident that they really are isolated". To draw from another recent thread, a _solution_ to the problematic parts is not necessary, but some understanding of them and there implications often is. > And it means that it is quite a > few years before there is any feedback from the user > community;. If there was a problem with the major design > decisions that were made, they become essentially impossible > to change, because things took so long to delivery. I think one can argue that point into a "lose either way" situation, so it is important to strike an appropriate balance. >From the other perspective, one could claim that the "smaller pieces" approach --without adequate problem analysis-- can lead to quick and effective feedback from the user community about those specific pieces, but that their deployment may then make it essentially impossible to solve the more difficult problems by constraining possible solutions to them down to a null set. That is reasonable if the more difficult problems are also the less important ones, but there are no guarantees that is the case. Sometimes, the most difficult problems are also the most important. >... > Is IP a failure? Besides independent development of TCP and > UDP, from the IP core, ICMP has been able to proceed > independently, as has different address-mapping efforts and, > for that matter, address interpretation efforts. But IP, and the post-split TCP/IP, started from, I think, a fairly comprehensive understanding of what problems people were trying to solve. Your example, along with the email transfer/content split, has more to do with effective modularization of the solution(s) than it does with a particular style of development. Indeed, if one goes back and examines the history of the transfer/content split in email, a case can be made that, as with IP, the two started out fairly integrated and were split up after the advantages of that became clear. To the extent to which that is true, neither one is a good example of _design_ or _development_ on a "small pieces" basis: rather, they are examples of redefinition of the problem and remodularization of the solution after the initial design and development were complete. >... > (One could go down a rathole about nonconformance, noting how > badly we suffer from excessive variance in email system > behavior, but I claim that is due to lack of enforcement, > rather than due to any architectural issues. Given the wide > range of support for HTML, and the like, this might be an > applications-level issue. But it is not a big-vs-small design > effort issue.) Agreed. > In fact, this highlights one of the other, surprising benefits > of a divide-and-conquer approach, namely that it permits > post-hoc additions that were not planned. When the original > philosophy is to do as little as possible to be useful, > knowing that more bits of related work will be done, then it > often is easier to do some of those bits many years later. Again, I suggest that the advantages you are claiming here --and with which I agree-- are due to effective modularization, rather than a particular development approach (such as "divide and conquer"). And I believe we are more likely to get the modularization right if we have a moderately complete understanding of the problem --a systems analysis of properties, relationships, and interactions-- rather than if we start carving off pieces of the problem piecemeal on the assumption that we can always fit things back together later. regards, john From problem-statement-bounces@alvestrand.no Wed Jul 2 12:12:29 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29140 for ; Wed, 2 Jul 2003 12:12:28 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5A3EC623CD; Wed, 2 Jul 2003 18:11:59 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by eikenes.alvestrand.no (Postfix) with ESMTP id 86C8D61A96 for ; Wed, 2 Jul 2003 18:11:56 +0200 (CEST) Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h62GBqfU006461; Wed, 2 Jul 2003 09:11:54 -0700 (PDT) Received: from lillen (lillen [129.157.212.23])h62GBqQ02928; Wed, 2 Jul 2003 18:11:52 +0200 (MEST) Date: Wed, 2 Jul 2003 18:11:23 +0200 (CEST) From: Erik Nordmark To: Charlie Perkins , Jim.Bound@hp.com In-Reply-To: "Your message with ID" <3EE4D004.4010103@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Cc: problem-statement@alvestrand.no Subject: Re: The need for smaller protocol specifications X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Erik Nordmark List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no > I'm going to try to describe what I see as a major problem, but > the solution is not a black-and-white cure-all rule. It's more a > matter of perspective, balance, and judgement. > > Put simply, protocol specifications are being required to > contain too many features. In my favorite example, a very > simple signaling protocol specification was eventually required > to also incorporate other related specifications: > - A discovery algorithm > - A key distribution algorithm > - Renumbering algorithms > - Compatibility recipes for an incompatible security protocol > - other stuff too. Let me try to add my 2 cents on this topic even though I'm behind on the list. The way I would characterize the problem is that the protocols the IETF undetakes today might take a longer time to develop because: - the problem is harder - we've solved the easy problems already - we as a community place higher requirements (for instance, deployable security for the protocol; congestion control; and we might desire less manual configuration; etc) - interaction with other artifacts, whether our own protocol specifications or something else that is deployed on the net. If you look at the third bullet alone for Internet Area stuff there is an amazing list. Making it concrete using mobile IPv6 (Charlie's example) I immediately come up with: - interaction with DHCP (assigned home and/or care-of addresses) - interaction with stateless addrconf (assigned home and/or care-of addresses) - interaction with RFC 3041 temporary addresses (assigned as home and/or care-of addresses) - interaction with IPsec for protecting the data traffic (as opposed to using IPsec to protect the Mobile IPv6 signalling protocol itself) - interaction with renumbering (the home link and/or the visited link) - combinations of the above... For other protocols there might be concerns about other interactions, such as interaction with NAT boxes in the path. Presumably there are other lists that are more pertinent for other parts of the stack. My point isn't about Mobile IPv6 or the individual items in the above lists, but about the total complexity of the space. I suspect that as a result of this, protocol specifications become longer and more complex and, even if the solutions to deal with individual pieces are separable, in order to get the protocol approved it might be necessary to deal with many, if not all, of the issues. Presumably the community doesn't want to compromise away some key requirements (such as a reasonable level of security; congestion control) but what about the interaction with other protocols and artifacts; is it ok to not worry about those initially? As a hypothetical example, would there have been concerns if DHCPv6 worked and Mobile IPv6 worked, but the combination couldn't be made to work? (Again, I'm not asking about the specifics but about the general case of interaction with existing protocols or protocols that are being developed in parallel.) In other cases working groups have first specified a protocol and later made some extensions to e.g. make it cope better with NATs. While such an approach could be taken for more of the "interactions" above to make smaller separate specifications, it doesn't really address the complexity of the total solution. So I think part of the issue is that protocols end up being complex because they need to fit into a complex world, and at least some of that complex world the IETF has created itself. Restraining what the community creates could be one approach to limit the complexity. Perhaps better modularity and/or less number of ways to do the same thing is another way. [As an aside, note that in the above list there are interactions with the 3 different ways that IPv6 addresses can be autoconfigured.] Jim said: > PROBLEM: The IETF process to complete specifications puts to many > features in those initial specifications. [This would be sub bullet > again above]. In Charlie's example many the "features" aren't there as improvements to the protocol itself (the dynamic home agent discovery might be), but instead driven by the complexity outside of the protocol being specified. One possible problem could be that WGs wants to put too many features in the initial specification. Another possible problem could be that the external word (or the IETF community, or the IESG) requires interaction with too many different things. >From the wording above I can't tell whether you had one or both of these in mind. Erik From problem-statement-bounces@alvestrand.no Wed Jul 2 15:07:11 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06934 for ; Wed, 2 Jul 2003 15:07:10 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id ED3C462597; Wed, 2 Jul 2003 21:06:39 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by eikenes.alvestrand.no (Postfix) with ESMTP id 213ED622A1 for ; Wed, 2 Jul 2003 21:06:38 +0200 (CEST) Received: from txdwillis (bdsl.66.12.12.254.gte.net [66.12.12.254]) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h62J6Z24008749 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 2 Jul 2003 14:06:36 -0500 From: "Dean Willis" To: "'Erik Nordmark'" Date: Wed, 2 Jul 2003 14:06:17 -0500 Message-ID: <002e01c340cd$042569e0$ee036e3f@txdwillis> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: Importance: Normal Cc: problem-statement@alvestrand.no Subject: RE: The need for smaller protocol specifications X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: quoted-printable Erik said: > I suspect that as a result of this, protocol specifications=20 > become longer and more complex and, even if the solutions to=20 > deal with individual pieces are separable, in order to get=20 > the protocol approved it might be necessary to deal with=20 > many, if not all, of the issues. I suspect that this intersects viciously with the "every possible issue = must be solved before publishing a proposed standard, because nothing ever = makes it to draft" behavior. We HAVE been setting higher and higher standards for our work. I keep expecting the next trivial protocol proposal to have to solve the distributed-PKI problem while proving the NP-completeness of general relativity and demonstrating a solution to world hunger all in order 0 = time. Seriously, I think the bars are set at the wrong levels -- the first = rung is just too high, the second is unachievable, and the third is = unimaginable. -- Dean From problem-statement-bounces@alvestrand.no Wed Jul 2 15:35:30 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08980 for ; Wed, 2 Jul 2003 15:35:29 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 889FA6259B; Wed, 2 Jul 2003 21:35:00 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by eikenes.alvestrand.no (Postfix) with ESMTP id 824ED62278 for ; Wed, 2 Jul 2003 21:34:58 +0200 (CEST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h62JY8N27760; Wed, 2 Jul 2003 15:34:10 -0400 (EDT) Date: Wed, 2 Jul 2003 15:34:07 -0400 From: Keith Moore To: "Dean Willis" Message-Id: <20030702153407.36c5412f.moore@cs.utk.edu> In-Reply-To: <002e01c340cd$042569e0$ee036e3f@txdwillis> References: <002e01c340cd$042569e0$ee036e3f@txdwillis> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Cc: Erik.Nordmark@sun.com Cc: moore@cs.utk.edu Subject: Re: The need for smaller protocol specifications X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit > Erik said: > > I suspect that as a result of this, protocol specifications > > become longer and more complex and, even if the solutions to > > deal with individual pieces are separable, in order to get > > the protocol approved it might be necessary to deal with > > many, if not all, of the issues. > > I suspect that this intersects viciously with the "every possible > issue must be solved before publishing a proposed standard, because > nothing ever makes it to draft" behavior. I suspect it intersects even more viciously with the "we finalize the design of the the protocol before we understand the full spectrum of requirements" behavior. Or to put it another way, if the WG is finding out only after Last Call that it's failed to establish the requirements for its work to be complete and to get sign-off on those requirements from IESG, it's going to be very difficult to fix that WG's output to everyone's satisfaction. the surest way to get burned is to deliver a product to a customer without first having agreed on the deliverables... > Seriously, I think the bars are set at the wrong levels -- the first > rung is just too high, the second is unachievable, and the third is > unimaginable. I think we need some lower rungs to step on before we get to Last Call. I also think we might need to raise the rung we're currently calling Proposed Standard. From problem-statement-bounces@alvestrand.no Wed Jul 2 16:58:57 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17062 for ; Wed, 2 Jul 2003 16:58:56 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7449862595; Wed, 2 Jul 2003 22:58:27 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5CF6E62278 for ; Wed, 2 Jul 2003 22:58:25 +0200 (CEST) Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h62KwMvc027454; Wed, 2 Jul 2003 14:58:23 -0600 (MDT) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) h62KwIQ07566; Wed, 2 Jul 2003 22:58:19 +0200 (MEST) Date: Wed, 2 Jul 2003 22:55:24 +0200 (CEST) From: Erik Nordmark To: Dean Willis In-Reply-To: "Your message with ID" <002e01c340cd$042569e0$ee036e3f@txdwillis> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Cc: problem-statement@alvestrand.no Cc: "'Erik Nordmark'" Subject: RE: The need for smaller protocol specifications X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Erik Nordmark List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no > We HAVE been setting higher and higher standards for our work. I keep > expecting the next trivial protocol proposal to have to solve the > distributed-PKI problem while proving the NP-completeness of general > relativity and demonstrating a solution to world hunger all in order 0 time. > > Seriously, I think the bars are set at the wrong levels -- the first rung is > just too high, the second is unachievable, and the third is unimaginable. Devil is in the details I suspect. The hard question is what should the criteria be. While I can see the community agreeing on some general requirements (like reasonable security; congestion control) it is a lot harder to ssee where to do incremental work when it comes to things like - doesn't handle all the aspects of the layer's it's built upon - doesn't fit together with other protocols sitting next to it - doesn't provide the assumed set of services to other protocols e.g. those layered on top of it While prptocols that don't have all of the above might be useful to specify and implement as part of a better understanding of the problem and solution spaces, it would seem odd to call somethhing an IETF standard it is doesn't fit into the puzzle of existing standards. So perhaps there is an argument that such "components" be experimental RFCs and when they fit better into the puzzle they can move to the standards track. Making them fit might involve modifications to the protocol itself, or the addition of some more components that provide the glue. Erik From problem-statement-bounces@alvestrand.no Wed Jul 2 17:39:28 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20612 for ; Wed, 2 Jul 2003 17:39:27 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7069F6259F; Wed, 2 Jul 2003 23:38:58 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mx-out.daemonmail.net (mx-out.daemonmail.net [216.104.160.39]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0847E62597 for ; Wed, 2 Jul 2003 23:38:56 +0200 (CEST) Received: from mx0.emailqueue.net (localhost.daemonmail.net [127.0.0.1]) by mx-out.daemonmail.net (8.9.3p2/8.9.3) with SMTP id OAA70361 for ; Wed, 2 Jul 2003 14:38:54 -0700 (PDT) (envelope-from spencer@mcsr-labs.org) Received: from (12.237.229.250 [12.237.229.250]) by mail.varaha.com with SMTP id fII0BNO2 Wed, 02 Jul 2003 14:38:53 -0700 (PDT) Message-ID: <03e101c340e2$57a34410$0200a8c0@DFNJGL21> From: "Spencer Dawkins" To: References: Date: Wed, 2 Jul 2003 16:38:56 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: Re: The need for smaller protocol specifications X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Spencer Dawkins List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Dear Erik, Re: Component specifications as Experimental... The thing I would wonder about is simply moving the "one stage standard" problem from Proposed Standard to Experimental. Trying to frame my question in an on-topic way - does the IETF's multiple stages of approval matter to the consumers of our specifications? Variants of this question include: o When we publish a proprietary specification as Informational and then publish a WG specification as Proposed Standard, is this a distinction that matters to the Internet community? o When we publish (as we often do) TCP changes as Experimental, do implementors wait for Proposed Standard approval before including them in products? Spencer ----- Original Message ----- From: "Erik Nordmark" To: "Dean Willis" Cc: ; "'Erik Nordmark'" Sent: Wednesday, July 02, 2003 3:55 PM Subject: RE: The need for smaller protocol specifications > > While prptocols that don't have all of the above might be useful > to specify and implement as part of a better understanding of the > problem and solution spaces, it would seem odd to call somethhing > an IETF standard it is doesn't fit into the puzzle of existing > standards. > > So perhaps there is an argument that such "components" be experimental > RFCs and when they fit better into the puzzle they can move to the standards > track. Making them fit might involve modifications to the protocol > itself, or the addition of some more components that provide the glue. > > Erik From problem-statement-bounces@alvestrand.no Wed Jul 2 18:14:31 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24714 for ; Wed, 2 Jul 2003 18:14:30 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 61EC0625A3; Thu, 3 Jul 2003 00:13:58 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by eikenes.alvestrand.no (Postfix) with ESMTP id AFDAF62597 for ; Thu, 3 Jul 2003 00:13:56 +0200 (CEST) Received: from txdwillis (bdsl.66.12.12.254.gte.net [66.12.12.254]) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h62MDs24010101 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 2 Jul 2003 17:13:55 -0500 From: "Dean Willis" To: "'Erik Nordmark'" Date: Wed, 2 Jul 2003 17:13:35 -0500 Message-ID: <009901c340e7$2eebe360$ee036e3f@txdwillis> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: Importance: Normal Cc: problem-statement@alvestrand.no Subject: RE: The need for smaller protocol specifications X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Erik said: > While prptocols that don't have all of the above might be > useful to specify and implement as part of a better > understanding of the problem and solution spaces, it would > seem odd to call somethhing an IETF standard it is doesn't > fit into the puzzle of existing standards. Aha! You prove my point. Today, (as you ilustrate above) we seem to think that any RFC is "an IETF standard". By the current official process, a proposed standard is a relatively stable work that is acknowledged to be incomplete and not expected to be widely implemented. A draft standard is considered pretty much complete and widely enough implemented that we know it works (two implementations of each feature). Only a full standard is expected to be really complete. Does that line up with the real world's perception, or with the quotation above? I propose that the four-tracks of RFCs combined with three tiers on the standards track (Total= seven kinds of RFCs) confuse not only the external consumers of our work, but have confused us as well. We don't know whether we're delivering "standards" or instructions about "how to try something at home, kids." Result: a Catch-22 where we can't know something works right until we've tried it, can't try it until it's a standards-track RFC, and can't write it up as a standards-track RFC until we know it works right. Result: the dining philosophers have no fork and soon starve. I think this is a problem. I know it's a pain in the behind. Would it be going too far to equate the seven kinds of RFC with the seven deadly sins? -- Dean From problem-statement-bounces@alvestrand.no Thu Jul 3 06:28:43 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05246 for ; Thu, 3 Jul 2003 06:28:42 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 24EA5625BA; Thu, 3 Jul 2003 12:28:11 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id 581C9625A7; Thu, 3 Jul 2003 12:28:09 +0200 (CEST) Date: Thu, 03 Jul 2003 12:28:09 +0200 From: Harald Tveit Alvestrand To: John C Klensin , avri Message-ID: <296430000.1057228089@askvoll.hjemme.alvestrand.no> In-Reply-To: <117518632.1057047653@p3.JCK.COM> References: <117518632.1057047653@p3.JCK.COM> X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: "problem-statement@alvestrand.no" Subject: Re: Appeal records (was: Re: appeal mechanisms was Re: Ombuds-process) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit --On tirsdag, juli 01, 2003 08:20:53 -0400 John C Klensin wrote: > (Separating this off into a separate thread) > > --On Tuesday, 01 July, 2003 09:42 +0900 avri wrote: > >> I would really be interested in an analysis of the number of >> appeals that have been brought forth in last years, the number >> of successful ones and the reasons formally given for the >> unsuccessful ones. Is a formal record kept of all appeals and >> the deliberation on those appeals? Are those records open and >> readily available to the IETF participants? > > I doubt that such records exist in a form that would be amenable to > statistical analysis. Certainly the _decisions_ of the IAB on appeals > have been public and, as far as I can recall, have always been recorded > on the IAB's web pages. I instituted a web page for this at the IESG level last fall. It's http://www.ietf.org/IESG/Appeals.html - reached from the main IESG page, under the title (unsurprisingly) of "Appeals to the IESG". So far, it's collected a grand total of 3 appeal texts - one of which ws accepted, one of which was rejected, and one which was withdrawn. Caveat: It does NOT record appeals against WG actions that are addressed to individual ADs. The IAB appeals page, which has a somewhat longer history, is at http://www.iab.org/Appeals/index.html Harald From problem-statement-bounces@alvestrand.no Thu Jul 3 07:54:52 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07614 for ; Thu, 3 Jul 2003 07:54:51 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C89FC625BA; Thu, 3 Jul 2003 13:54:19 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by eikenes.alvestrand.no (Postfix) with ESMTP id 01A98625B2 for ; Thu, 3 Jul 2003 13:54:12 +0200 (CEST) Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h63BsA1J013970; Thu, 3 Jul 2003 05:54:11 -0600 (MDT) Received: from lillen (lillen [129.157.212.23])h63Bs9Q06344; Thu, 3 Jul 2003 13:54:09 +0200 (MEST) Date: Thu, 3 Jul 2003 07:51:10 +0200 (CEST) From: Erik Nordmark To: Dean Willis In-Reply-To: "Your message with ID" <009901c340e7$2eebe360$ee036e3f@txdwillis> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Cc: problem-statement@alvestrand.no Cc: "'Erik Nordmark'" Subject: RE: The need for smaller protocol specifications X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Erik Nordmark List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no > Aha! You prove my point. Today, (as you ilustrate above) we seem to think > that any RFC is "an IETF standard". No, I don't think I said that. > By the current official process, a proposed standard is a relatively stable > work that is acknowledged to be incomplete and not expected to be widely > implemented. RFC 2026 doesn't say "incomplete" instead it says "has resolved known design choices". That could easily be interpreted as all the pieces necessary in the protocol has been specified. For instance, having a proposed standard say "we need X but haven't specified how to do that yet" seems to violate 2026, whether X is e.g., a security mechanism, the ability to interact with different forms of IP address configuration, or some agent discovery mechanism. Erik From problem-statement-bounces@alvestrand.no Thu Jul 3 10:20:26 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13110 for ; Thu, 3 Jul 2003 10:20:25 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1106A625C5; Thu, 3 Jul 2003 16:19:53 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from ietf.org (odin.ietf.org [132.151.1.176]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8C0DF625B2 for ; Thu, 3 Jul 2003 16:19:50 +0200 (CEST) Received: from tigger (scoya.cnri.reston.va.us [10.27.5.106]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13095; Thu, 3 Jul 2003 10:19:46 -0400 (EDT) Date: Thu, 3 Jul 2003 10:18:48 -0400 (Eastern Daylight Time) From: Steve Coya To: Spencer Dawkins In-Reply-To: <03e101c340e2$57a34410$0200a8c0@DFNJGL21> Message-ID: X-X-Sender: scoya@odin.cnri.reston.va.us MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: problem-statement@alvestrand.no Subject: Re: The need for smaller protocol specifications X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no >>Variants of this question include: >> >>o When we publish a proprietary specification as Informational and then >>publish >>a WG specification as Proposed Standard, is this a distinction that matters >>to the Internet community? Define Internet Community. IOW, replace "community" with "developers." I do believe the distinction is understood by the vendors (be they companies or individuals) who actually implement the protocol defined in the RFC. Also, when there is both a WG effort and a propriatary Informational RFC, the latter typically includes an IESG note, pointing out the existance (and implied preference) of the Proposed Standard. >>o When we publish (as we often do) TCP changes as Experimental, do >>implementors wait for Proposed Standard approval before including >>them in products? >From what I recall, some do and some don't. Those that do are typically particiants in the WG that produced the Experimental RFC. Back in the early 90s, there was a concern that some vendors would not implement Proposed Standards, but wait for Draft - that was when IETF meeting attedance was under 500. Today is different as there seem to be many RFCs remaining at Proposed (and everyone confuses product differentation with protocol specifications) That's my recollection, and is based on history - not current events. Steve From problem-statement-bounces@alvestrand.no Thu Jul 3 11:32:25 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16759 for ; Thu, 3 Jul 2003 11:32:22 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 896D7625C5; Thu, 3 Jul 2003 17:31:46 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from ietf.org (odin.ietf.org [132.151.1.176]) by eikenes.alvestrand.no (Postfix) with ESMTP id CC9FA625C5 for ; Thu, 3 Jul 2003 17:31:41 +0200 (CEST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16554; Thu, 3 Jul 2003 11:31:38 -0400 (EDT) Message-Id: <200307031531.LAA16554@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: problem-statement@alvestrand.no From: Internet-Drafts@ietf.org Date: Thu, 03 Jul 2003 11:31:38 -0400 Subject: I-D ACTION:draft-ietf-problem-process-01.txt X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Internet-Drafts@ietf.org List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Problem Statement Working Group of the IETF. Title : IETF Problem Resolution Processes Author(s) : M. Wasserman Filename : draft-ietf-problem-process-01.txt Pages : 20 Date : 2003-7-3 This document suggests processes to address the problems identified in the IETF Problem Statement. This document decomposes each of the problems described in the problem statement into a few areas for improvement, categorizes those areas into longer-term and near-term problems, and suggests processes to address each area. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-problem-process-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-problem-process-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-problem-process-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-7-3112146.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-problem-process-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-problem-process-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-3112146.I-D@ietf.org> --OtherAccess-- --NextPart-- From problem-statement-bounces@alvestrand.no Thu Jul 3 11:32:52 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16944 for ; Thu, 3 Jul 2003 11:32:51 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7D8C5625D9; Thu, 3 Jul 2003 17:32:21 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from ietf.org (odin.ietf.org [132.151.1.176]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5E490625D9 for ; Thu, 3 Jul 2003 17:31:53 +0200 (CEST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16581; Thu, 3 Jul 2003 11:31:44 -0400 (EDT) Message-Id: <200307031531.LAA16581@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: problem-statement@alvestrand.no From: Internet-Drafts@ietf.org Date: Thu, 03 Jul 2003 11:31:44 -0400 Subject: I-D ACTION:draft-ietf-problem-issue-statement-02.txt X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Internet-Drafts@ietf.org List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Problem Statement Working Group of the IETF. Title : IETF Problem Statement Author(s) : E. Davies Filename : draft-ietf-problem-issue-statement-02.txt Pages : 23 Date : 2003-7-3 This memo summarizes perceived problems in the structure, function and processes of the Internet Engineering Task Force (IETF). We are attempting to identify these problems, so that they can be addressed and corrected by the IETF community. The problems have been digested and categorized from an extensive discussion which took place on the 'problem-statement' mailing list from November 2002 to May 2003. The problem list has been further analyzed to try and determine the root causes, that are at the heart of the perceived problems: The result will be used to guide the next stage of the process in the Problem Statement working group which is to determine the structures and processes that will carry out the corrections. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-problem-issue-statement-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-problem-issue-statement-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-problem-issue-statement-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-7-3112155.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-problem-issue-statement-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-problem-issue-statement-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-3112155.I-D@ietf.org> --OtherAccess-- --NextPart-- From problem-statement-bounces@alvestrand.no Thu Jul 3 21:05:01 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29072 for ; Thu, 3 Jul 2003 21:05:00 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 035BE625A7; Fri, 4 Jul 2003 03:04:29 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9F36B625A3 for ; Thu, 3 Jul 2003 06:53:25 +0200 (CEST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 82E047554; Thu, 3 Jul 2003 00:53:24 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Thu, 3 Jul 2003 00:53:24 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 3 Jul 2003 00:53:23 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B032413E2@tayexc13.americas.cpqcorp.net> Thread-Topic: The need for smaller protocol specifications Thread-Index: AcNAtLJGOrlvJAYETQuQRKQQng6TogAaKlPg From: "Bound, Jim" To: "Erik Nordmark" , "Charlie Perkins" X-OriginalArrivalTime: 03 Jul 2003 04:53:24.0419 (UTC) FILETIME=[08D0A930:01C3411F] X-Mailman-Approved-At: Fri, 04 Jul 2003 03:04:28 +0200 Cc: problem-statement@alvestrand.no Cc: "Bound, Jim" Subject: RE: The need for smaller protocol specifications X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: quoted-printable Erik, I am off this list but your catching up on old email I guess. I will respond to you privately engineer to engineer not IETF politician to politician which I will not even bother with anymore and ignore. =20 But there was something else that came up and as you ship products too, is that the IETF needs to ship a product faster and leaner and more often. Never has the IETF been the subject of concern in the industry as it is today many factions, entities, and governments are highly concerned the IETF has lost it completely to achieve time to market. I am on vacation now and your one of the few humans on the planet that I will respond to in the all to infrequent exercise of doing something besides our technology work/life. Or we can talk in Vienna privately. The problem is treat this work here with a deliverable and fix the IESG work load. There are individual problem children across the IETF with bad manners, impolite, and a legend in their own mind. So what!! they exist everywhere in all aspects of life and here in the IETF. It is unfortuneate when they are leaders but that happens too. But if you all focus on time-to-market and the mass numbers of specs using SIR or some other such group most of the problems that can be resolved will begin to get fixed. To bad you left the IESG and that put me over the top, after the Nomcom decided Scott should not stay, for now I give up and will watch the IESG on my work in detail. But given your rationale I would have done the same and why I am riding my harley around the east coast and your resignation influenced me too, so in that respect thanks for that "honest" open mail. Like common sense that is rare to see these days. /jim > -----Original Message----- > From: Erik Nordmark [mailto:Erik.Nordmark@sun.com]=20 > Sent: Wednesday, July 02, 2003 12:11 PM > To: Charlie Perkins; Bound, Jim > Cc: problem-statement@alvestrand.no > Subject: Re: The need for smaller protocol specifications >=20 >=20 > > I'm going to try to describe what I see as a major problem, but the=20 > > solution is not a black-and-white cure-all rule. It's more=20 > a matter=20 > > of perspective, balance, and judgement. > >=20 > > Put simply, protocol specifications are being required to=20 > contain too=20 > > many features. In my favorite example, a very simple signaling=20 > > protocol specification was eventually required to also incorporate=20 > > other related specifications: > > - A discovery algorithm > > - A key distribution algorithm > > - Renumbering algorithms > > - Compatibility recipes for an incompatible security protocol > > - other stuff too. >=20 > Let me try to add my 2 cents on this topic even though I'm=20 > behind on the list. >=20 > The way I would characterize the problem is that the=20 > protocols the IETF undetakes today might take a longer time=20 > to develop because: > - the problem is harder - we've solved the easy problems already > - we as a community place higher requirements (for instance,=20 > deployable security > for the protocol; congestion control; and we might desire=20 > less manual =20 > configuration; etc) > - interaction with other artifacts, whether our own protocol=20 > specifications > or something else that is deployed on the net. >=20 > If you look at the third bullet alone for Internet Area stuff=20 > there is an amazing list. Making it concrete using mobile=20 > IPv6 (Charlie's example) I immediately come up with: > - interaction with DHCP (assigned home and/or care-of addresses) > - interaction with stateless addrconf (assigned home and/or=20 > care-of addresses) > - interaction with RFC 3041 temporary addresses (assigned as=20 > home and/or=20 > care-of addresses) > - interaction with IPsec for protecting the data traffic (as=20 > opposed to > using IPsec to protect the Mobile IPv6 signalling protocol itself) > - interaction with renumbering (the home link and/or the=20 > visited link) > - combinations of the above... >=20 > For other protocols there might be concerns about other=20 > interactions, such as=20 > interaction with NAT boxes in the path. Presumably there are=20 > other lists that are more pertinent for other parts of the stack. >=20 > My point isn't about Mobile IPv6 or the individual items in=20 > the above lists,=20 > but about the total complexity of the space. >=20 > I suspect that as a result of this, protocol specifications=20 > become longer and more complex and, even if the solutions to=20 > deal with individual pieces are separable, in order to get=20 > the protocol approved it might be necessary to deal with=20 > many, if not all, of the issues. >=20 > Presumably the community doesn't want to compromise away some=20 > key requirements (such as a reasonable level of security;=20 > congestion control) but what about the interaction with other=20 > protocols and artifacts; is it ok to not worry about those=20 > initially? As a hypothetical example, would there have been=20 > concerns if DHCPv6 worked and Mobile IPv6=20 > worked, but the combination couldn't be made to work? (Again,=20 > I'm not asking about the specifics but about the general case=20 > of interaction with existing protocols or protocols that are=20 > being developed in parallel.) >=20 > In other cases working groups have first specified a protocol=20 > and later made some extensions to e.g. make it cope better=20 > with NATs. While such an approach could be taken for more of=20 > the "interactions" above to make smaller separate=20 > specifications, it doesn't really address the=20 > complexity of the total solution. >=20 > So I think part of the issue is that protocols end up being=20 > complex because they need to fit into a complex world, and at=20 > least some of that complex world the IETF has created itself.=20 > Restraining what the community creates could be one approach=20 > to limit the complexity. Perhaps better modularity and/or=20 > less number of ways to do the same thing is another way. [As=20 > an aside, note that in the above list there are interactions=20 > with the 3 different ways that IPv6 addresses can be autoconfigured.] >=20 >=20 > Jim said: > > PROBLEM: The IETF process to complete specifications puts to many=20 > > features in those initial specifications. [This would be sub bullet=20 > > again above]. >=20 > In Charlie's example many the "features" aren't there as=20 > improvements to the=20 > protocol itself (the dynamic home agent discovery might be),=20 > but instead driven by the complexity outside of the protocol=20 > being specified. >=20 > One possible problem could be that WGs wants to put too many=20 > features in the=20 > initial specification. > Another possible problem could be that the external word (or=20 > the IETF community, or the IESG) requires interaction with=20 > too many different things. From the wording above I can't=20 > tell whether you had one or both of these in mind. >=20 > Erik >=20 >=20 From problem-statement-bounces@alvestrand.no Fri Jul 4 10:29:08 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27972 for ; Fri, 4 Jul 2003 10:29:06 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 17BB66257B; Fri, 4 Jul 2003 16:28:36 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3F52E61C73 for ; Fri, 4 Jul 2003 16:28:33 +0200 (CEST) Received: from MOU1WNEXC03.verisign.com (verisign.com [65.205.251.57]) by peacock.verisign.com (8.12.9/) with ESMTP id h64ESVch027480 for ; Fri, 4 Jul 2003 07:28:31 -0700 (PDT) Received: by mou1wnexc03.verisign.com with Internet Mail Service (5.5.2653.19) id ; Fri, 4 Jul 2003 07:28:31 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E0D22BA@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'problem-statement@alvestrand.no'" Date: Fri, 4 Jul 2003 07:28:30 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: ADs who are also WG chairs X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no >however, I don't think you've demonstrated that "the current IETF process >gives too much power to the wg chairs & IESG", and I'd object to that >statement. *somebody* has to decide whether there is consensus, and whether >the document is of adequate quality, both within the WG and within the IETF as >a whole, and I don't see how decision can reasonably be made by other than a >small group of people. I can see an alternative to decisions by a small clique, it is called democracy. OASIS is running just fine using Robert's rules of order. There is thus an existence proof for the proposition that the IETF top down oligarchy is not essential for standards making. Replace the subjective 'consensus' with something objective and measureable and the need for power to be exclusively in the hands of a small unaccountable clique goes away. Of course the untutored masses may make a wrong decision, but they are already turning away from the IETF to work in other more responsive and accountable forums. To date this has been in the area of new specifications and the IETF has been allowed to retain control of specifications such as SMTP etc which have not been seen as being in need of urgent revision. This has changed as a result of spam. Protocol changes to SMTP and/or the messaging formats are now inevitable. I got laughed at for suggesting IETF as a possible standards venue. Phill From problem-statement-bounces@alvestrand.no Fri Jul 4 10:32:31 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28088 for ; Fri, 4 Jul 2003 10:32:28 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3F5666259E; Fri, 4 Jul 2003 16:31:57 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by eikenes.alvestrand.no (Postfix) with ESMTP id 99D3C625CC for ; Fri, 4 Jul 2003 16:31:52 +0200 (CEST) Received: from BBFUJIP.brandenburg.com (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h64EZBF20650; Fri, 4 Jul 2003 07:35:11 -0700 Date: Fri, 4 Jul 2003 15:20:47 +0200 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/11) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <156352047747.20030704152047@brandenburg.com> To: John C Klensin In-Reply-To: <57264892.1057136460@p3.JCK.COM> References: <3EDDA77F.8050700@piuha.net> <3EDDA77F.8050700@piuha.net> <5.1.0.14.2.20030607123251.047d9aa0@mail.windriver.com> <174132382475.20030607215256@brandenburg.com> <20030624160713.3ef09588.moore@cs.utk.edu> <57264892.1057136460@p3.JCK.COM> MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Cc: "problem-statement@alvestrand.no" Subject: Re: Complex Problems (Was: Re: Discipline of Internet Protocol Engineering) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Dave Crocker List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit John, JCK> I think one needs to distinguish between "adequate understanding JCK> of the problem" and "overly broad attempts at a solution". Yes, thank you. A very useful distinction. Alas, *each one* needs to be balanced between taking too long and being too hasty, I think. (And then, of course, they need to balanced with each other... it's amazing we ever get it right.) I believe we are currently having problems with each of these. JCK> when we take a complex _problem_ and say "well, we understand JCK> the lower-right-corner of it, so let's 'solve' that" often leads JCK> us into a solution that doesn't integrate well with the other JCK> pieces when those come along. Certainly there is the danger you cite, and certainly there are plenty of examples of this sin being committed around the world -- very much including within IETF. If one takes a view that is too narrow, or too localized, then they are likely (or certain) to commit this sin. One could argue that the real, underlying magic of the IETF's success has been the community's ability to hold the larger "problem understanding" that is needed, without spending excessive time developing it. The same has frequently been true for design of the larger solution space. This probably has been possible because there has been so much shared culture, so many skilled architects (including skill with scaling), and a relatively small domain of discourse. In terms of community proportions, I suspect none of these hold true anymore. (I said proportions, not actual numbers.) Hence, we cannot rely on assumptions and shared culture. We need to institutionalize mechanisms that achieve similar results. (yikes.) JCK> Clearly, it is important to find a balance, since the quest for JCK> comprehensive and perfect understanding of every problem would JCK> result in our never actually getting anything done ack. JCK> (if one were cynical, one might make that observation about this WG JCK> as well as about the IETF's technical/engineering work). or, worse, maybe *not* cynical... JCK> But "this JCK> piece will work, so let's do it" needs, IMO, to be carefully JCK> balanced with "and _what_ problem is it solving?". And we need JCK> to have clear explanations and a reasonable consensus about the JCK> latter. I suggest that failure to take that step has gotten us JCK> into a lot of trouble in some areas in the past and that may be JCK> where my views and Keith's intersect. and even mine. (*** Warning. Folks -- X.400 rathole section follows. Suggestion to the X.400/email technology-challenge: attend to the structure and process debate, without worrying whether either John or I are precisely correct about the facts. That is, treat it as a bench analysis of approaches, rather than an historical review... ***) >> One only needs to look at OSI in general, and X.400 in >> particular. JCK> And I would suggest that the failure in X.400 was that they lost JCK> track of the problem analysis (which was actually pretty good, JCK> IMO, in the early stages of that work) not sure i agree on the assessment of the early stages. my recollection is that X.400 tried, rather explicitly, to solve a whole array of human messaging problems for which the constituency was largely theoretical, and for which the solution(s) were very poorly understood. JCK> They also left two or three important issues out of that problem JCK> analysis: a reasonable migration path from earlier systems That was explicit. The world was explicitly expected simply to switch over. And therein lies and important lesson about installed base. (How else could anything as ugly as MIME prove so successful?) JCK> (including, later on, a reasonable migration path from earlier JCK> versions of X.400) Or, one could argue, that was the problem of making too darn many changes to existing functionality, and issuing them before vendors could recover their investment. And let's not forget just how complicated the specs were/are. JCK> and general usability (aggravated by the fact JCK> that there were already deployed systems that were easier to JCK> use). Another lesson, methinks. JCK> A possible additional important issue was that we already JCK> had deployed and successful experience with more or less peer to JCK> peer email systems, while the analysis that led to X.400 assumed JCK> a highly-structured "email provider" environment. A rather striking point about this is that the core of the X.400 work was done by folks with experience doing Arpanet stuff, though maybe not much with email. Hmmmm. >> The usual logic for explaining this problem is that the >> complexity of juggling all the issues, across the entire >> service, simply buries the development effort. JCK> No disagreement on this. But it is possible to do modular JCK> development against a systems-level problem understanding. The JCK> only additional requirement that introduces is that the JCK> little-piece development proposals must be examined against a JCK> "does this foul up anything else in the system" criterion. And JCK> that is, IMO, one which we have too often managed to bypass. and I agree with that, certainly. we can, of course, see the great, big, looming trap that this permits us to fall into, however. If we are not extremely careful. And one could argue that we have fallen into it quite a few times in recent years. >> and 2) it >> permits turning the crank on the specification engine more >> quickly and more frequently. This means that we get >> operational experience more quickly and can then, quickly, >> refine the specifications to match actual field knowledge. JCK> Again, up to a point. I would have said "until the boundaries JCK> of the most problematic parts are understood sufficiently to be JCK> reasonably confident that they really are isolated". My point was that enforcing dependencies between working groups ensures that none of them get their work done until the slowest is done. I believe your point pertained to the abstraction of what is needed to ensure that divide and conquer can proceed *without* the project management (ie, timing) dependencies. >> And it means that it is quite a >> few years before there is any feedback from the user >> community;. JCK> I think one can argue that point into a "lose either way" JCK> situation, so it is important to strike an appropriate balance. yup. JCK> From the other perspective, one could claim that the "smaller JCK> pieces" approach --without adequate problem analysis-- can lead JCK> to quick and effective feedback from the user community about JCK> those specific pieces, but that their deployment may then make JCK> it essentially impossible to solve the more difficult problems JCK> by constraining possible solutions to them down to a null set. the most essential bit of feedback is whether an approach (and its specification) are useful. If they are, the feedback means there is an installed base, and it must be respected henceforth. If the feedback says 'not useful', the we get to start over. Most of the time for any interesting problem, this carries a very real requirement, , that we must deploy components of a larger solution prior to fully understanding whether the divide-and-conquer component-ization has been done well enough. I believe it is a) the fear of getting this wrong, and/or b) actually getting it wrong, that cause the massive delays we experience for these complex problems. >> Is IP a failure? JCK> But IP, and the post-split TCP/IP, started from, I think, a JCK> fairly comprehensive understanding of what problems people were JCK> trying to solve. Your example, along with the email JCK> transfer/content split, has more to do with effective JCK> modularization of the solution(s) than it does with a particular JCK> style of development. With TCP/IP, perhaps. With email, I believe not. Frankly I would say that email was extremely accidental, in its architecture. Yes, the FTP mail commands were planned from the start, but standardizing the headers was done 5 years later, a separate email transfer protocol done 5 years after that, and the effort to make the body support multi-media content was done yet another 10 years later. Email addressing was no better. Ray Tomlinson just stuck the @host onto an existing structure. The architectural "brilliance" that came from such incremental growth was that the rest of the net was not allowed to know anything about the left-hand side (the mailbox) but only the domain of control (the host). (And let me explain that I put the quotation marks around brilliance not to diminish the importance, but to highlight that this kind of excellent work is marked by doing less, not more.) This left an extremely powerful back door for addressing extensions. By contrast, X.400 suffered very seriously because it insisted that there be global semantics to the whole string. (And -- surprise! -- we get into trouble, today, when relays commit the sin of thinking they know something about the syntax or semantics of the left-hand side.) I haven't asked Ray about his approach to addressing, and believe he was simply doing the minimum necessary to get the thing to work. I do not believe he had any sort of grand, global scheme for the entire address. My recollection is that the work on RFC733, in 1977, also did not get more "sophisticated" with respect to the overall addressing model, although we did add a feature for source-routing that proved useless. And when RFC822 added domain name structure to the right-hand side, it was again a small modification to a localized part of the architecture. Clearly, MIME worked the same way. So, none of this came from grand planning, at any point along the way, in my opinion. It did, however, benefit from some type of consistency in architectural thinking at each incremental effort. Maybe. But I am hard-pressed to claim it was even conscious or "coordinated". JCK> Indeed, if one goes back and examines the JCK> history of the transfer/content split in email, a case can be JCK> made that, as with IP, the two started out fairly integrated and JCK> were split up after the advantages of that became clear. I completely disagree. The entire process was highly fragmented and asynchronous. JCK> To the extent to which that is true, neither one is a good example JCK> of _design_ or _development_ on a "small pieces" basis: rather, JCK> they are examples of redefinition of the problem and JCK> remodularization of the solution after the initial design and JCK> development were complete. Nope. For email, definitely disagree. >> In fact, this highlights one of the other, surprising benefits >> of a divide-and-conquer approach, namely that it permits >> post-hoc additions that were not planned. JCK> Again, I suggest that the advantages you are claiming here --and JCK> with which I agree-- are due to effective modularization, rather JCK> than a particular development approach (such as "divide and JCK> conquer"). I think that "effective modularization" and "divide and conquer" are the same thing... Hmmmm. I suspect I am using the term divide and conquer more loosely than you. (That got me in trouble on my Ph.D. qualifying exam, and guess what degree I did not get...) JCK> And I believe we are more likely to get the JCK> modularization right if we have a moderately complete JCK> understanding of the problem --a systems analysis of properties, JCK> relationships, and interactions-- rather than if we start JCK> carving off pieces of the problem piecemeal on the assumption JCK> that we can always fit things back together later. The bottom line is that I believe there needs to be good consideration of the larger issues, too. The question comes back to those matters of 'balance' and 'skill'. So the real question is what can we do with these larger problem spaces to facilitate small, rapid development of independently-useful components that will fit into a larger scheme and support a reasonable degree of system scaling? (When we answer that, there are two activities we should pursue next. One involves the purchase of a certain bridge into New York City and the other involves world peace.) d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Fri Jul 4 10:35:06 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28192 for ; Fri, 4 Jul 2003 10:35:04 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E0F806259C; Fri, 4 Jul 2003 16:34:33 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5895861C73 for ; Fri, 4 Jul 2003 16:34:31 +0200 (CEST) Received: from newdev.harvard.edu (localhost [127.0.0.1]) by newdev.harvard.edu (8.12.9/8.12.2) with ESMTP id h64EYQDw014613 for ; Fri, 4 Jul 2003 10:34:26 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.9/8.12.2/Submit) id h64EYQj6014612 for problem-statement@alvestrand.no; Fri, 4 Jul 2003 10:34:26 -0400 (EDT) Date: Fri, 4 Jul 2003 10:34:26 -0400 (EDT) From: Scott Bradner Message-Id: <200307041434.h64EYQj6014612@newdev.harvard.edu> To: problem-statement@alvestrand.no Subject: re: ADs who are also WG chairs X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Phill susggests > Replace the subjective 'consensus' with something objective and measureable even though this is the problem not the solution list, can you suggest ways to do this in the IETF with its undefined membership and combination of face to face and mailing list work? Scot From problem-statement-bounces@alvestrand.no Fri Jul 4 11:02:12 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28783 for ; Fri, 4 Jul 2003 11:02:11 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C9C626257B; Fri, 4 Jul 2003 17:01:40 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from harrier.mail.pas.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0CCA662205 for ; Fri, 4 Jul 2003 17:01:39 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by harrier.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19YS47-0007A6-00; Fri, 04 Jul 2003 08:01:35 -0700 Date: Fri, 4 Jul 2003 10:57:42 -0400 From: Keith Moore To: "Hallam-Baker, Phillip" Message-Id: <20030704105742.08e96c32.moore@cs.utk.edu> In-Reply-To: <2A1D4C86842EE14CA9BC80474919782E0D22BA@mou1wnexm02.verisign.com> References: <2A1D4C86842EE14CA9BC80474919782E0D22BA@mou1wnexm02.verisign.com> X-Mailer: Sylpheed version 0.9.1 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Cc: moore@cs.utk.edu Subject: Re: ADs who are also WG chairs X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit ] I can see an alternative to decisions by a small clique, it is called ] democracy. as soon as you figure out a way for the users of the Internet to vote (and for them to understand what they're voting on) I'm all for it. but since we both know that's infeasible, it's clear that you don't really want democracy. From problem-statement-bounces@alvestrand.no Fri Jul 4 11:02:49 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28806 for ; Fri, 4 Jul 2003 11:02:48 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 62C486259C; Fri, 4 Jul 2003 17:02:18 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by eikenes.alvestrand.no (Postfix) with ESMTP id 64A4A62205 for ; Fri, 4 Jul 2003 17:02:16 +0200 (CEST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h64EaJf28941 for ; Fri, 4 Jul 2003 07:36:19 -0700 Date: Fri, 4 Jul 2003 07:36:19 -0700 (PDT) From: Bernard Aboba To: problem-statement@alvestrand.no Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Revised COACH BOF Agenda X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Comprehensive apprOACH to quality BOF (COACH) Monday, July 14 at 0900-1130 ============================= CHAIRS: Bernard Aboba John Loughney Mailing list: ietf-quality@bogus.com FULL DESCRIPTION: This BOF will focus on proposals for quality improvement within the IETF process, and determine if there is enough substance to work on a framework within which these proposals are evaluated. The outcome of the BOF will be to determine how best to proceed with these issues in the IETF. There are concerns about the quality and timeliness of IETF output. These problems are enumerated in the IETF Problem Statement, currently under development in the Problem Statement Working Group. The current IETF Problem Resolution Process document suggests that a Working Group be formed to improve the quality processes, including review processes, used by IETF Working Groups. The goals of this BOF will be to determine a basic approach that the IETF could take to WG process improvement, examine some of the documented proposal for process improvement, and determine if there is enough interest and content to warrant the creation of a WG to improve the quality processes used by Working Groups. One goal is to write one or more documents on aspects of a WG quality plan. For example, a document on tracking tools - what's available, and more importantly, how to use them to improve quality. Another document on reviews - how they might be conducted, the rules for reviewing, choosing reviewers, etc. Another document providing a sample Working Group quality plan. The benefit of this is that it while it requires Working Groups to think about the issue, it doesn't require that all working groups come up with the same plan. READING LIST: http://www.ietf.org/rfc/rfc2360.txt http://www.ietf.org/internet-drafts/draft-loughney-coach-00.txt http://www.ietf.org/internet-drafts/draft-ietf-problem-issue-statement-01.txt http://www.ietf.org/internet-drafts/draft-ietf-problem-process-00.txt http://www.ietf.org/internet-drafts/draft-wasserman-wg-process-00.txt http://www.ietf.org/internet-drafts/draft-klensin-overload-00.txt http://www.ietf.org/internet-drafts/draft-carpenter-solution-sirs-01.txt AGENDA: Agenda Bashing (5 minutes) Introduction (10 minutes) Existing RFC editorial guidelines - Scott Bradner http://www.ietf.org/rfc/rfc2360.txt Quality: Overview and Framework (20 minutes) A Comprehensive Approach to Quality (10 minutes), Bernard Aboba http://www.ietf.org/internet-drafts/draft-loughney-coach-00.txt IETF Problem Resolution Processes (10 minutes) - Margaret Wasserman http://www.ietf.org/internet-drafts/draft-ietf-problem-process-00.txt Starting New Work (20 minutes) The BOF Process: A Critique (10 minutes) Leslie Daigle IESG Overload and Quality of WGs (10 minutes) - John Klensin http://www.ietf.org/internet-drafts/draft-klensin-overload-00.txt The WG Process (10 minutes) Decision points/milestones in the WG process (10 minutes) - Margaret Wasserman http://www.ietf.org/internet-drafts/draft-wasserman-wg-process-00.txt The Review Process (20 minutes) Careful Additional Review of Documents (CARD) (10 minutes) - Brian Carpenter http://www.ietf.org/internet-drafts/draft-carpenter-solution-sirs-01.txt The Review Process in Action: The DCCP WG (10 minutes) - Aaron Falk & Allison Mankin Summary and Discussion (20 minutes) From problem-statement-bounces@alvestrand.no Fri Jul 4 11:09:10 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28923 for ; Fri, 4 Jul 2003 11:09:09 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id F0B8C6257B; Fri, 4 Jul 2003 17:08:38 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by eikenes.alvestrand.no (Postfix) with ESMTP id CECF262205 for ; Fri, 4 Jul 2003 17:08:35 +0200 (CEST) Received: from mou1wnexc02.verisign.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.9/) with ESMTP id h64F8Ych006966 for ; Fri, 4 Jul 2003 08:08:34 -0700 (PDT) Received: by mou1wnexc02.verisign.com with Internet Mail Service (5.5.2653.19) id ; Fri, 4 Jul 2003 08:08:34 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E0D22BC@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'problem-statement@alvestrand.no'" Date: Fri, 4 Jul 2003 08:08:34 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: MAJOR ISSUE: "Concentration of power" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no >Firstly I believe that this issue, in somewhat different words, is >covered in the draft. I don't think that the establishment understand the problem yet. There are two concentrations of power. Within the IETF there is an establishment that effectively controls the whole process. Outside the IETF there is a group of vendors and open source hackers who effectively control what goes into the applications people use. There is almost NO overlap between the two power concentrations. This situation is simply not stable, particularly given the behavior of the establishement of late. >Secondly, the IETF isn't structured as a democracy. The IETF is structured to maintain an imbalance of power in favor of the establishment, power that they would otherwise not hold. The IETF was functioning up to the point where the people with the application deployment power lost confidence that the establishment was prepared to act as a partner. Five years ago there was an advantage to allowing the IETF establishment to act in the way it did. The Internet market was highly competative and it was better to allow the IETF establishment to control the process rather than risk power falling into a competitor's hands. Today the situation is very different. Control of a standards process by a competitor is now a much lower concern than a standards process that is so slow that the standard never makes it to market. So the incentive to put up with arbitrary actions by the IETF establishment is gone. >Finally, there have been quite a few appeals. Apellants I can remember >without searching are Dave Crocker, Dan Bernstein, Dave Perkins, >Bill Simpson and Robert Elz. Lets take a look at some, Dan Bernstein - This appeal was over the posting policy to the DNSEXT mailing list, apparently a perenial problem area. The appeals statement does not give any confidence, it does not address the substance of the complaint at all. Instead it merely states that the IAB is confident that the proper PROCESS has been applied and that Bernstein was able to RAISE HIS CONCERNS with the ADs. This statement illustrates what is wrong with the IETF appeals process. It refuses to address the substance of any complaint. That is why I and others have zero confidence in it. The process appears to be nothing more than a sop to avoid aggrieved parties resorting to littigation. Bill Simpson - The remarkable fact of the IAB appeal is that it actually accepts almost all the substantive points raised by Bill as fact but refuses to act on them in the particular. What I am seeing here is chopped logic, similar to that I see from the USPTO. Challenge the USPTO over the award of an obvious patent and you get back 'that is what the rules say, obviuous has different meaning', challenge the public interest in awarding obvious patents and you get back 'patents must not be obvious'. I get the same feeling reading this thread. The appeals process is held out as the solution to all ills. Then when we get down to specifics we find that it is so narrowly focused that it will refuse all appeals on the merits of the case and focus only on whether the process was or was not followed. This means that the appeals process is completely useless as a counterbalance to a process that allows WG chairs and ADs to do whatever they like. Phill From problem-statement-bounces@alvestrand.no Fri Jul 4 11:17:55 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29091 for ; Fri, 4 Jul 2003 11:17:54 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D36026257B; Fri, 4 Jul 2003 17:17:24 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by eikenes.alvestrand.no (Postfix) with ESMTP id CB30F62205 for ; Fri, 4 Jul 2003 17:17:22 +0200 (CEST) Received: from mou1wnexc01.verisign.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.9/) with ESMTP id h64FHL2Q002937 for ; Fri, 4 Jul 2003 08:17:21 -0700 (PDT) Received: by mou1wnexc01.verisign.com with Internet Mail Service (5.5.2653.19) id ; Fri, 4 Jul 2003 08:17:21 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E0D22BD@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'problem-statement@alvestrand.no'" Date: Fri, 4 Jul 2003 08:17:20 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: ADs who are also WG chairs X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no >even though this is the problem not the solution list, can you suggest ways >to do this in the IETF with its undefined membership and combination >of face to face and mailing list work? As I said before, look at the way it is working today in OASIS. You cannot claim that something is impossible in the face of an existence proof. Step one - election of IAB and IESG. All members of the IAB and IESG to be directly elected by the membership of the IETF as currently defined for the purposes of NOMCON membership. i.e. all persons who have attended two out of the past three IETFs get a vote. The voting process itself to be managed via a Web interface, software for the purpose has been developed by Ron Rivest's students at MIT. Step two - WG decisions. In OASIS the membership of a WG requires attendance at meetings, both face to face and in con-calls. Anyone present at the first meeting is automatically a member. To maintain membership you have to attend a certain proportion of the meetings and con calls. Anyone can apply to join at any time, however they do not get voting privs until they have attended a certain number of meetings. Yes, I am aware that this limits decision making to people who actually care enough to attend the con-calls. That is a good thing. It has not in my experience excluded any participant who wanted to contribute. There are plenty of academics participating in the OASIS process. Step three - Roberts rules of order. Phill From problem-statement-bounces@alvestrand.no Fri Jul 4 11:19:01 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29141 for ; Fri, 4 Jul 2003 11:19:00 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 50CDF6257B; Fri, 4 Jul 2003 17:18:31 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by eikenes.alvestrand.no (Postfix) with ESMTP id D111462205 for ; Fri, 4 Jul 2003 17:18:28 +0200 (CEST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h64EqWN29796 for ; Fri, 4 Jul 2003 07:52:32 -0700 Date: Fri, 4 Jul 2003 07:52:31 -0700 (PDT) From: Bernard Aboba To: problem-statement@alvestrand.no Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: MAJOR ISSUE: Causes of "problems" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no If a "problem" now exists where formerly there was none, a logical question to ask is "what changed?" So I'm curious as to what people think some of the underlying *causes* of the "problems" are. There has been discussion of an increase in complexity due to the need to address security. Another potential cause for discussion: scope expansion. It can be argued that two of the major trends of the last few years are "IP Everywhere" and "Ethernet everywhere". No surprise then that both the IETF and IEEE 802 have grown considerably over the period, incorporating work that might have previously been handled in other standards bodies and forums. For example, over the last 5 years, the IETF has expanded its scope to work on topics such as VOIP, SUB-IP, RDMA, IP Storage, etc. Each of those expansions has required the IETF to accomodate a new group of attendees, so that today many IETF partipants also participate in other standards bodies such as ITU, ATM/Frame Relay/MPLS forum, 3GPP, 3GPP2, IEEE 802, InfiniBand Trade Association, T10/T11, etc. This is a bit akin to a company executing a series of mergers over the years, trying to knit a patch work quilt of acquisitions into a coherent whole. It's difficult to do even with good management and lots of resources -- but in the case of the IETF, additional management bandwidth and resources may not necessarily be considered during the scope expansion discussion. So is "scope expansion" a potential *cause* of "problems"? Or is it a "problem" in its own right? From problem-statement-bounces@alvestrand.no Fri Jul 4 11:45:20 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00020 for ; Fri, 4 Jul 2003 11:45:18 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CBC476257B; Fri, 4 Jul 2003 17:44:48 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5B51361C73; Fri, 4 Jul 2003 17:44:48 +0200 (CEST) Date: Fri, 04 Jul 2003 17:44:48 +0200 From: Harald Tveit Alvestrand To: "Hallam-Baker, Phillip" , "'problem-statement@alvestrand.no'" Message-ID: <421540000.1057333488@askvoll.hjemme.alvestrand.no> In-Reply-To: <2A1D4C86842EE14CA9BC80474919782E0D22BD@mou1wnexm02.verisign.com> References: <2A1D4C86842EE14CA9BC80474919782E0D22BD@mou1wnexm02.verisign.com > X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Robert's Rules (Re: ADs who are also WG chairs) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit --On fredag, juli 04, 2003 08:17:20 -0700 "Hallam-Baker, Phillip" wrote: > > Step three - Roberts rules of order. > serious question: do you have an example of a version of Robert's rules of order that has successfully been applied to mailing lists? RR has a number of concepts that are hard to apply to a mailing list - recognition of speakers by the chair, expulsion from the room of disorderly members, voting in real time on points of procedure, for instance. I'd be interested in hearing of examples of successful adaptations. I've been involved in one or two other attempts to call on Robert's rules when mailing lists were part of the context, and they usually petered into nothing when people started following the pointers and actually *reading* the Robert's Rules books - there are just so many concepts that need adaption. It may be possible, may even be very useful - but it certainly isn't obvious. RR has sometimes been described as "how to make decisions in an orderly fashion with participants who don't trust each other one bit". We might need that model at times. Harald From problem-statement-bounces@alvestrand.no Fri Jul 4 11:48:19 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00095 for ; Fri, 4 Jul 2003 11:48:18 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3E36262205; Fri, 4 Jul 2003 17:47:48 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from grebe.mail.pas.earthlink.net (grebe.mail.pas.earthlink.net [207.217.120.46]) by eikenes.alvestrand.no (Postfix) with ESMTP id E82E261C73 for ; Fri, 4 Jul 2003 17:47:46 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by grebe.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19YSmj-00076B-00; Fri, 04 Jul 2003 08:47:42 -0700 Date: Fri, 4 Jul 2003 11:43:49 -0400 From: Keith Moore To: "Hallam-Baker, Phillip" Message-Id: <20030704114349.3647c3d5.moore@cs.utk.edu> In-Reply-To: <2A1D4C86842EE14CA9BC80474919782E0D22BD@mou1wnexm02.verisign.com> References: <2A1D4C86842EE14CA9BC80474919782E0D22BD@mou1wnexm02.verisign.com> X-Mailer: Sylpheed version 0.9.1 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Cc: moore@cs.utk.edu Subject: Re: ADs who are also WG chairs X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit ] Yes, I am aware that this limits decision making to people who actually care ] enough to attend the con-calls. That is a good thing. yeah, it makes it really easy for the WG leadership to exclude anyone who doesn't get paid to do standards work. WGs are too narrow already. From problem-statement-bounces@alvestrand.no Fri Jul 4 11:54:14 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00226 for ; Fri, 4 Jul 2003 11:54:13 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E674662205; Fri, 4 Jul 2003 17:53:43 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [194.196.100.234]) by eikenes.alvestrand.no (Postfix) with ESMTP id C897B61C73 for ; Fri, 4 Jul 2003 17:53:41 +0200 (CEST) Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180])h64Frd76082798; Fri, 4 Jul 2003 17:53:40 +0200 Received: from ochsehorn.zurich.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228])h64Frap8240300; Fri, 4 Jul 2003 17:53:38 +0200 Received: from dhcp22-107.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA42236 from ; Fri, 4 Jul 2003 17:53:34 +0200 Message-Id: <3F05A30D.B6675C80@hursley.ibm.com> Date: Fri, 04 Jul 2003 17:53:49 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: "Hallam-Baker, Phillip" References: <2A1D4C86842EE14CA9BC80474919782E0D22BD@mou1wnexm02.verisign.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "'problem-statement@alvestrand.no'" Subject: Re: ADs who are also WG chairs X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit What's to stop Big Bad Company stuffing an Oasis WG with ringers? What's to stop a commercial grouping pushing something through an Oasis WG that is good for them and harmful to the Internet? How can Roberts' Rules be applied on a mailing list? (I'm not trying to make debating points - I really am concerned that these are serious weaknesses in the model you describe. And I spent two years chairing a Board that supposedly followed Roberts' Rules and used email extensively, and I can't answer the third question.) Brian "Hallam-Baker, Phillip" wrote: > > >even though this is the problem not the solution list, can you suggest ways > >to do this in the IETF with its undefined membership and combination > >of face to face and mailing list work? > > As I said before, look at the way it is working today in OASIS. You cannot > claim that something is impossible in the face of an existence proof. > > Step one - election of IAB and IESG. > > All members of the IAB and IESG to be directly elected by the membership of > the IETF as currently defined for the purposes of NOMCON membership. i.e. > all persons who have attended two out of the past three IETFs get a vote. > > The voting process itself to be managed via a Web interface, software for > the purpose has been developed by Ron Rivest's students at MIT. > > Step two - WG decisions. > > In OASIS the membership of a WG requires attendance at meetings, both face > to face and in con-calls. Anyone present at the first meeting is > automatically a member. To maintain membership you have to attend a certain > proportion of the meetings and con calls. Anyone can apply to join at any > time, however they do not get voting privs until they have attended a > certain number of meetings. > > Yes, I am aware that this limits decision making to people who actually care > enough to attend the con-calls. That is a good thing. It has not in my > experience excluded any participant who wanted to contribute. There are > plenty of academics participating in the OASIS process. > > Step three - Roberts rules of order. > > Phill From problem-statement-bounces@alvestrand.no Fri Jul 4 12:00:55 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00377 for ; Fri, 4 Jul 2003 12:00:54 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7DF7E62205; Fri, 4 Jul 2003 18:00:24 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from sentosa.post1.com (sentosa.post1.com [202.27.17.100]) by eikenes.alvestrand.no (Postfix) with SMTP id D57CD61C73 for ; Fri, 4 Jul 2003 18:00:21 +0200 (CEST) Received: (qmail 11318 invoked from network); 4 Jul 2003 16:06:34 -0000 Received: from bb-203-125-7-219.singnet.com.sg (HELO pobox.org.sg) (203.125.7.219) by sentosa.post1.com with SMTP; 4 Jul 2003 16:06:34 -0000 Message-ID: <3F05A4A6.3010902@pobox.org.sg> Date: Sat, 05 Jul 2003 00:00:38 +0800 From: James Seng User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en, zh-cn, zh-tw, ja, ko MIME-Version: 1.0 To: "Hallam-Baker, Phillip" References: <2A1D4C86842EE14CA9BC80474919782E0D22BD@mou1wnexm02.verisign.com> In-Reply-To: <2A1D4C86842EE14CA9BC80474919782E0D22BD@mou1wnexm02.verisign.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "'problem-statement@alvestrand.no'" Subject: Re: ADs who are also WG chairs X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit While this is off-topic, one should note that 1. OASIS is a paid-membership group. Some would considered that the fact it is paid-membership makes is exclusive (altho not exactly closed). 2. IETF dont have "members", or at least similar to OASIS. Participating in IETF are usually free (excluding cost of attending IETF meetings) so any formal voting process, web-based or otherwise, arent likely going to work. (If in doubt, look at GA@ICANN). 3. OASIS is a coporate-centric organization whereas IETF is an individual-centeric organization. (This is not to say individual cant participate in OASIS or coporate cant participate in IETF...) Are we prepared to make this big switch making IETF an industry consortium? -James Seng Hallam-Baker, Phillip wrote: >>even though this is the problem not the solution list, can you suggest ways >>to do this in the IETF with its undefined membership and combination >>of face to face and mailing list work? > > > As I said before, look at the way it is working today in OASIS. You cannot > claim that something is impossible in the face of an existence proof. > > > Step one - election of IAB and IESG. > > All members of the IAB and IESG to be directly elected by the membership of > the IETF as currently defined for the purposes of NOMCON membership. i.e. > all persons who have attended two out of the past three IETFs get a vote. > > The voting process itself to be managed via a Web interface, software for > the purpose has been developed by Ron Rivest's students at MIT. > > > Step two - WG decisions. > > In OASIS the membership of a WG requires attendance at meetings, both face > to face and in con-calls. Anyone present at the first meeting is > automatically a member. To maintain membership you have to attend a certain > proportion of the meetings and con calls. Anyone can apply to join at any > time, however they do not get voting privs until they have attended a > certain number of meetings. > > Yes, I am aware that this limits decision making to people who actually care > enough to attend the con-calls. That is a good thing. It has not in my > experience excluded any participant who wanted to contribute. There are > plenty of academics participating in the OASIS process. > > > Step three - Roberts rules of order. > > > Phill > > From problem-statement-bounces@alvestrand.no Fri Jul 4 12:04:14 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00521 for ; Fri, 4 Jul 2003 12:04:13 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 450D761C73; Fri, 4 Jul 2003 18:03:44 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [194.196.100.234]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1B92C61A96 for ; Fri, 4 Jul 2003 18:03:42 +0200 (CEST) Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180])h64G3Z76031200; Fri, 4 Jul 2003 18:03:35 +0200 Received: from ochsehorn.zurich.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228])h64G3Wp8159128; Fri, 4 Jul 2003 18:03:33 +0200 Received: from dhcp22-107.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA17788 from ; Fri, 4 Jul 2003 18:03:30 +0200 Message-Id: <3F05A561.8E60F70D@hursley.ibm.com> Date: Fri, 04 Jul 2003 18:03:45 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Bernard Aboba References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: MAJOR ISSUE: Causes of "problems" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Bernard Aboba wrote: ... > > So is "scope expansion" a potential *cause* of "problems"? Or is it a > "problem" in its own right? I think it's really just global warming - i.e. something we have to deal with as a given. Brian From problem-statement-bounces@alvestrand.no Fri Jul 4 12:08:33 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00819 for ; Fri, 4 Jul 2003 12:08:32 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C634162205; Fri, 4 Jul 2003 18:08:02 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from sentosa.post1.com (sentosa.post1.com [202.27.17.100]) by eikenes.alvestrand.no (Postfix) with SMTP id 946FB61C73 for ; Fri, 4 Jul 2003 18:07:59 +0200 (CEST) Received: (qmail 11366 invoked from network); 4 Jul 2003 16:14:14 -0000 Received: from bb-203-125-7-219.singnet.com.sg (HELO pobox.org.sg) (203.125.7.219) by sentosa.post1.com with SMTP; 4 Jul 2003 16:14:14 -0000 Message-ID: <3F05A672.9060405@pobox.org.sg> Date: Sat, 05 Jul 2003 00:08:18 +0800 From: James Seng User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en, zh-cn, zh-tw, ja, ko MIME-Version: 1.0 To: Harald Tveit Alvestrand References: <2A1D4C86842EE14CA9BC80474919782E0D22BD@mou1wnexm02.verisign.com > <421540000.1057333488@askvoll.hjemme.alvestrand.no> In-Reply-To: <421540000.1057333488@askvoll.hjemme.alvestrand.no> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "'problem-statement@alvestrand.no'" Cc: "Hallam-Baker, Phillip" Subject: Re: Robert's Rules (Re: ADs who are also WG chairs) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Remember the discussion of functional vs. ceremorial meeting? The Robert's rule of order is the latter. If we taking this path, we might as well merge with JTC1. -James Seng Harald Tveit Alvestrand wrote: > > > --On fredag, juli 04, 2003 08:17:20 -0700 "Hallam-Baker, Phillip" > wrote: > >> >> Step three - Roberts rules of order. >> > > serious question: > > do you have an example of a version of Robert's rules of order that has > successfully been applied to mailing lists? > > RR has a number of concepts that are hard to apply to a mailing list - > recognition of speakers by the chair, expulsion from the room of > disorderly members, voting in real time on points of procedure, for > instance. I'd be interested in hearing of examples of successful > adaptations. > > I've been involved in one or two other attempts to call on Robert's > rules when mailing lists were part of the context, and they usually > petered into nothing when people started following the pointers and > actually *reading* the Robert's Rules books - there are just so many > concepts that need adaption. It may be possible, may even be very useful > - but it certainly isn't obvious. > > RR has sometimes been described as "how to make decisions in an orderly > fashion with participants who don't trust each other one bit". We might > need that model at times. > > Harald > > From problem-statement-bounces@alvestrand.no Fri Jul 4 12:12:21 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00944 for ; Fri, 4 Jul 2003 12:12:21 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5DC0361C73; Fri, 4 Jul 2003 18:11:51 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0B30C61A96 for ; Fri, 4 Jul 2003 18:11:49 +0200 (CEST) Received: from mou1wnexc01.verisign.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.9/) with ESMTP id h64GBm2Q011420; Fri, 4 Jul 2003 09:11:48 -0700 (PDT) Received: by mou1wnexc01.verisign.com with Internet Mail Service (5.5.2653.19) id ; Fri, 4 Jul 2003 09:11:48 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E0D22BF@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'Brian E Carpenter'" , "Hallam-Baker, Phillip" Date: Fri, 4 Jul 2003 09:11:48 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Cc: "'problem-statement@alvestrand.no'" Subject: RE: ADs who are also WG chairs X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no > What's to stop Big Bad Company stuffing an Oasis WG with ringers? What is to stop them doing that in an IETF WG? Since everyone is theoretically participating as an individual I can't see how the WG Chair could claim consensus if big bad company wanted to block something. Oh yes, sorry I remember the WG chair can claim consensus because at the end of the day it is only his opinion that matters. See DNSEXT for details. > What's to stop a commercial grouping pushing something through > an Oasis WG that is good for them and harmful to the Internet? Same as when the IETF proposes something that would be harmful, the community of users rejects a protocol that it does not want. But it is a good question since there are far more companies with market power who are now participating in OASIS than are currently fully engaged in IETF process. So if there is a risk that 'evil' protocols come from OASIS and 'corrupt' the Internet then that is going to be happening regardless of what the opinion is here. > How can Roberts' Rules be applied on a mailing list? Roberts rules are not directly applicable to a mailing list since it is asynchronous conversation. They are applicable to conference calls and in person meetings. Even so we have had many successful polls through mailing lists, in many cases using Quaker polls and other consensus finding processes rather than the more divisive up or down questions we see in IETF process. > (I'm not trying to make debating points - I really am concerned > that these are serious weaknesses in the model you describe. And I > spent two years chairing a Board that supposedly followed Roberts' > Rules and used email extensively, and I can't answer the third > question.) And your evidence for thinking that the IETF approach is working at any level would be what? Phill From problem-statement-bounces@alvestrand.no Fri Jul 4 12:38:46 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01744 for ; Fri, 4 Jul 2003 12:38:45 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6580A62205; Fri, 4 Jul 2003 18:38:16 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5E50961A96 for ; Fri, 4 Jul 2003 18:38:13 +0200 (CEST) Received: from mou1wnexc01.verisign.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.9/) with ESMTP id h64GcC2Q013847; Fri, 4 Jul 2003 09:38:12 -0700 (PDT) Received: by mou1wnexc01.verisign.com with Internet Mail Service (5.5.2653.19) id ; Fri, 4 Jul 2003 09:38:12 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E0D22C0@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'James Seng'" , "Hallam-Baker, Phillip" Date: Fri, 4 Jul 2003 09:38:12 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Cc: "'problem-statement@alvestrand.no'" Subject: RE: ADs who are also WG chairs X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no > 1. OASIS is a paid-membership group. Some would considered > that the fact > it is paid-membership makes is exclusive (altho not exactly closed). This is irrelevant, that aspect of OASIS is not essential to the points I raised. Also the right to vote as an OASIS member is not the same as the right to vote in a TC. An individual member of OASIS pays a reduced subscription and does not get a vote in OASIS governance issues, mention in press releases etc. However an individual member or even a non-member contributor has the same voting rights in a TC. > 2. IETF dont have "members", or at least similar to OASIS. There are plenty of proxies for membership that can be effected. > Participating > in IETF are usually free (excluding cost of attending IETF > meetings) so > any formal voting process, web-based or otherwise, arent > likely going to > work. (If in doubt, look at GA@ICANN). I see no conflict between membership being free and having voting. The only reason there is a charge to join OASIS is the need to pay the administrative costs. The IETF has found an alternative solution. I fail to see the relevance of ICANN processes here. > 3. OASIS is a coporate-centric organization whereas IETF is an > individual-centeric organization. (This is not to say individual cant > participate in OASIS or coporate cant participate in IETF...) > > Are we prepared to make this big switch making IETF an > industry consortium? Again that is not being proposed, you are raising a false dichotomy. The choice is between taking action to make the IETF internal processes open democratic and accountable allowing the IETF to continue to direct Internet standards development as a voluntary body or attempting to continue with the status quo where control inside the IETF is vested in a small unaccountable clique and vendors increasingly abandon IETF process for more open forums. Attempting to maintain the status quo will result in the exact situation you are trying to prevent. Phill From problem-statement-bounces@alvestrand.no Fri Jul 4 12:45:33 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01822 for ; Fri, 4 Jul 2003 12:45:33 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2BEDD6257B; Fri, 4 Jul 2003 18:45:03 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7800761A96; Fri, 4 Jul 2003 18:45:00 +0200 (CEST) Received: from mou1wnexc02.verisign.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.9/) with ESMTP id h64Gixch022649; Fri, 4 Jul 2003 09:44:59 -0700 (PDT) Received: by mou1wnexc02.verisign.com with Internet Mail Service (5.5.2653.19) id ; Fri, 4 Jul 2003 09:44:59 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E0D22C1@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'Harald Tveit Alvestrand'" , "Hallam-Baker, Phillip" , "'problem-statement@alvestrand.no'" Date: Fri, 4 Jul 2003 09:44:59 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Robert's Rules (Re: ADs who are also WG chairs) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no > serious question: > > do you have an example of a version of Robert's rules of > order that has > successfully been applied to mailing lists? This was the subject of some study by my group when I was at IETF. We ran an Open Meeting over the Internet for Vice President Al Gore. That was a moderated forum using an adapted form of Recher's dialectic, however the moderation was not essential in that case. > RR has a number of concepts that are hard to apply to a > mailing list - > recognition of speakers by the chair, expulsion from the room > of disorderly > members, voting in real time on points of procedure, for > instance. I'd be > interested in hearing of examples of successful adaptations. Some of the rules are not appropriate because the constraints are not. For example it is not necessary to require recognition by the chair since it is possible for more than one person to speak at once. The key point is what to do with respect to decisions and what to do with in person and conference call meeting time. What we do in OASIS in most cases is to run with an abreviated version of the rules except when there is an actual controversy and someone wants to make sure process is followed. Phill From problem-statement-bounces@alvestrand.no Fri Jul 4 12:53:52 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01899 for ; Fri, 4 Jul 2003 12:53:51 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 16F5061C2B; Fri, 4 Jul 2003 18:53:22 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by eikenes.alvestrand.no (Postfix) with ESMTP id 31B0761A96 for ; Fri, 4 Jul 2003 18:53:20 +0200 (CEST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h64GrDN16220; Fri, 4 Jul 2003 12:53:14 -0400 (EDT) Date: Fri, 4 Jul 2003 12:53:13 -0400 From: Keith Moore To: "Hallam-Baker, Phillip" Message-Id: <20030704125313.374be83d.moore@cs.utk.edu> In-Reply-To: <2A1D4C86842EE14CA9BC80474919782E0D22BF@mou1wnexm02.verisign.com> References: <2A1D4C86842EE14CA9BC80474919782E0D22BF@mou1wnexm02.verisign.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: pbaker@verisign.com Cc: moore@cs.utk.edu Cc: brian@hursley.ibm.com Cc: problem-statement@alvestrand.no Subject: Re: ADs who are also WG chairs X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit > Same as when the IETF proposes something that would be harmful, the > community of users rejects a protocol that it does not want. to a large degree, users have to take what vendors give them. to some extent users trust the IETF to specify what will work well. if we fail to do that, we become irrelevant. > Even so we have had many successful polls through mailing lists, > in many cases using Quaker polls and other consensus finding > processes rather than the more divisive up or down questions we > see in IETF process. sounds good. I'd love to see pointers to descriptions of these things; we certainly need to find better ways to conduct mailing list discussions. Keith From problem-statement-bounces@alvestrand.no Fri Jul 4 12:56:36 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01966 for ; Fri, 4 Jul 2003 12:56:36 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 992C8625A7; Fri, 4 Jul 2003 18:56:06 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id DED7E61C2B; Fri, 4 Jul 2003 18:56:04 +0200 (CEST) Date: Fri, 04 Jul 2003 18:56:05 +0200 From: Harald Tveit Alvestrand To: "Hallam-Baker, Phillip" , "'problem-statement@alvestrand.no'" Message-ID: <427280000.1057337765@askvoll.hjemme.alvestrand.no> In-Reply-To: <2A1D4C86842EE14CA9BC80474919782E0D22C1@mou1wnexm02.verisign.com> References: <2A1D4C86842EE14CA9BC80474919782E0D22C1@mou1wnexm02.verisign.com > X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: RE: Robert's Rules (Re: ADs who are also WG chairs) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit --On fredag, juli 04, 2003 09:44:59 -0700 "Hallam-Baker, Phillip" wrote: > >> serious question: >> >> do you have an example of a version of Robert's rules of >> order that has >> successfully been applied to mailing lists? > > This was the subject of some study by my group when I was at IETF. We ran > an Open Meeting over the Internet for Vice President Al Gore. > > That was a moderated forum using an adapted form of Recher's dialectic, > however the moderation was not essential in that case. do you have a reference? I'm not familiar with Recher's dialectic... >> RR has a number of concepts that are hard to apply to a >> mailing list - >> recognition of speakers by the chair, expulsion from the room >> of disorderly >> members, voting in real time on points of procedure, for >> instance. I'd be >> interested in hearing of examples of successful adaptations. > > Some of the rules are not appropriate because the constraints are not. For > example it is not necessary to require recognition by the chair since it > is possible for more than one person to speak at once. > > The key point is what to do with respect to decisions and what to do with > in person and conference call meeting time. > > What we do in OASIS in most cases is to run with an abreviated version of > the rules except when there is an actual controversy and someone wants to > make sure process is followed. that's been my impression with most places that claim to follow RR too - that unless there's a conflict, things jut run in an ad-hoc fashion, but that once there is conflict, one has the ruleset to fall back on to ensure orderly and clear decision-making. And I actually think that's an eminently sensible way to run meetings, and wish we knew how to make mailing lists do that. Harald From problem-statement-bounces@alvestrand.no Fri Jul 4 13:10:03 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02198 for ; Fri, 4 Jul 2003 13:10:02 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4CE3462574; Fri, 4 Jul 2003 19:09:32 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8C24A61C2B; Fri, 4 Jul 2003 19:09:29 +0200 (CEST) Received: from MOU1WNEXC03.verisign.com (verisign.com [65.205.251.57]) by peacock.verisign.com (8.12.9/) with ESMTP id h64H9Sch027119; Fri, 4 Jul 2003 10:09:28 -0700 (PDT) Received: by mou1wnexc03.verisign.com with Internet Mail Service (5.5.2653.19) id ; Fri, 4 Jul 2003 10:09:28 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E0D22C4@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'Harald Tveit Alvestrand'" , "Hallam-Baker, Phillip" , "'problem-statement@alvestrand.no'" Date: Fri, 4 Jul 2003 10:09:25 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Robert's Rules (Re: ADs who are also WG chairs) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no > > That was a moderated forum using an adapted form of > Recher's dialectic, > > however the moderation was not essential in that case. > > do you have a reference? I'm not familiar with Recher's dialectic... http://www.amazon.com/exec/obidos/tg/detail/-/087395372X/qid=1057338215/sr=1 -29/ref=sr_1_29/102-1205297-4835306?v=glance&s=books Dialectics: A Controversy-Oriented Approach to the Theory of Knowledge by Nicholas. Rescher It is unfortunately out of print. The open meeting is described in: http://www.ai.mit.edu/projects/iiip/doc/open-meeting/abstract.html Actually reading up on the paper again I realise that actually we did not apply Rescher's dialectic in open-meeting, but we did use it in Web Interactive Talk at CERN. The open-meeting had a richer set of labels for the dialogue and was structured so as to build consensus rather than expose controversy. > > What we do in OASIS in most cases is to run with an > abreviated version of > > the rules except when there is an actual controversy and > someone wants to > > make sure process is followed. > > that's been my impression with most places that claim to > follow RR too - > that unless there's a conflict, things jut run in an ad-hoc > fashion, but > that once there is conflict, one has the ruleset to fall back > on to ensure > orderly and clear decision-making. > > And I actually think that's an eminently sensible way to run > meetings, and > wish we knew how to make mailing lists do that. I think it is a soluble problem, though not one that is likely soluble in the context of a few months. Phill From problem-statement-bounces@alvestrand.no Fri Jul 4 13:12:06 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02282 for ; Fri, 4 Jul 2003 13:12:04 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2FD4362574; Fri, 4 Jul 2003 19:11:36 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0DE3F61C2B for ; Fri, 4 Jul 2003 19:11:34 +0200 (CEST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h64HBTN16237; Fri, 4 Jul 2003 13:11:30 -0400 (EDT) Date: Fri, 4 Jul 2003 13:11:28 -0400 From: Keith Moore To: Bernard Aboba Message-Id: <20030704131128.176db2d1.moore@cs.utk.edu> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Cc: moore@cs.utk.edu Subject: Re: MAJOR ISSUE: Causes of "problems" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit > If a "problem" now exists where formerly there was none, a logical > question to ask is "what changed?" > > So I'm curious as to what people think some of the underlying *causes* > of the "problems" are. The Internet has gotten considerably larger and more diverse. It is no longer sufficient to design a protocol that will work in a benign and fairly homogeneous network for a relatively small group of researchers. The environment is no longer benign - serious large-scale distributed attacks are a weekly occurance. Network capabilities vary considerably - available bandwith between two points can vary by six orders of magnitude, maybe more. Apps now have to content with NATs, firewalls, interception proxies, and other obstacles that subtly disrupt their communications and impose arbitrary constraints on when they can communicate. Users' interests have also become quite diverse - Internet users no longer mostly speak the same language or use a uniform set of applications (although almost everyone uses email and the web, the uniformity ends there). So now we see a demand to make things work over IP that demand far more from the network than IP was ever designed to guarantee; we also see conflicts between the different demands. With the increased size we are also finding some limits to the scalability of the original design - not only in address space size but also in routing, and in (the lack of a) comprehensive security architecture. We have adopted piecemeal workarounds for some of these problems, but these conflict with one another and with legitimate uses of the network. Also, to gain consensus on a protocol it is no longer sufficient merely to find a way to solve the technical problems of how to represent the data and exchange the information. Vendors will now insist that the protocol support or even mandate their business models - even when these contradict each other or are not in the interests of users. And lacking the confidence to compete in the marketplace, some vendors have resorted to using IETF as a battleground - blocking working group activity either with political means or by the threat of IPR suits in order to coerce a particular outcome or delay the result. The low-hanging fruit has already been picked - having solved the easier problems we are now tasked with solving much more difficult ones - including problems for which there is no known solution. Given all of the above, it's amazing we're able to do any useful work at all any more. What did I leave out? From problem-statement-bounces@alvestrand.no Fri Jul 4 13:12:39 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02310 for ; Fri, 4 Jul 2003 13:12:38 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D3739625CC; Fri, 4 Jul 2003 19:12:09 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6ADB1625BA for ; Fri, 4 Jul 2003 19:12:07 +0200 (CEST) Received: from MOU1WNEXC03.verisign.com (verisign.com [65.205.251.57]) by peacock.verisign.com (8.12.9/) with ESMTP id h64HC6ch027652; Fri, 4 Jul 2003 10:12:06 -0700 (PDT) Received: by mou1wnexc03.verisign.com with Internet Mail Service (5.5.2653.19) id ; Fri, 4 Jul 2003 10:12:06 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E0D22C5@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'Keith Moore'" , "Hallam-Baker, Phillip" Date: Fri, 4 Jul 2003 10:12:06 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Cc: problem-statement@alvestrand.no Subject: RE: ADs who are also WG chairs X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no > ] Yes, I am aware that this limits decision making to people > who actually care > ] enough to attend the con-calls. That is a good thing. > > yeah, it makes it really easy for the WG leadership to > exclude anyone who doesn't > get paid to do standards work. WGs are too narrow already. No, it limits the ability to decide on a standard to the people who have sufficient time to make a contribution to the process. Attending con-calls is a much smaller commitment than reading the drafts. I don't know how to determine empirically who is reading the drafts though. phill From problem-statement-bounces@alvestrand.no Fri Jul 4 13:25:20 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02474 for ; Fri, 4 Jul 2003 13:25:19 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7236462574; Fri, 4 Jul 2003 19:24:49 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by eikenes.alvestrand.no (Postfix) with ESMTP id 65DF861C2B for ; Fri, 4 Jul 2003 19:24:47 +0200 (CEST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h64HOhN16253; Fri, 4 Jul 2003 13:24:44 -0400 (EDT) Date: Fri, 4 Jul 2003 13:24:43 -0400 From: Keith Moore To: "Hallam-Baker, Phillip" Message-Id: <20030704132443.56879820.moore@cs.utk.edu> In-Reply-To: <2A1D4C86842EE14CA9BC80474919782E0D22C5@mou1wnexm02.verisign.com> References: <2A1D4C86842EE14CA9BC80474919782E0D22C5@mou1wnexm02.verisign.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: pbaker@verisign.com Cc: moore@cs.utk.edu Cc: problem-statement@alvestrand.no Subject: Re: ADs who are also WG chairs X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit > > ] Yes, I am aware that this limits decision making to people > > ] who actually care enough to attend the con-calls. That is a good > > ] thing. > > > > yeah, it makes it really easy for the WG leadership to exclude > > anyone who doesn't get paid to do standards work. WGs are too > > narrow already. > > No, it limits the ability to decide on a standard to the people who > have sufficient time to make a contribution to the process. so all we have to do is raise the bar high enough, and we can be assured that none of the riff-raff get let in... I'm speaking from experience. Keith From problem-statement-bounces@alvestrand.no Fri Jul 4 14:50:24 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04447 for ; Fri, 4 Jul 2003 14:50:23 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5D3D562574; Fri, 4 Jul 2003 20:49:50 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by eikenes.alvestrand.no (Postfix) with ESMTP id D94C461C2B for ; Fri, 4 Jul 2003 20:49:43 +0200 (CEST) Received: from mou1wnexc02.verisign.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.9/) with ESMTP id h64Ingch019422; Fri, 4 Jul 2003 11:49:42 -0700 (PDT) Received: by mou1wnexc02.verisign.com with Internet Mail Service (5.5.2653.19) id ; Fri, 4 Jul 2003 11:49:42 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E0D22C7@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'Keith Moore'" , "Hallam-Baker, Phillip" Date: Fri, 4 Jul 2003 11:49:41 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Cc: problem-statement@alvestrand.no Cc: "Hallam-Baker, Phillip" Subject: RE: ADs who are also WG chairs X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no > > No, it limits the ability to decide on a standard to the people who > > have sufficient time to make a contribution to the process. > > so all we have to do is raise the bar high enough, and we can > be assured > that none of the riff-raff get let in... No, all that is necessary is to raise the bar high enough to stop someone from suddenly packing a meeting to force through some scheme. In practice there is no real incentive to pack a meeting if the IPR rules prohibit proprietary protocols. I have never seen a vendor led attempt to pack a meeting that did not involve some form of IPR dispute. WAP would probably have had no problems at all if they had written the rules to state that no proprietary technology would be considered if there was an unencumbered alternative. Phill From problem-statement-bounces@alvestrand.no Fri Jul 4 14:55:59 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04629 for ; Fri, 4 Jul 2003 14:55:58 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 003AD6257B; Fri, 4 Jul 2003 20:55:28 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by eikenes.alvestrand.no (Postfix) with ESMTP id 34D1962574 for ; Fri, 4 Jul 2003 20:55:21 +0200 (CEST) Received: from MOU1WNEXC03.verisign.com (verisign.com [65.205.251.57]) by peacock.verisign.com (8.12.9/) with ESMTP id h64ItKch020422 for ; Fri, 4 Jul 2003 11:55:20 -0700 (PDT) Received: by mou1wnexc03.verisign.com with Internet Mail Service (5.5.2653.19) id ; Fri, 4 Jul 2003 11:55:20 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E0D22C8@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'problem-statement@alvestrand.no'" Date: Fri, 4 Jul 2003 11:55:19 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: MAJOR ISSUE: Causes of "problems" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no >Also, to gain consensus on a protocol it is no longer sufficient merely >to find a way to solve the technical problems of how to represent >the data and exchange the information. Vendors will now insist that the >protocol support or even mandate their business models - even when these >contradict each other or are not in the interests of users. Well it is hardly surprising that companies would insist that a protocol they are being asked to support actually support their business model. If the IETF wants any vendor, ISP or end user to support the standards it suggests it had better meet their requirements. I think what we are seeing here is projection. Replace the word 'vendors' with 'narrow cliques persuing personal agendas' and you describe the actions in DNSEXT to oppose DNSSEC deployment perfectly. Phill From problem-statement-bounces@alvestrand.no Fri Jul 4 16:48:49 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07513 for ; Fri, 4 Jul 2003 16:48:48 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 89CBC6259C; Fri, 4 Jul 2003 22:48:15 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from grebe.mail.pas.earthlink.net (grebe.mail.pas.earthlink.net [207.217.120.46]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0F52A6257F for ; Fri, 4 Jul 2003 22:48:14 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by grebe.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19YXTV-0007io-00; Fri, 04 Jul 2003 13:48:09 -0700 Date: Fri, 4 Jul 2003 16:44:15 -0400 From: Keith Moore To: "Hallam-Baker, Phillip" Message-Id: <20030704164415.0f1b7cdf.moore@cs.utk.edu> In-Reply-To: <2A1D4C86842EE14CA9BC80474919782E0D22C7@mou1wnexm02.verisign.com> References: <2A1D4C86842EE14CA9BC80474919782E0D22C7@mou1wnexm02.verisign.com> X-Mailer: Sylpheed version 0.9.1 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: pbaker@verisign.com Cc: moore@cs.utk.edu Cc: problem-statement@alvestrand.no Subject: attempts to exclude people from WGs (was ADs who are also WG chairs) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit ] > > No, it limits the ability to decide on a standard to the people who ] > > have sufficient time to make a contribution to the process. ] > ] > so all we have to do is raise the bar high enough, and we can ] > be assured that none of the riff-raff get let in... ] ] No, all that is necessary is to raise the bar high enough to stop ] someone from suddenly packing a meeting to force through some ] scheme. basically any bias you add to the selection of people who are at the table will favor somebody or another, and the fact that the bias exists can be used to try to get a competitive advanage. ] In practice there is no real incentive to pack a meeting if the ] IPR rules prohibit proprietary protocols. wrong. there are other ways for a protocol to be biased in favor of one vendor or another. ] I have never seen a vendor led attempt to pack a meeting that did not ] involve some form of IPR dispute. maybe you haven't been around much. of course, these days, people will cite the DMCA as justification to call almost anything IPR. ] WAP would probably have had no problems at all if they had ] written the rules to state that no proprietary technology ] would be considered if there was an unencumbered alternative. never mind that it was a complete crock anyway. Keith From problem-statement-bounces@alvestrand.no Fri Jul 4 16:56:36 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07825 for ; Fri, 4 Jul 2003 16:56:35 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 363E56257B; Fri, 4 Jul 2003 22:56:05 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by eikenes.alvestrand.no (Postfix) with ESMTP id F138262205 for ; Fri, 4 Jul 2003 22:56:02 +0200 (CEST) Received: from MOU1WNEXC03.verisign.com (verisign.com [65.205.251.57]) by peacock.verisign.com (8.12.9/) with ESMTP id h64Ku1ch010153; Fri, 4 Jul 2003 13:56:01 -0700 (PDT) Received: by mou1wnexc03.verisign.com with Internet Mail Service (5.5.2653.19) id ; Fri, 4 Jul 2003 13:56:01 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E0D22CA@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'Keith Moore'" , "Hallam-Baker, Phillip" Date: Fri, 4 Jul 2003 13:56:01 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Cc: problem-statement@alvestrand.no Cc: "Hallam-Baker, Phillip" Subject: RE: attempts to exclude people from WGs (was ADs who are also WG chairs) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no > basically any bias you add to the selection of people who are > at the table > will favor somebody or another, and the fact that the bias > exists can be used > to try to get a competitive advanage. Ah, so because there is no 'perfect' alternative that satisfies Keith there is no choice but to accept the current situation where the only people with any say are the IETF establishment. I prefer a partly flawed selection than the current situation where only the WG chair gets to make any decision according to whatever process he chooses and then the IESG and IAB refuse to intervene so long as the abuse takes place in accordance with the 'process'. Again, either you open up the IETF process so that everyone has a say in the outcome or we will find an alternative venue to agree standards. There is no divine right by which the IETF is the only arbiter of Internet protocols. If the IETF refuses to be open and accountable it is not going to be allowed to be part of the standards decision process. Phill From problem-statement-bounces@alvestrand.no Fri Jul 4 17:22:00 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08496 for ; Fri, 4 Jul 2003 17:21:59 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3503C6257B; Fri, 4 Jul 2003 23:21:29 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by eikenes.alvestrand.no (Postfix) with ESMTP id EFD0362205 for ; Fri, 4 Jul 2003 23:21:27 +0200 (CEST) Received: from mou1wnexc01.verisign.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.9/) with ESMTP id h64LLR2Q029812 for ; Fri, 4 Jul 2003 14:21:27 -0700 (PDT) Received: by mou1wnexc01.verisign.com with Internet Mail Service (5.5.2653.19) id ; Fri, 4 Jul 2003 14:21:27 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E0D22CB@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'problem-statement@alvestrand.no'" Date: Fri, 4 Jul 2003 14:21:26 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: The need for smaller protocol specifications X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no >Back in the early 90s, there was a concern that some vendors would not >implement Proposed Standards, but wait for Draft - that was when IETF >meeting attedance was under 500. Today is different as there seem to be >many RFCs remaining at Proposed (and everyone confuses product >differentation with protocol specifications) I don't think anyone outside the IETF understands the difference between proposed, draft and standard. For that matter I don't think anyone cares about the difference between an informational, experimental or standards track RFC. My experience on HTTP was that by the time the process got arround to draft the products were long out the door. DNSSEC has been in standards limbo for ten years, PKIX for the same length of time. CAT took much more than a decade. I don't know of any developer that is going to wait that length of time, whether commercial or independent. Most of the time in my experience code gets written to the internet drafts. It is not unusual for a major software vendor to effectively close debate on an issue by simply deploying software and letting it be known that they have no plans to change anything until the next major upgrade - typically a 3 year cycle. The 'Draft' stage in the standards process is unnecessary, confusing and should be eliminated immediately. This would immediately reduce the IESG work load by a third and have no detrimental effect. All RFCs currently at draft standard status would immediately progress to Standard. Phill From problem-statement-bounces@alvestrand.no Fri Jul 4 18:27:59 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10979 for ; Fri, 4 Jul 2003 18:27:58 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 074036259C; Sat, 5 Jul 2003 00:27:28 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from grebe.mail.pas.earthlink.net (grebe.mail.pas.earthlink.net [207.217.120.46]) by eikenes.alvestrand.no (Postfix) with ESMTP id A2C6A62205 for ; Sat, 5 Jul 2003 00:27:26 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by grebe.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19YZ1Y-0006wN-00; Fri, 04 Jul 2003 15:27:24 -0700 Date: Fri, 4 Jul 2003 18:23:30 -0400 From: Keith Moore To: "Hallam-Baker, Phillip" Message-Id: <20030704182330.2434aa3c.moore@cs.utk.edu> In-Reply-To: <2A1D4C86842EE14CA9BC80474919782E0D22CA@mou1wnexm02.verisign.com> References: <2A1D4C86842EE14CA9BC80474919782E0D22CA@mou1wnexm02.verisign.com> X-Mailer: Sylpheed version 0.9.1 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: pbaker@verisign.com Cc: moore@cs.utk.edu Cc: problem-statement@alvestrand.no Subject: Re: attempts to exclude people from WGs (was ADs who are also WG chairs) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit ] > basically any bias you add to the selection of people who are at the ] > table will favor somebody or another, and the fact that the bias exists ] > can be used to try to get a competitive advanage. ] ] Ah, so because there is no 'perfect' alternative that satisfies Keith there ] is no choice but to accept the current situation where the only people with ] any say are the IETF establishment. there is no IETF establishment, Phill. a randomly-selected group of people gets an opportunity to replace half of IESG and IAB with whomever they wish every year. to the extent these people continue to serve, it's because this random group feels that they're the best ones qualified to do the job that are available. not that this has anything to do with your attmepts to exclude valuable input from working groups, but it sure sounds good to blame the establishment, doesn't it? ] I prefer a partly flawed selection than the current situation where only the ] WG chair gets to make any decision according to whatever process he chooses ] and then the IESG and IAB refuse to intervene so long as the abuse takes ] place in accordance with the 'process'. so we've got a problem with the process by which WGs are run, or the process by which appeals are made, but you want to blame the management. never mind that changing the management won't help as long as the process is flawed. of course, it's always easier to demonize people or groups than to actually understand or solve difficult problems. ] Again, either you open up the IETF process so that everyone has a say in the ] outcome or we will find an alternative venue to agree standards. in the current scheme, everyone does have a say in the outcome. and yet we all acknowledge that the process has serious problems - that's why we're having this discussion. in a nutshell, the fact that everyone has a "say" in the outcome is insufficient to produce results that are technically sound and earn broad consensus. somehow I don't think that raising the bar to entry, as you are encouraging us to do, will improve things. it might create the appearance of consensus but it will make the IETF's output even less relevant than it is now. ] There is no divine right by which the IETF is the only arbiter of Internet ] protocols. If the IETF refuses to be open and accountable it is not going to ] be allowed to be part of the standards decision process. and there is no divine right by which you are the arbitrer of what is open and fair. but if you want to leave the IETF and cause trouble elsewhere, feel free. From problem-statement-bounces@alvestrand.no Fri Jul 4 18:35:28 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11151 for ; Fri, 4 Jul 2003 18:35:27 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C62A76257F; Sat, 5 Jul 2003 00:34:57 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by eikenes.alvestrand.no (Postfix) with ESMTP id 714E662205 for ; Sat, 5 Jul 2003 00:34:56 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by hawk.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19YZ8g-0002G9-00; Fri, 04 Jul 2003 15:34:46 -0700 Date: Fri, 4 Jul 2003 18:30:53 -0400 From: Keith Moore To: "Hallam-Baker, Phillip" Message-Id: <20030704183053.47feb6b1.moore@cs.utk.edu> In-Reply-To: <2A1D4C86842EE14CA9BC80474919782E0D22C8@mou1wnexm02.verisign.com> References: <2A1D4C86842EE14CA9BC80474919782E0D22C8@mou1wnexm02.verisign.com> X-Mailer: Sylpheed version 0.9.1 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Cc: moore@cs.utk.edu Subject: Re: MAJOR ISSUE: Causes of "problems" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit ] >Also, to gain consensus on a protocol it is no longer sufficient merely ] >to find a way to solve the technical problems of how to represent ] >the data and exchange the information. Vendors will now insist that the ] >protocol support or even mandate their business models - even when these ] >contradict each other or are not in the interests of users. ] ] Well it is hardly surprising that companies would insist that a ] protocol they are being asked to support actually support their ] business model. hardly surprising, no. reasonable, not in the least. IETF does not exist to allow companies to screw other companies. or for that matter, to screw users. From problem-statement-bounces@alvestrand.no Fri Jul 4 18:47:21 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11446 for ; Fri, 4 Jul 2003 18:47:20 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 68ABB6257F; Sat, 5 Jul 2003 00:46:51 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by eikenes.alvestrand.no (Postfix) with ESMTP id 138FE62205 for ; Sat, 5 Jul 2003 00:46:45 +0200 (CEST) Received: from mou1wnexc01.verisign.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.9/) with ESMTP id h64Mkh2Q013138; Fri, 4 Jul 2003 15:46:43 -0700 (PDT) Received: by mou1wnexc01.verisign.com with Internet Mail Service (5.5.2653.19) id ; Fri, 4 Jul 2003 15:46:43 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E0D22CC@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'Keith Moore'" , "Hallam-Baker, Phillip" Date: Fri, 4 Jul 2003 15:46:43 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Cc: problem-statement@alvestrand.no Subject: RE: MAJOR ISSUE: Causes of "problems" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no > ] Well it is hardly surprising that companies would insist that a > ] protocol they are being asked to support actually support their > ] business model. > > hardly surprising, no. reasonable, not in the least. > > IETF does not exist to allow companies to screw other > companies. or for that > matter, to screw users. Apparently you believe it exists to allow a group of self selected individuals to exercise their infantile political agendas in which anything a corporation does must be considered evil. What if the users vote for Internet Explorer? Or do their views only count to the extent they agree with you? If they disagree their opinions MUST be the result of some sort of false conciousness. Phill From problem-statement-bounces@alvestrand.no Fri Jul 4 18:59:11 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11765 for ; Fri, 4 Jul 2003 18:59:10 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0A67362205; Sat, 5 Jul 2003 00:58:42 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from snipe.mail.pas.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by eikenes.alvestrand.no (Postfix) with ESMTP id CFCF961C2B for ; Sat, 5 Jul 2003 00:58:40 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by snipe.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19YZVl-0002q5-00; Fri, 04 Jul 2003 15:58:37 -0700 Date: Fri, 4 Jul 2003 18:54:43 -0400 From: Keith Moore To: "Hallam-Baker, Phillip" Message-Id: <20030704185443.1894d3e6.moore@cs.utk.edu> In-Reply-To: <2A1D4C86842EE14CA9BC80474919782E0D22CC@mou1wnexm02.verisign.com> References: <2A1D4C86842EE14CA9BC80474919782E0D22CC@mou1wnexm02.verisign.com> X-Mailer: Sylpheed version 0.9.1 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: pbaker@verisign.com Cc: moore@cs.utk.edu Cc: problem-statement@alvestrand.no Subject: Re: MAJOR ISSUE: Causes of "problems" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit ] > IETF does not exist to allow companies to screw other ] > companies. or for that matter, to screw users. ] ] Apparently you believe it exists to allow a group of self selected ] individuals to exercise their infantile political agendas in which anything ] a corporation does must be considered evil. yawn. From problem-statement-bounces@alvestrand.no Fri Jul 4 19:06:05 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12034 for ; Fri, 4 Jul 2003 19:06:03 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 97EF26259E; Sat, 5 Jul 2003 01:05:31 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6E88961C2B; Sat, 5 Jul 2003 01:05:30 +0200 (CEST) Date: Sat, 05 Jul 2003 01:05:30 +0200 From: Harald Tveit Alvestrand To: "Hallam-Baker, Phillip" , "'problem-statement@alvestrand.no'" Message-ID: <436330000.1057359930@askvoll.hjemme.alvestrand.no> In-Reply-To: <2A1D4C86842EE14CA9BC80474919782E0D22CB@mou1wnexm02.verisign.com> References: <2A1D4C86842EE14CA9BC80474919782E0D22CB@mou1wnexm02.verisign.com > X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: The need for smaller protocol specifications X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit --On fredag, juli 04, 2003 14:21:26 -0700 "Hallam-Baker, Phillip" wrote: > The 'Draft' stage in the standards process is unnecessary, confusing and > should be eliminated immediately. This would immediately reduce the IESG > work load by a third and have no detrimental effect. All RFCs currently at > draft standard status would immediately progress to Standard. The part of the IESG workload caused by moving stuff to Draft is far less than one third. More like three percent - apart from the number of documents (low), most of the stuff going to Draft is "known quantity" - we know what it's supposed to do, and what it's being used for, so reading the doc is MUCH easier.... there are good reasons to remove Draft (I think), but load on the IESG by the current process is not one of them. Harald From problem-statement-bounces@alvestrand.no Fri Jul 4 19:25:26 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12281 for ; Fri, 4 Jul 2003 19:25:25 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 56FAF6259E; Sat, 5 Jul 2003 01:24:56 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by eikenes.alvestrand.no (Postfix) with ESMTP id EA5236259C for ; Sat, 5 Jul 2003 01:24:52 +0200 (CEST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h64NOoQr002319; Fri, 4 Jul 2003 16:24:50 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AJE39117; Fri, 4 Jul 2003 16:24:49 -0700 (PDT) Message-Id: <200307042324.AJE39117@mira-sjc5-c.cisco.com> To: "Hallam-Baker, Phillip" From: Melinda Shore In-Reply-To: Message from pbaker@verisign.com <2A1D4C86842EE14CA9BC80474919782E0D22CC@mou1wnexm02.verisign.com> Date: Fri, 04 Jul 2003 19:24:49 -0400 Cc: problem-statement@alvestrand.no Subject: Re: MAJOR ISSUE: Causes of "problems" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no > Apparently you believe it exists to allow a group of self selected > individuals to exercise their infantile political agendas in which anything > a corporation does must be considered evil. While this is fascinating, let's keep the discussion focused on the business at hand, which is progressing the two documents. Melinda From problem-statement-bounces@alvestrand.no Fri Jul 4 22:34:54 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15323 for ; Fri, 4 Jul 2003 22:34:53 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5A2866259C; Sat, 5 Jul 2003 04:34:22 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from apocalypse.org (apocalypse.org [192.48.232.17]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2D84B61A96; Sat, 5 Jul 2003 04:34:20 +0200 (CEST) Received: from apocalypse.org (apocalypse.org [192.48.232.17]) by apocalypse.org (8.12.8/8.12.8) with ESMTP id h652YEk1026121; Fri, 4 Jul 2003 22:34:15 -0400 Date: Sat, 5 Jul 2003 11:34:12 +0900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v552) To: Harald Tveit Alvestrand From: avri In-Reply-To: <427280000.1057337765@askvoll.hjemme.alvestrand.no> Message-Id: <29B9764C-AE91-11D7-87A9-000393CC2112@apocalypse.org> Content-Transfer-Encoding: quoted-printable X-Mailer: Apple Mail (2.552) Cc: "'problem-statement@alvestrand.no'" Subject: Re: Robert's Rules (Re: ADs who are also WG chairs) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: quoted-printable Some parts of this conversation would be just right for the Solutions list. I might even be able to contribute. a. ps. but you are indulged. :-) On l=F6rdag, jul 5, 2003, at 01:56 Asia/Seoul, Harald Tveit Alvestrand=20= wrote: > from the chairs....> > > --On fredag, juli 04, 2003 09:44:59 -0700 "Hallam-Baker, Phillip"=20 > wrote: > >> >>> serious question: >>> >>> do you have an example of a version of Robert's rules of >>> order that has >>> successfully been applied to mailing lists? >> >> This was the subject of some study by my group when I was at IETF. We=20= >> ran >> an Open Meeting over the Internet for Vice President Al Gore. >> >> That was a moderated forum using an adapted form of Recher's=20 >> dialectic, >> however the moderation was not essential in that case. > > do you have a reference? I'm not familiar with Recher's dialectic... > >>> RR has a number of concepts that are hard to apply to a >>> mailing list - >>> recognition of speakers by the chair, expulsion from the room >>> of disorderly >>> members, voting in real time on points of procedure, for >>> instance. I'd be >>> interested in hearing of examples of successful adaptations. >> >> Some of the rules are not appropriate because the constraints are=20 >> not. For >> example it is not necessary to require recognition by the chair since=20= >> it >> is possible for more than one person to speak at once. >> >> The key point is what to do with respect to decisions and what to do=20= >> with >> in person and conference call meeting time. >> >> What we do in OASIS in most cases is to run with an abreviated=20 >> version of >> the rules except when there is an actual controversy and someone=20 >> wants to >> make sure process is followed. > > that's been my impression with most places that claim to follow RR too=20= > - that unless there's a conflict, things jut run in an ad-hoc fashion,=20= > but that once there is conflict, one has the ruleset to fall back on=20= > to ensure orderly and clear decision-making. > > And I actually think that's an eminently sensible way to run meetings,=20= > and wish we knew how to make mailing lists do that. > > Harald > From problem-statement-bounces@alvestrand.no Fri Jul 4 22:37:16 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15362 for ; Fri, 4 Jul 2003 22:37:15 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2736D62205; Sat, 5 Jul 2003 04:36:45 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from falcon.mail.pas.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1C56961A96 for ; Sat, 5 Jul 2003 04:36:44 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by falcon.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19Ycun-0002D1-00; Fri, 04 Jul 2003 19:36:42 -0700 Date: Fri, 4 Jul 2003 22:32:47 -0400 From: Keith Moore To: Keith Moore Message-Id: <20030704223247.369dfd94.moore@cs.utk.edu> In-Reply-To: <20030704131128.176db2d1.moore@cs.utk.edu> References: <20030704131128.176db2d1.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.9.1 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Cc: moore@cs.utk.edu Cc: aboba@internaut.com Subject: Re: MAJOR ISSUE: Causes of "problems" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit One thing I left out (probably not the only one) IETF has become widely known and highly visible outside of the protocol developer community. Because of this, a greater number of people with widely varying interests now seek to influence the organization, for good or ill. And whether because they are envious of IETF's success, or disappointed at IETF's failures, or for some other reason, a greater number of people also attempt to interfere with IETF's operation. From problem-statement-bounces@alvestrand.no Fri Jul 4 22:44:01 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15467 for ; Fri, 4 Jul 2003 22:44:00 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id ABC416257F; Sat, 5 Jul 2003 04:43:30 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from apocalypse.org (apocalypse.org [192.48.232.17]) by eikenes.alvestrand.no (Postfix) with ESMTP id D279F62205 for ; Sat, 5 Jul 2003 04:43:28 +0200 (CEST) Received: from acm.org (apocalypse.org [192.48.232.17]) by apocalypse.org (8.12.8/8.12.8) with ESMTP id h652hHk1026452; Fri, 4 Jul 2003 22:43:24 -0400 Date: Sat, 5 Jul 2003 11:43:15 +0900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v552) To: "Hallam-Baker, Phillip" , "'Keith Moore'" From: Avri Doria In-Reply-To: <2A1D4C86842EE14CA9BC80474919782E0D22CA@mou1wnexm02.verisign.com> Message-Id: <6D23B8FB-AE92-11D7-87A9-000393CC2112@acm.org> Content-Transfer-Encoding: quoted-printable X-Mailer: Apple Mail (2.552) Cc: problem-statement@alvestrand.no Subject: Re: attempts to exclude people from WGs (was ADs who are also WG chairs) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: quoted-printable To bring this back to Problems and an attempt to make sure we have all of the problems documented, when the draft show up (it has been submitted) please go through it and then suggest language that needs=20= to be added or amended. Please lets not bicker. Thanks a. On l=F6rdag, jul 5, 2003, at 05:56 Asia/Seoul, Hallam-Baker, Phillip=20 wrote: >> basically any bias you add to the selection of people who are >> at the table >> will favor somebody or another, and the fact that the bias >> exists can be used >> to try to get a competitive advanage. > > Ah, so because there is no 'perfect' alternative that satisfies Keith=20= > there > is no choice but to accept the current situation where the only people=20= > with > any say are the IETF establishment. > > I prefer a partly flawed selection than the current situation where=20 > only the > WG chair gets to make any decision according to whatever process he=20 > chooses > and then the IESG and IAB refuse to intervene so long as the abuse=20 > takes > place in accordance with the 'process'. > > Again, either you open up the IETF process so that everyone has a say=20= > in the > outcome or we will find an alternative venue to agree standards. There=20= > is no > divine right by which the IETF is the only arbiter of Internet=20 > protocols. If > the IETF refuses to be open and accountable it is not going to be=20 > allowed to > be part of the standards decision process. > > > Phill > > From problem-statement-bounces@alvestrand.no Sat Jul 5 02:29:14 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00964 for ; Sat, 5 Jul 2003 02:29:14 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 77C176259E; Sat, 5 Jul 2003 08:28:43 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from sentosa.post1.com (sentosa.post1.com [202.27.17.100]) by eikenes.alvestrand.no (Postfix) with SMTP id 0594162574 for ; Sat, 5 Jul 2003 08:28:40 +0200 (CEST) Received: (qmail 20368 invoked from network); 5 Jul 2003 06:34:52 -0000 Received: from bb-203-125-7-219.singnet.com.sg (HELO pobox.org.sg) (203.125.7.219) by sentosa.post1.com with SMTP; 5 Jul 2003 06:34:52 -0000 Message-ID: <3F06702B.4060605@pobox.org.sg> Date: Sat, 05 Jul 2003 14:28:59 +0800 From: James Seng User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en, zh-cn, zh-tw, ja, ko MIME-Version: 1.0 To: "Hallam-Baker, Phillip" References: <2A1D4C86842EE14CA9BC80474919782E0D22C0@mou1wnexm02.verisign.com> In-Reply-To: <2A1D4C86842EE14CA9BC80474919782E0D22C0@mou1wnexm02.verisign.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "'problem-statement@alvestrand.no'" Subject: Re: ADs who are also WG chairs X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Hallam-Baker, Phillip wrote: >>1. OASIS is a paid-membership group. Some would considered >>that the fact >>it is paid-membership makes is exclusive (altho not exactly closed). > > This is irrelevant, that aspect of OASIS is not essential to the points I > raised. It is relevant. A paid-membership vs a no-membership fees is one of the key differences between IETF & OASIS. > Also the right to vote as an OASIS member is not the same as the right to > vote in a TC. An individual member of OASIS pays a reduced subscription and > does not get a vote in OASIS governance issues, mention in press releases > etc. However an individual member or even a non-member contributor has the > same voting rights in a TC. To be a OASIS "TC voting member", you need to be an "eligable member" and participate in TC activites for at least 3 times. Therefore, this set the prerequiste that you need to pay some form of memberships to OASIS in order to participate in OASIS TC. >>2. IETF dont have "members", or at least similar to OASIS. > > There are plenty of proxies for membership that can be effected. 'proxies' for which group? IETF dont have the concept of proxies and OASIS TC voting dont allow proxies. So I am not sure how my comment and your response fit together. > I see no conflict between membership being free and having voting. The only > reason there is a charge to join OASIS is the need to pay the administrative > costs. The IETF has found an alternative solution. > > I fail to see the relevance of ICANN processes here. Obviously you have not watch the ICANN experiment with free membership + voting process in GA...Take a look back at GA@ICANN history. Most organisation I deal with either have restricted membership but have voting or free & open membership but no formal voting. I have yet to see a successful organisation which is both free & open and have voting. If you have a reference to an organisation that actually works this way, I would love to study it. > The choice is between taking action to make the IETF internal processes open > democratic and accountable allowing the IETF to continue to direct Internet > standards development as a voluntary body or attempting to continue with the > status quo where control inside the IETF is vested in a small unaccountable > clique and vendors increasingly abandon IETF process for more open forums. > > Attempting to maintain the status quo will result in the exact situation you > are trying to prevent. The word "open & democratic" keep popping up in your mail whereas IETF core principle is "running code & rough consensus". This is not to say we are trying to maintain status quo...otherwise, we wont be doing this excerise. But changing the organisation does not mean we change our core principle. I prefer to stick with our "running code & rough consensus" principle, then see how we can build an open, bottom-up organisation that lives by that principle. So while I agree that a formal voting process might helps to bring "open & democratic" organisation, I am not sure how it fits into our "running code & rough consensus" principle. -James Seng From problem-statement-bounces@alvestrand.no Sat Jul 5 08:50:43 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06459 for ; Sat, 5 Jul 2003 08:50:43 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A06306230F; Sat, 5 Jul 2003 14:50:12 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by eikenes.alvestrand.no (Postfix) with ESMTP id 783D26225B for ; Sat, 5 Jul 2003 14:50:06 +0200 (CEST) Received: from MOU1WNEXC03.verisign.com (verisign.com [65.205.251.57]) by peacock.verisign.com (8.12.9/) with ESMTP id h65Co4ch007079 for ; Sat, 5 Jul 2003 05:50:04 -0700 (PDT) Received: by mou1wnexc03.verisign.com with Internet Mail Service (5.5.2653.19) id ; Sat, 5 Jul 2003 05:50:04 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E0D22CF@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'problem-statement@alvestrand.no'" Date: Sat, 5 Jul 2003 05:50:03 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: ADs who are also WG chairs X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no >It is relevant. A paid-membership vs a no-membership fees is one of the >key differences between IETF & OASIS. Nobody is suggesting a paid membership fee for the IETF. Therefore the point IS irrelevant. You are continuing to attack a straw man here. It is like attacking the IETF because the IETF meetings have a singificant fee. >To be a OASIS "TC voting member", you need to be an "eligable member" >and participate in TC activites for at least 3 times. Therefore, this >set the prerequiste that you need to pay some form of memberships to >OASIS in order to participate in OASIS TC. Not at all, there are plenty of individuals participating who do not pay to participate. But I mention the point only because you might discourage people from participating in OASIS groups with your misinformed statements. This aspect of OASIS is not particularly satisfactory, however it is not alone in having to pay for its secretariat. OASIS is a heck of a lot more economical in this regard than IETF. ISOC tells us it costs $800,000 a year to run the RFC editor. That strikes me as a ridiculous sum for a task that should be largely automated. Phill From problem-statement-bounces@alvestrand.no Sat Jul 5 09:30:51 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07333 for ; Sat, 5 Jul 2003 09:30:51 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 642796230F; Sat, 5 Jul 2003 15:30:21 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1BCAF6225B for ; Sat, 5 Jul 2003 15:30:19 +0200 (CEST) Received: from mou1wnexc01.verisign.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.9/) with ESMTP id h65DUH2Q000124 for ; Sat, 5 Jul 2003 06:30:17 -0700 (PDT) Received: by mou1wnexc01.verisign.com with Internet Mail Service (5.5.2653.19) id ; Sat, 5 Jul 2003 06:30:17 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E0D22D0@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'problem-statement@alvestrand.no'" Date: Sat, 5 Jul 2003 06:30:16 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: Comments on problem statement X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no 1.1 These failures are just those that afflict many small organizations trying to make the transition from a small organization which can be run informally and where essentially all participants fully share the aims, values and motivations of the leadership, That is NOT the issue, the problem has nothing to do with shared values, this statement contains exactly the type of arrogant assumption that has poisoned relationships between the establishment and the proletariat. When there is a problem with the proletariat refusing to be led blindly the establishment complain sniffily about 'lack of shared values' - thus putting themselves up on a pedestal. Can't you folk see how insulting this attitude is? The PROBLEM is a well known one that there is a functional limit of about 150 people for informally organized groups. It is a basic limitation of the human brain, it simply does not have enough RAM to maintain knowledge of relationships amongst bigger groups. 2.2 This section should address the fact that IETF documents are poorly formatted in a fixed width font making them VERY hard to read. They look like a second rate piece of work and many engineers will avoid IETF process for that reason alone. This is yet another example of the establishment having its own way without listening to the membership. Suggest change and you get Dilbert's PHB wet blanket proceedure. Also the section should address the fact that many of the engineering criteria that the IETF thinks it is applying don't actually exist. Case in point is the ubiquitous reference to 'end-to-end' security. This is actually a conflation of several pieces of work. Search for an actual definition of what the doctrine means and you will not find a single coherent statement. The end-to-end paper itself barely mentions security. If you read the RFC describing the IAB security workshop which is the nearest thing to a coherent IETF statement on security you will find it bears little relation to the received wisdom that is often rammed down the throats of WGs by people who in most cases are NOT security specialists. 2.6 The IETF Management Structure is not Matched to the Current Size and Complexity of the IETF IT could well be that the ROLE of the IETF management structure is not matched to the current size and scope. The management structure is considerably larger than OASIS which at this point is managing an equivalent number of active specifications. If the management does less the problem is reduced. To do less the management have to relinquish control over the process outcome. I fail to see the fearful penalties that the IESG believe will attend a faulty spec. In my experience completely broken specs don't make it to production. There is plenty of brokeness that went into the Web but that almost always happened as a result of someone deliberately circumventing the process completely. From problem-statement-bounces@alvestrand.no Sat Jul 5 10:53:28 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09774 for ; Sat, 5 Jul 2003 10:53:27 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 845F9625A7; Sat, 5 Jul 2003 16:52:14 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by eikenes.alvestrand.no (Postfix) with ESMTP id 451576230F for ; Sat, 5 Jul 2003 16:52:12 +0200 (CEST) Received: from employees.org (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 05 Jul 2003 07:54:09 -0700 Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h65Eq97F029372 for ; Sat, 5 Jul 2003 07:52:09 -0700 (PDT) Received: from cisco.com (sjc-vpn3-85.cisco.com [10.21.64.85]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with SMTP id AHS86507; Sat, 5 Jul 2003 07:43:24 -0700 (PDT) Received: by cisco.com (sSMTP sendmail emulation); Sat, 5 Jul 2003 10:51:52 -0400 Date: Sat, 5 Jul 2003 10:51:52 -0400 From: Scott W Brim To: "'problem-statement@alvestrand.no'" Message-ID: <20030705105151.B1840@sbrim-w2k01> Mail-Followup-To: Scott W Brim , "'problem-statement@alvestrand.no'" References: <2A1D4C86842EE14CA9BC80474919782E0D22D0@mou1wnexm02.verisign.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <2A1D4C86842EE14CA9BC80474919782E0D22D0@mou1wnexm02.verisign.com>; from pbaker@verisign.com on Sat, Jul 05, 2003 at 06:30:16AM -0700 Subject: Re: Comments on problem statement X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no On Sat, Jul 05, 2003 06:30:16AM -0700, Hallam-Baker, Phillip allegedly wrote: > 1.1 > > These failures are just those that afflict many small organizations > trying to make the transition from a small organization which can be > run informally and where essentially all participants fully share the > aims, values and motivations of the leadership, > > That is NOT the issue, the problem has nothing to do with shared values, > this statement contains exactly the type of arrogant assumption that has > poisoned relationships between the establishment and the proletariat. > > When there is a problem with the proletariat refusing to be led blindly the > establishment complain sniffily about 'lack of shared values' - thus putting > themselves up on a pedestal. > > Can't you folk see how insulting this attitude is? http://www.shirky.com/writings/group_enemy.html From problem-statement-bounces@alvestrand.no Sat Jul 5 13:09:26 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11472 for ; Sat, 5 Jul 2003 13:09:25 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A17F4625A7; Sat, 5 Jul 2003 19:08:56 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by eikenes.alvestrand.no (Postfix) with ESMTP id 30F61625A7 for ; Sat, 5 Jul 2003 19:08:54 +0200 (CEST) Received: from BBFUJIP.brandenburg.com (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h65HCMF10010; Sat, 5 Jul 2003 10:12:23 -0700 Date: Fri, 4 Jul 2003 19:31:50 +0200 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/11) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <33367111668.20030704193150@brandenburg.com> To: avri In-Reply-To: <123A6F9F-AA9C-11D7-A025-000393CC2112@apocalypse.org> References: <045201c33ea6$bfd052a0$0200a8c0@DFNJGL21> <123A6F9F-AA9C-11D7-A025-000393CC2112@apocalypse.org> MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: appeal mechanisms was Re: Ombuds-process X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Dave Crocker List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit avri, a> i think looking at the counter-examples will show that the folks a> brave enough and process savvy enough to file these appeals a> where not our average participants. a> yes, there is a process but it takes a lot of energy and savvy to a> use that process. We always need to be careful that the system is not design (or administered) in a way that prevents legitimate voicing of "contrary" views, including those that go into an appeal. On the other hand, I tend to believe that it is a Very Good Thing to have meaningful barriers, for expensive processes. A working group should not be formed just because someone likes the idea. It needs the barrier of demonstrating community support for using the output. Similarly, appeals need a reasonable barrier to avoid frivolities. Frankly, the more these process discussions go on, the more it looks as if our biggest problem is with people not having read the documents that exist. For example: the appeals process is documented. What is it that makes the barrier to appeals too high? Your note seeks to move from a generic complaint to something specific about which action can be taken. I laud that, and merely suggest taking it further. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Sun Jul 6 00:08:19 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23977 for ; Sun, 6 Jul 2003 00:08:18 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 11423622AF; Sun, 6 Jul 2003 06:07:50 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from sentosa.post1.com (sentosa.post1.com [202.27.17.100]) by eikenes.alvestrand.no (Postfix) with SMTP id C76E661A96 for ; Sun, 6 Jul 2003 06:07:46 +0200 (CEST) Received: (qmail 28021 invoked from network); 6 Jul 2003 04:13:52 -0000 Received: from bb-203-125-7-219.singnet.com.sg (HELO pobox.org.sg) (203.125.7.219) by sentosa.post1.com with SMTP; 6 Jul 2003 04:13:52 -0000 Message-ID: <3F07A0A5.1030806@pobox.org.sg> Date: Sun, 06 Jul 2003 12:08:05 +0800 From: James Seng User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en, zh-cn, zh-tw, ja, ko MIME-Version: 1.0 To: "Hallam-Baker, Phillip" References: <2A1D4C86842EE14CA9BC80474919782E0D22CF@mou1wnexm02.verisign.com> In-Reply-To: <2A1D4C86842EE14CA9BC80474919782E0D22CF@mou1wnexm02.verisign.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "'problem-statement@alvestrand.no'" Subject: Re: ADs who are also WG chairs X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Hallam-Baker, Phillip wrote: >>It is relevant. A paid-membership vs a no-membership fees is one of the >>key differences between IETF & OASIS. > > Nobody is suggesting a paid membership fee for the IETF. Therefore the > point IS irrelevant. > > You are continuing to attack a straw man here. It is like attacking > the IETF because the IETF meetings have a singificant fee. Read my email again, please. I did not say you are suggesting a paid membership fee for IETF. Neither do I think there is anything wrong with paid membership. (I am involved in many other paid membership standard organisation too, some of them even more exclusive) I am saying that the paid-membership makes OASIS very different from IETF, fundamentally. So you cannot say "Oh, this and this works in OASIS" and assume it also works for IETF. >>To be a OASIS "TC voting member", you need to be an "eligable member" >>and participate in TC activites for at least 3 times. Therefore, this >>set the prerequiste that you need to pay some form of memberships to >>OASIS in order to participate in OASIS TC. > > Not at all, there are plenty of individuals participating who do not > pay to participate. But I mention the point only because you might > discourage people from participating in OASIS groups with your > misinformed statements. According to the OASIS TC process you need to be "Eligible Person" to become a TC member. The definition of "Eligible Person" is "one of a class of individuals that includes persons holding individual memberships in the corporation, employees of organizational members of the corporation, members of organization to which OASIS has extended the benefits of joint membership, and such other persons as may be designated by the board of directors". So I am not sure how there are "plenty of individuals participating who do not pay"...I could be wrong in reality but going by the rules, that is how it is. > This aspect of OASIS is not particularly satisfactory, however it is > not alone in having to pay for its secretariat. OASIS is a heck of a > lot more economical in this regard than IETF. ISOC tells us it costs > $800,000 a year to run the RFC editor. That strikes me as a ridiculous > sum for a task that should be largely automated. Ah, one thing we do agree. It is hell lots of money to spend and we shouldn't. (Altho I am not sure if it can be automated...) -James Seng From problem-statement-bounces@alvestrand.no Sun Jul 6 09:00:32 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12349 for ; Sun, 6 Jul 2003 09:00:31 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0EC936259D; Sun, 6 Jul 2003 15:00:01 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0B3F462591 for ; Sun, 6 Jul 2003 14:59:55 +0200 (CEST) Received: from mou1wnexc01.verisign.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.9/) with ESMTP id h66Cxq2Q003489; Sun, 6 Jul 2003 05:59:53 -0700 (PDT) Received: by mou1wnexc01.verisign.com with Internet Mail Service (5.5.2653.19) id ; Sun, 6 Jul 2003 05:59:52 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E0D22D6@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'James Seng'" , "Hallam-Baker, Phillip" Date: Sun, 6 Jul 2003 05:59:51 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Cc: "'problem-statement@alvestrand.no'" Subject: RE: ADs who are also WG chairs X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no > I am saying that the paid-membership makes OASIS very different from > IETF, fundamentally. So you cannot say "Oh, this and this works in > OASIS" and assume it also works for IETF. I am saying the charge is utterly irrelevant to the argument. It is simply a convenient excuse not to consider the unpleasant ugly little fact that the very system that you are claiming is impossible is working fine in OASIS. I am certainly NOT 'assuming' that democracy would work for the IETF, I am demonstrating that it works in a body that does very similar work and further that the cosmetic differences between the organizations do not affect the workability of democracy. That is not 'assuming', it is a reasoned argument. You on the other hand are asserting that democracy cannot work in the IETF on the basis of no proof whatsoever. If you do not want ALL Internet standards developed in that forum reform the IETF so that it is genuinely open, democratic and accountable. Phill From problem-statement-bounces@alvestrand.no Sun Jul 6 09:37:38 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12919 for ; Sun, 6 Jul 2003 09:37:37 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2DF3162591; Sun, 6 Jul 2003 15:37:08 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from sentosa.post1.com (sentosa.post1.com [202.27.17.100]) by eikenes.alvestrand.no (Postfix) with SMTP id 5509462582 for ; Sun, 6 Jul 2003 15:37:05 +0200 (CEST) Received: (qmail 34187 invoked from network); 6 Jul 2003 13:43:10 -0000 Received: from bb-203-125-7-219.singnet.com.sg (HELO pobox.org.sg) (203.125.7.219) by sentosa.post1.com with SMTP; 6 Jul 2003 13:43:10 -0000 Message-ID: <3F082615.2070807@pobox.org.sg> Date: Sun, 06 Jul 2003 21:37:25 +0800 From: James Seng User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en, zh-cn, zh-tw, ja, ko MIME-Version: 1.0 To: "Hallam-Baker, Phillip" References: <2A1D4C86842EE14CA9BC80474919782E0D22D6@mou1wnexm02.verisign.com> In-Reply-To: <2A1D4C86842EE14CA9BC80474919782E0D22D6@mou1wnexm02.verisign.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "'problem-statement@alvestrand.no'" Subject: Re: ADs who are also WG chairs X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Hallam-Baker, Phillip wrote: > I am saying the charge is utterly irrelevant to the argument. It is > simply a convenient excuse not to consider the unpleasant ugly little > fact that the very system that you are claiming is impossible is > working fine in OASIS. It is absolutely relevant. If you can find an organisation which is not restrictive in its membership AND at the same time deal with consensus using voting mechanism, then let us know. > I am certainly NOT 'assuming' that democracy would work for the IETF, > I am demonstrating that it works in a body that does very similar > work and further that the cosmetic differences between the > organizations do not affect the workability of democracy. That > is not 'assuming', it is a reasoned argument. You on the other hand > are asserting that democracy cannot work in the IETF on the basis of > no proof whatsoever. Yes, OASIS works within its context. But it is comparing apple & orange. One is a paid-membership model and the other isn't. Proof me wrong. Name me one organisation I asked for as above. > If you do not want ALL Internet standards developed in that forum > reform the IETF so that it is genuinely open, democratic and > accountable. Once again, 'democratic' is not one of our core principle, AFAIK. Running code & rough consensus is the IETF core principle. Or are you proposing we change this too? -James Seng From problem-statement-bounces@alvestrand.no Sun Jul 6 09:47:42 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13019 for ; Sun, 6 Jul 2003 09:47:42 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id ECB906259D; Sun, 6 Jul 2003 15:47:12 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4DE9A62591 for ; Sun, 6 Jul 2003 15:47:11 +0200 (CEST) Received: from mou1wnexc02.verisign.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.9/) with ESMTP id h66Dl9ch004655; Sun, 6 Jul 2003 06:47:09 -0700 (PDT) Received: by mou1wnexc02.verisign.com with Internet Mail Service (5.5.2653.19) id ; Sun, 6 Jul 2003 06:47:09 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E0D22D8@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'James Seng'" , "Hallam-Baker, Phillip" Date: Sun, 6 Jul 2003 06:47:07 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Cc: "'problem-statement@alvestrand.no'" Subject: RE: ADs who are also WG chairs X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no > Once again, 'democratic' is not one of our core principle, AFAIK. > Running code & rough consensus is the IETF core principle. No, the core principle is top down organization, control by the few. Consensus or running code did not enter into the DNSEXT OPTIN process. If the IESG has any value it will refuse the DNSSEC specs as broken of its own accord. Instead however it will be too timid to challenge Randy. What "consensus" means is people are too frightened to rock the boat lest their behavior cause someone who is obstructionist and determined to get their own way start blocking your projects in retaliation. Phill From problem-statement-bounces@alvestrand.no Sun Jul 6 10:06:59 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13653 for ; Sun, 6 Jul 2003 10:06:58 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9925562591; Sun, 6 Jul 2003 16:06:29 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by eikenes.alvestrand.no (Postfix) with ESMTP id BDF6462582 for ; Sun, 6 Jul 2003 16:06:27 +0200 (CEST) Received: from cisco.com (171.68.223.137) by sj-iport-2.cisco.com with ESMTP; 06 Jul 2003 07:03:47 -0700 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h66E6OpZ026531; Sun, 6 Jul 2003 07:06:24 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AJE92615; Sun, 6 Jul 2003 07:06:22 -0700 (PDT) Message-Id: <200307061406.AJE92615@mira-sjc5-c.cisco.com> To: James Seng From: Melinda Shore In-Reply-To: Message from jseng@pobox.org.sg of "Sun, 06 Jul 2003 21:37:25 +0800." <3F082615.2070807@pobox.org.sg> Date: Sun, 06 Jul 2003 10:06:22 -0400 Cc: "'problem-statement@alvestrand.no'" Cc: "Hallam-Baker, Phillip" Subject: Re: ADs who are also WG chairs X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no > It is absolutely relevant. If you can find an organisation which is not > restrictive in its membership AND at the same time deal with consensus > using voting mechanism, then let us know. This discussion has parked itself in solution space and should be moved to the solutions mailing list (http://eikenes.alvestrand.no/mailman/listinfo/solutions) or, at least, not continue here. Our task is to identify and sort through problems without presuming solutions. Melinda From problem-statement-bounces@alvestrand.no Sun Jul 6 12:40:40 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16964 for ; Sun, 6 Jul 2003 12:40:39 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D04C66230D; Sun, 6 Jul 2003 18:40:10 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [194.196.100.235]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0D2C561A96 for ; Sun, 6 Jul 2003 18:40:09 +0200 (CEST) Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196])h66Ge5PO051120; Sun, 6 Jul 2003 18:40:05 +0200 Received: from ochsehorn.zurich.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228])h66Ge4iG262202; Sun, 6 Jul 2003 18:40:04 +0200 Received: from gsine08.us.sine.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA18610 from ; Sun, 6 Jul 2003 18:40:00 +0200 Message-Id: <3F084029.16753D46@hursley.ibm.com> Date: Sun, 06 Jul 2003 17:28:41 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: "Hallam-Baker, Phillip" References: <2A1D4C86842EE14CA9BC80474919782E0D22D0@mou1wnexm02.verisign.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "'problem-statement@alvestrand.no'" Subject: Fixed font v multiple fonts X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit "Hallam-Baker, Phillip" wrote: ... > 2.2 > > This section should address the fact that IETF documents are poorly > formatted in a fixed width font making them VERY hard to read. They look > like a second rate piece of work and many engineers will avoid IETF process > for that reason alone. Well, I'm currently working both in the IETF (one fixed width font) and in the GGF (as many variable fonts as you want). I find IETF documents substantially easier to deal with. They are much smaller, which is an immense advantage when you are on the road or on a lousy hotel wireless network. They are much easier to discuss on mailing lists by trivial cut and paste. Even the diagrams can easily be cut, pasted, and updated. Against this is is the lack of italics or shading to distinguish symbols and examples from text; that is certainly an advantage in GGF documents. There may be some arguments for having the final product look pretty, by use of multiple fonts and artistic diagrams. But in my experience, using these techniques in documents under development is a problem in itself. Brian From problem-statement-bounces@alvestrand.no Sun Jul 6 12:40:54 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16984 for ; Sun, 6 Jul 2003 12:40:53 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5B7426259D; Sun, 6 Jul 2003 18:40:15 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [194.196.100.234]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3D91A62591 for ; Sun, 6 Jul 2003 18:40:13 +0200 (CEST) Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196])h66GeC76092236; Sun, 6 Jul 2003 18:40:12 +0200 Received: from ochsehorn.zurich.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228])h66GeBiG262206; Sun, 6 Jul 2003 18:40:11 +0200 Received: from gsine08.us.sine.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA18628 from ; Sun, 6 Jul 2003 18:40:07 +0200 Message-Id: <3F084600.1CAA205F@hursley.ibm.com> Date: Sun, 06 Jul 2003 17:53:36 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: "Hallam-Baker, Phillip" References: <2A1D4C86842EE14CA9BC80474919782E0D22BF@mou1wnexm02.verisign.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "'problem-statement@alvestrand.no'" Subject: Re: ADs who are also WG chairs X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit "Hallam-Baker, Phillip" wrote: > > > What's to stop Big Bad Company stuffing an Oasis WG with ringers? > > What is to stop them doing that in an IETF WG? Since everyone is > theoretically participating as an individual I can't see how the WG Chair > could claim consensus if big bad company wanted to block something. This is the point about IETF consensus that you truly don't seem to get. The chair, or the IESG, when judging consensus, is entitled to decide that the 100 hands waving are equal to only one, because of the knowledge that Big Bad Company has sent 100 people to the meeting or mailing list. You may not like the fact that we give this power to the chairs and the IESG, but that *is* the IETF's answer to this question. > Oh yes, sorry I remember the WG chair can claim consensus because at the end > of the day it is only his opinion that matters. See DNSEXT for details. We shouldn't argue from one case where you happen to disagree with the chair and have chosen not to appeal. We have ~100 WGs and I don't hear 100 claims of this kind, or even ten a year. (That doesn't mean your complaint is invalid, or valid, but we have no evidence that it's typical.) > > What's to stop a commercial grouping pushing something through > > an Oasis WG that is good for them and harmful to the Internet? > > Same as when the IETF proposes something that would be harmful, the > community of users rejects a protocol that it does not want. There is no connection between my question and your answer, and no link between the first and second halves of your answer. The equivalent question is "What's to stop a commercial grouping pushing something through an IETF WG that is good for them and harmful to the Internet?" The answer is supposed to be "checks and balances applied by careful WG chartering, Last Call and IESG review." This could of course be failing - that's a legitimate topic for this list - but what I was asking is how does Oasis deal with this risk? The market is of course always able to reject something it doesn't want. That is orthogonal to something that is harmful. Users don't understand what is harmful to the commons, they understand what is good for them. > But it is a good question since there are far more companies with market > power who are now participating in OASIS than are currently fully engaged in > IETF process. So if there is a risk that 'evil' protocols come from OASIS > and 'corrupt' the Internet then that is going to be happening regardless of > what the opinion is here. That may be true. And if it's true, let's consider that it may be so *because* the IETF has been successful at deflecting 'evil' work. But actually, I suspect that Oasis is mainly working on topics that IETF would consider out of scope (and that W3C might have expected to handle). > > How can Roberts' Rules be applied on a mailing list? > > Roberts rules are not directly applicable to a mailing list since > it is asynchronous conversation. They are applicable to conference > calls and in person meetings. > > Even so we have had many successful polls through mailing lists, > in many cases using Quaker polls and other consensus finding > processes rather than the more divisive up or down questions we > see in IETF process. The biggest problem is that RR allow the chair to drive to a decision on exactly one question at a time, or to push that question on the stack until a subsidiary question has been resolved. Serialising debate in that style is essentially impossible on a mailing list. > > > (I'm not trying to make debating points - I really am concerned > > that these are serious weaknesses in the model you describe. And I > > spent two years chairing a Board that supposedly followed Roberts' > > Rules and used email extensively, and I can't answer the third > > question.) > > And your evidence for thinking that the IETF approach is working at any > level would be what? Finding out what isn't working in the IETF is exactly what this WG exists for. Brian From problem-statement-bounces@alvestrand.no Sun Jul 6 12:41:35 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17022 for ; Sun, 6 Jul 2003 12:41:34 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2ACB76230D; Sun, 6 Jul 2003 18:41:07 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by eikenes.alvestrand.no (Postfix) with ESMTP id C333A61A96; Sun, 6 Jul 2003 18:41:04 +0200 (CEST) Received: from BBFUJIP.brandenburg.com (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h66GicF27316; Sun, 6 Jul 2003 09:44:38 -0700 Date: Sun, 6 Jul 2003 08:59:55 +0200 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/11) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1101423707.20030706085955@brandenburg.com> To: Harald Tveit Alvestrand In-Reply-To: <148310000.1055147276@askvoll.hjemme.alvestrand.no> References: <120210000.1055072340@askvoll.hjemme.alvestrand.no> <481518433.20030608091336@brandenburg.com> <125670000.1055090084@askvoll.hjemme.alvestrand.no> <721113479.20030608173246@brandenburg.com> <148310000.1055147276@askvoll.hjemme.alvestrand.no> MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: ISSUE: Determinants for timeliness missing in section 2.1 X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Dave Crocker List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Harald, >> On the contrary, I believe there were plenty of people in both >> situations that had a very clear vision of what they wanted to achieve. >> The real problem is that they were prevented from pursuing those >> visions, due to requirements to satisfy additional constraints and/or to >> coordinate with competing efforts. HTA> I don't think those two descriptions contradict each other.... HTA> as I frequently say when asking for charters to be more clear: I was referring to situations in which there is a constituency that is clear about what it thinks needs to be done and says so clearly. I was referring to situations where such a constituency is prevented from making progress, either 1. because they are forced to "negotiate" or "compromise" with a different group that has a different -- and usually equally clear sense of needs and tasks -- at the level of paradigm differences, or 2. because they are saddled with a potentially large and potentially varying set of additional requirements, by folks who are not doing the work. All of this is well-intentioned, but that is irrelevant. (I mention this, in order to to exclude conspiracy explanations.) And all of this has nothing at all to do with basic engineering flaws that mean the result of their efforts will fundamentally not work. (Path #2, above, is often claimed to be in the interest of ensuring that the result will work, but folks are directed to Charlie Perkins' thread, of 9 June, on that score.) By way of providing a concrete example, I'll note the problem with imposing delays on XMPP while the highly problematic IMPP stuff gets worked out. XMPP is derived from an extremely successful, working system, with a significant installed base. The technical work has been done diligently and in a timely fashion. There is even documentation that the work satisfies the published IETF "requirements" for an IM&P service. Best of all, there is a clear constituency for using the working group's output. Yet it appears that that work will not be issued in a timely fashion, because there are problems elsewhere, outside of the working group. Concerns about Internet-scale "coordination" of multiple IM efforts are, at best, misguided, at this point. HTA> When we have the case of "plenty of people .... that had a very clear HTA> vision of what they wanted to achieve", and have "requirements to satisfy HTA> additional constraints", the people imposing additional constraints are HTA> people too, and part of the community. What's more, in the cases where HTA> those "imposing" people are chosen as leaders of the community, they HTA> believe that they represent other members of the community - and may even HTA> be right. This was an extremely helpful posting. I think it honestly and accurately highlights two points of disparity. One is that the folks imposing those additional requirements are not the folks doing the work to satisfy them. Consult one of Randy's learned texts on management about the effect of a pattern of such impositions on productivity and morale. A pattern of imposing, like this, needs to be balanced by an accompanying pattern of being perceived to help achieve timely and productive results. The other point of disparity is that this is a community that supposedly has its ultimate authority in the community, not in its "leaders". Leaders in this community are supposed to be facilitators at pursuing community rough consensus, rather than folks who "impose" requirements. However the IETF construct of community rough consensus is explicitly designed to ensure that no one person (or tiny minority) holds a veto. And if it sounds like my last sentence is the same as your last sentence, yes, that is interesting. The difference in views is who has vetoes and who is accountable. (And if anyone wants to suggest that nomcom is our way of achieving accountability, please don't, and for quite a few different reasons.) d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Sun Jul 6 12:47:58 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17121 for ; Sun, 6 Jul 2003 12:47:57 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id EF093621B8; Sun, 6 Jul 2003 18:47:28 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3F00161A96 for ; Sun, 6 Jul 2003 18:47:26 +0200 (CEST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h66GlMpp013500; Sun, 6 Jul 2003 09:47:23 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AJE96603; Sun, 6 Jul 2003 09:47:21 -0700 (PDT) Message-Id: <200307061647.AJE96603@mira-sjc5-c.cisco.com> To: Brian E Carpenter From: Melinda Shore In-Reply-To: Message from brian@hursley.ibm.com of "Sun, 06 Jul 2003 17:28:41 +0200." <3F084029.16753D46@hursley.ibm.com> Date: Sun, 06 Jul 2003 12:47:21 -0400 Cc: "'problem-statement@alvestrand.no'" Cc: "Hallam-Baker, Phillip" Subject: Re: Fixed font v multiple fonts X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no > Well, I'm currently working both in the IETF (one fixed width font) and > in the GGF (as many variable fonts as you want). I find IETF documents > substantially easier to deal with. They are much smaller, which is an > immense advantage when you are on the road or on a lousy hotel wireless > network. They are much easier to discuss on mailing lists by trivial cut > and paste. Even the diagrams can easily be cut, pasted, and updated. This line of discussion has, as we've seen repeatedly, extraordinarily high likelihood of becoming very unproductive very quickly. If there's a real problem here aside from differences in personal preference, let's put some text to it and move on, otherwise let's just move on. Melinda From problem-statement-bounces@alvestrand.no Sun Jul 6 13:09:16 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17360 for ; Sun, 6 Jul 2003 13:09:15 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 87E6362206; Sun, 6 Jul 2003 19:08:47 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by eikenes.alvestrand.no (Postfix) with ESMTP id C8201621B8 for ; Sun, 6 Jul 2003 19:08:45 +0200 (CEST) Received: from mou1wnexc01.verisign.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.9/) with ESMTP id h66H8i2Q000285; Sun, 6 Jul 2003 10:08:44 -0700 (PDT) Received: by mou1wnexc01.verisign.com with Internet Mail Service (5.5.2653.19) id ; Sun, 6 Jul 2003 10:08:44 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E0D22DA@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'Brian E Carpenter'" , "Hallam-Baker, Phillip" Date: Sun, 6 Jul 2003 10:08:43 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Cc: "'problem-statement@alvestrand.no'" Subject: RE: ADs who are also WG chairs X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no > This is the point about IETF consensus that you truly don't seem > to get. On the contrary Brian. I DO GET IT, honestly I do. Ascribing disagreement to ignorance is PRECISELY the type of arrogant behavior that people are complaining about >The chair, or the IESG, when judging consensus, is entitled > to decide that the 100 hands waving are equal to only one, because > of the knowledge that Big Bad Company has sent 100 people to the > meeting or mailing list. You may not like the fact that we give > this power to the chairs and the IESG, but that *is* the IETF's > answer to this question. So you admit that the process is completely arbitrary? Just replace '100 hands for big company' with '100 hands for something we the establishment don't like.' This is the excuse for control by cliques through the ages. > > Oh yes, sorry I remember the WG chair can claim consensus > because at the end > > of the day it is only his opinion that matters. See DNSEXT > for details. > > We shouldn't argue from one case where you happen to disagree with the > chair and have chosen not to appeal. We have ~100 WGs and I don't hear > 100 claims of this kind, or even ten a year. (That doesn't mean your > complaint is invalid, or valid, but we have no evidence that it's > typical.) Oh no, lets not let facts enter into the discussion, particularly when discussing facts results in interesting admissions such as the above. > The equivalent question is "What's to stop a commercial grouping > pushing something through an IETF WG that is good for them > and harmful > to the Internet?" The answer is supposed to be "checks and balances > applied by careful WG chartering, Last Call and IESG review." This > could of course be failing - that's a legitimate topic for this list - > but what I was asking is how does Oasis deal with this risk? Oasis very properly ignores the risk. If people are going to do something damaging to the Internet and have the commercial power to deploy then there is nothing either the IETF or OASIS is going to be able to do to stop it. Thinking that the possibility of such control exists is pure conceit. Slashdot is a far more effective brake on such behavior than any decision of the IESG, IAB or any other body. > The market is of course always able to reject something it > doesn't want. > That is orthogonal to something that is harmful. Users don't > understand > what is harmful to the commons, they understand what is good for them. Ah, the poor users, of course they need to be saved from themselves. > That may be true. And if it's true, let's consider that it > may be so *because* > the IETF has been successful at deflecting 'evil' work. The IETF has certainly been successful at stopping work, I fail to see any evidence of discrimination between good work and evil work though. What your entire argument comes down to is that the Internet users are somehow obliged to you and the other great sages to protect them from themselves and big bad companies. Just who are these 'big bad companies' anyway and what makes you think they are other than the employers of the members of the IESG and IAB? Phill From problem-statement-bounces@alvestrand.no Sun Jul 6 13:48:56 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18311 for ; Sun, 6 Jul 2003 13:48:55 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id AC42C62206; Sun, 6 Jul 2003 19:48:25 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from thunker.thunk.org (thunk.org [140.239.227.29]) by eikenes.alvestrand.no (Postfix) with ESMTP id 43FF0621B8 for ; Sun, 6 Jul 2003 19:48:24 +0200 (CEST) Received: from [65.85.192.194] (helo=think.thunk.org) authenticated as tytso by thunker.thunk.org with asmtp (tls_cipher TLSv1:DES-CBC3-SHA:168) (Exim 3.35 #1 (Debian)) id 19ZDcO-0003AV-00; Sun, 06 Jul 2003 13:48:08 -0400 Received: from tytso authenticated as tytso by think.thunk.org with local (Exim 3.35 #1 (Debian)) id 19ZDbV-0000Zm-00; Sun, 06 Jul 2003 13:47:13 -0400 Date: Sun, 6 Jul 2003 13:47:13 -0400 From: "Theodore Ts'o" To: Melinda Shore Message-ID: <20030706174713.GB2159@think> References: <3F082615.2070807@pobox.org.sg> <200307061406.AJE92615@mira-sjc5-c.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200307061406.AJE92615@mira-sjc5-c.cisco.com> User-Agent: Mutt/1.5.4i Cc: James Seng Cc: "Hallam-Baker, Phillip" Cc: "'problem-statement@alvestrand.no'" Subject: Re: ADs who are also WG chairs X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no On Sun, Jul 06, 2003 at 10:06:22AM -0400, Melinda Shore wrote: > > It is absolutely relevant. If you can find an organisation which is not > > restrictive in its membership AND at the same time deal with consensus > > using voting mechanism, then let us know. > > This discussion has parked itself in solution space and > should be moved to the solutions mailing list > (http://eikenes.alvestrand.no/mailman/listinfo/solutions) > or, at least, not continue here. Our task is to identify > and sort through problems without presuming solutions. The first question is whether there is a problem. Phillip Hallam-Baker has expressed (repeated, through many e-mail messages) unhappiness which he has interpreted as problems in the IETF. I'd like to know if these concerns are shared by others in the community, or not. An any experienced working group chair knows, just because one or even a few people are making a huge amount of noise on a list, might mean that there is a problem that few others are seeing --- but it might also just mean that those folks are a minority opinion that are the other side of a "rough consensus". - Ted From problem-statement-bounces@alvestrand.no Sun Jul 6 14:15:26 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18867 for ; Sun, 6 Jul 2003 14:15:25 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 745EB6230D; Sun, 6 Jul 2003 20:14:56 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2075962206 for ; Sun, 6 Jul 2003 20:14:54 +0200 (CEST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h66IEp7F013040; Sun, 6 Jul 2003 11:14:52 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AJE98907; Sun, 6 Jul 2003 11:14:51 -0700 (PDT) Message-Id: <200307061814.AJE98907@mira-sjc5-c.cisco.com> To: "Theodore Ts'o" From: Melinda Shore In-Reply-To: Message from tytso@mit.edu of "Sun, 06 Jul 2003 13:47:13 EDT." <20030706174713.GB2159@think> Date: Sun, 06 Jul 2003 14:14:50 -0400 Cc: "'problem-statement@alvestrand.no'" Subject: Re: ADs who are also WG chairs X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no > I'd like to know if these concerns are shared by others in the > community, or not. We've agreed that we don't need consensus on identified problems for them to be reflected in the document (otherwise the document would be empty). What we need is a clear description of the problem and a general sense that what's being described is not the Problem From Another Planet. Personally, I believe that there really may be some issues here, but they need to be articulated more clearly and we need for the participants in the discussion to show a little more restraint. Thanks, Melinda From problem-statement-bounces@alvestrand.no Sun Jul 6 14:32:51 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19070 for ; Sun, 6 Jul 2003 14:32:50 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1A47F6230D; Sun, 6 Jul 2003 20:32:21 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from thunker.thunk.org (thunk.org [140.239.227.29]) by eikenes.alvestrand.no (Postfix) with ESMTP id 411F662206 for ; Sun, 6 Jul 2003 20:32:19 +0200 (CEST) Received: from [65.85.192.194] (helo=think.thunk.org) authenticated as tytso by thunker.thunk.org with asmtp (tls_cipher TLSv1:DES-CBC3-SHA:168) (Exim 3.35 #1 (Debian)) id 19ZEIv-0003Ki-00; Sun, 06 Jul 2003 14:32:05 -0400 Received: from tytso authenticated as tytso by think.thunk.org with local (Exim 3.35 #1 (Debian)) id 19ZEIB-0000ci-00; Sun, 06 Jul 2003 14:31:19 -0400 Date: Sun, 6 Jul 2003 14:31:19 -0400 From: "Theodore Ts'o" To: Melinda Shore Message-ID: <20030706183119.GC2159@think> References: <20030706174713.GB2159@think> <200307061814.AJE98907@mira-sjc5-c.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200307061814.AJE98907@mira-sjc5-c.cisco.com> User-Agent: Mutt/1.5.4i Cc: "'problem-statement@alvestrand.no'" Subject: Re: ADs who are also WG chairs X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no On Sun, Jul 06, 2003 at 02:14:50PM -0400, Melinda Shore wrote: > > I'd like to know if these concerns are shared by others in the > > community, or not. > > We've agreed that we don't need consensus on identified > problems for them to be reflected in the document (otherwise > the document would be empty). What we need is a clear > description of the problem and a general sense that what's > being described is not the Problem From Another Planet. Agreed. But nevertheless, I think it's fair to ask if Phillip's concerns are shared by others. If they are, it would be a strong indicator that they aren't what you called a "Problem From Another Planet". - Ted From problem-statement-bounces@alvestrand.no Sun Jul 6 14:42:46 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19234 for ; Sun, 6 Jul 2003 14:42:45 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8FD986256C; Sun, 6 Jul 2003 20:42:16 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by eikenes.alvestrand.no (Postfix) with ESMTP id 404BF6230D for ; Sun, 6 Jul 2003 20:42:14 +0200 (CEST) Received: from mou1wnexc02.verisign.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.9/) with ESMTP id h66IgCch002938; Sun, 6 Jul 2003 11:42:13 -0700 (PDT) Received: by mou1wnexc02.verisign.com with Internet Mail Service (5.5.2653.19) id ; Sun, 6 Jul 2003 11:42:13 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E0D22DB@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'Theodore Ts'o'" , Melinda Shore Date: Sun, 6 Jul 2003 11:42:11 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Cc: James Seng Cc: "Hallam-Baker, Phillip" Cc: "'problem-statement@alvestrand.no'" Subject: RE: ADs who are also WG chairs X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no > The first question is whether there is a problem. Phillip > Hallam-Baker has expressed (repeated, through many e-mail messages) > unhappiness which he has interpreted as problems in the IETF. > > I'd like to know if these concerns are shared by others in the > community, or not. How about considering the possibility that people might be dropping out of IETF process because they are fed up with the top down aristocratic process? > An any experienced working group chair knows, just because one or even > a few people are making a huge amount of noise on a list, might mean > that there is a problem that few others are seeing --- but it might > also just mean that those folks are a minority opinion that are the > other side of a "rough consensus". Ah so it is not necessary to have any empirical means of determining what opinion actually is, after all if we don't ever measure something it is always POSSIBLE that the assertion was correct. Regardless of what the WG Chair asserts is the 'consensus' it is POSSIBLE that the votes if counted would have elected Bush President. And since it is POSSIBLE we can assume it to be true. From problem-statement-bounces@alvestrand.no Sun Jul 6 14:44:12 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19265 for ; Sun, 6 Jul 2003 14:44:12 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0A47E6230D; Sun, 6 Jul 2003 20:43:44 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by eikenes.alvestrand.no (Postfix) with ESMTP id E499A62206 for ; Sun, 6 Jul 2003 20:43:41 +0200 (CEST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h66Ihdpp008107; Sun, 6 Jul 2003 11:43:40 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AJE99607; Sun, 6 Jul 2003 11:43:38 -0700 (PDT) Message-Id: <200307061843.AJE99607@mira-sjc5-c.cisco.com> To: "Theodore Ts'o" From: Melinda Shore In-Reply-To: Message from tytso@mit.edu of "Sun, 06 Jul 2003 14:31:19 EDT." <20030706183119.GC2159@think> Date: Sun, 06 Jul 2003 14:43:37 -0400 Cc: "'problem-statement@alvestrand.no'" Subject: Re: ADs who are also WG chairs X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no > Agreed. But nevertheless, I think it's fair to ask if Phillip's > concerns are shared by others. If they are, it would be a strong > indicator that they aren't what you called a "Problem From Another > Planet". To a point. What I'm really asking here is that as the discussion continues, let's all be mindful about lowering the heat rather than raising it and keeping the discussion as impersonal as possible under the circumstances. Melinda From problem-statement-bounces@alvestrand.no Sun Jul 6 14:48:09 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19345 for ; Sun, 6 Jul 2003 14:48:08 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A60BA6230D; Sun, 6 Jul 2003 20:47:38 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by eikenes.alvestrand.no (Postfix) with ESMTP id E2F6D62206 for ; Sun, 6 Jul 2003 20:47:36 +0200 (CEST) Received: from MOU1WNEXC03.verisign.com (verisign.com [65.205.251.57]) by peacock.verisign.com (8.12.9/) with ESMTP id h66IlZch004735; Sun, 6 Jul 2003 11:47:35 -0700 (PDT) Received: by mou1wnexc03.verisign.com with Internet Mail Service (5.5.2653.19) id ; Sun, 6 Jul 2003 11:47:35 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E0D22DC@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'Melinda Shore'" , Brian E Carpenter Date: Sun, 6 Jul 2003 11:47:34 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Cc: "'problem-statement@alvestrand.no'" Cc: "Hallam-Baker, Phillip" Subject: RE: Fixed font v multiple fonts X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no > > Well, I'm currently working both in the IETF (one fixed > width font) and > > in the GGF (as many variable fonts as you want). I find > IETF documents > > substantially easier to deal with. They are much smaller, > which is an > > immense advantage when you are on the road or on a lousy > hotel wireless > > network. They are much easier to discuss on mailing lists > by trivial cut > > and paste. Even the diagrams can easily be cut, pasted, and > updated. > > This line of discussion has, as we've seen repeatedly, > extraordinarily high likelihood of becoming very > unproductive very quickly. If there's a real problem here > aside from differences in personal preference, let's put > some text to it and move on, otherwise let's just move on. The real problem here is that there is absolutely no process for actually deciding the issue. The status quo wins because inertia is always the strongest argument in the IETF. Brian might be right in his assertion that specs that look like they came off a 1950s era teletype might be the acme of perfection for a standards process. But why does he and the rest of the establishment get to decide for the rest of us? Postscript is allowed, despite the fact that it is a closed proprietary markup. So why not allow groups to choose to use HTML? Why do I have to waste my time fighting Word to make it produce baddly formatted text that usually prints out wrong on the printer anyway? If the IETF is "open and inclusive" why not allow for some degree of choice in the matter? Phill From problem-statement-bounces@alvestrand.no Sun Jul 6 16:48:30 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22134 for ; Sun, 6 Jul 2003 16:48:29 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CFE35621B8; Sun, 6 Jul 2003 22:48:00 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from psg.com (psg.com [147.28.0.62]) by eikenes.alvestrand.no (Postfix) with ESMTP id DCB00621B6 for ; Sun, 6 Jul 2003 22:47:59 +0200 (CEST) Received: from [127.0.0.1] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 4.14) id 19ZGQQ-0009Vm-9Z; Sun, 06 Jul 2003 20:47:59 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.20) id 19Ytxd-0001OX-4S; Sat, 05 Jul 2003 13:48:45 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sat, 5 Jul 2003 13:48:44 -0700 To: Melinda Shore References: <20030706174713.GB2159@think> <200307061814.AJE98907@mira-sjc5-c.cisco.com> Message-Id: Cc: problem-statement@alvestrand.no Subject: Re: ADs who are also WG chairs X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit > We've agreed that we don't need consensus on identified > problems for them to be reflected in the document (otherwise > the document would be empty). one hopes the document will differentiate between problems which seem to be widely perceived as such and those which are not. and between those which are root causes and those which are not so perceived. fwiw, i found scott brim's ref extremely educational, and am still digesting it. randy From problem-statement-bounces@alvestrand.no Sun Jul 6 17:59:01 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23278 for ; Sun, 6 Jul 2003 17:59:00 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B2FD462206; Sun, 6 Jul 2003 23:58:31 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0D5D5621FB for ; Sun, 6 Jul 2003 23:58:30 +0200 (CEST) Received: from mou1wnexc01.verisign.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.9/) with ESMTP id h66LwR2Q019414; Sun, 6 Jul 2003 14:58:27 -0700 (PDT) Received: by mou1wnexc01.verisign.com with Internet Mail Service (5.5.2653.19) id ; Sun, 6 Jul 2003 14:58:27 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E0D22DF@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'Brian E Carpenter'" , "Hallam-Baker, Phillip" Date: Sun, 6 Jul 2003 14:58:25 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Cc: "'problem-statement@alvestrand.no'" Subject: RE: Fixed font v multiple fonts X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no > Against this is is the lack of italics or shading to > distinguish symbols > and examples from text; that is certainly an advantage in GGF > documents. >From my point of view it is almost impossible to accurately compare a cryptographic algorithm described in the litterature with the alleged same algorithm in an IETF RFC. Subscripts, superscripts etc. are part of the notation we use for our work. Use of R_AS etc is simply not an acceptable substitute. One of the reasons that the IETF has produced poor specs is that it has resolutely refused to apply formal methods of protocol design to the process. Adopting a document format that actively prevents the use of any formal specification language prevents anyone even trying. Phill From problem-statement-bounces@alvestrand.no Sun Jul 6 18:56:34 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25111 for ; Sun, 6 Jul 2003 18:56:33 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D5C6762206; Mon, 7 Jul 2003 00:56:04 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from hammerhead.shentel.net (hammerhead.shentel.net [204.111.11.43]) by eikenes.alvestrand.no (Postfix) with ESMTP id C3923621FB for ; Mon, 7 Jul 2003 00:56:02 +0200 (CEST) Received: from Steve (ha96s051.d.shentel.net [204.111.96.51]) by hammerhead.shentel.net (8.12.9/8.12.9) with SMTP id h66MtxJ4006213; Sun, 6 Jul 2003 18:56:00 -0400 From: "Steve Silverman" To: "Hallam-Baker, Phillip" Date: Sun, 6 Jul 2003 18:57:00 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <2A1D4C86842EE14CA9BC80474919782E0D22DF@mou1wnexm02.verisign.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Cc: problem-statement@alvestrand.no Subject: RE: Fixed font v multiple fonts X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit While I agree that the draft text format is hard to read and hard to work with (Other groups I have worked with allowed standard Word Processor input) and I would really prefer being able to use a decent word processor to write drafts, I think that this issue is well down on the list of problems in the IETF. Far more important is: o The lack of a formal democratic (or quasi-democratic) decision-making process. o A serious attempt at architectural work before detailed coding is specified. o Various issues that have been mentioned on this list. Steve Silverman > -----Original Message----- > From: problem-statement-bounces@alvestrand.no > [mailto:problem-statement-bounces@alvestrand.no]On Behalf Of > Hallam-Baker, Phillip > Sent: Sunday, July 06, 2003 5:58 PM > To: 'Brian E Carpenter'; Hallam-Baker, Phillip > Cc: 'problem-statement@alvestrand.no' > Subject: RE: Fixed font v multiple fonts > > > > > Against this is is the lack of italics or shading to > > distinguish symbols > > and examples from text; that is certainly an advantage in GGF > > documents. > > >From my point of view it is almost impossible to > accurately compare a > cryptographic algorithm described in the litterature with > the alleged same > algorithm in an IETF RFC. > > Subscripts, superscripts etc. are part of the notation we > use for our work. > Use of R_AS etc is simply not an acceptable substitute. > > One of the reasons that the IETF has produced poor specs is > that it has > resolutely refused to apply formal methods of protocol design to the > process. Adopting a document format that actively prevents > the use of any > formal specification language prevents anyone even trying. > > > Phill > > From problem-statement-bounces@alvestrand.no Sun Jul 6 23:17:08 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28700 for ; Sun, 6 Jul 2003 23:17:07 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 419CE6230D; Mon, 7 Jul 2003 05:16:38 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5AC9262206 for ; Mon, 7 Jul 2003 03:06:58 +0200 (CEST) Received: from tsg1 (213.sanjose-06-07rs16rt.ca.dial-access.att.net[12.81.2.213]) by mtiwmhc12.worldnet.att.net (mtiwmhc12) with SMTP id <2003070701065511200iv4uee>; Mon, 7 Jul 2003 01:06:56 +0000 Message-ID: <024b01c34424$00d69480$020aff0a@tsg1> From: "todd glassey" To: Date: Sun, 6 Jul 2003 13:18:18 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailman-Approved-At: Mon, 07 Jul 2003 05:16:37 +0200 Subject: Fw: proposed text for updated ISOC Copyright Statement - generic flaws in the IETF's ISOC copyrigtht statement. X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit this posting to the IPR list documents a problem that the IPR working group is having with whether Individual Rights are more important to the larger IETF operations and how these effect IP policies. It therefore is relevant to this WG. Todd ----- Original Message ----- From: "todd glassey" To: "Ole Jacobsen" Sent: Thursday, July 03, 2003 6:47 AM Subject: Re: proposed text for updated ISOC Copyright Statement - generic flaws in the IETF's ISOC copyrigtht statement. > OK - my apologies my friend - you have run into the same brick wall that the > IP lawyers, those that have had initiatives suppressed, and I did. > > ----- Original Message ----- > From: "Ole J. Jacobsen" > To: "todd glassey" > Sent: Wednesday, July 02, 2003 8:07 AM > Subject: Re: proposed text for updated ISOC Copyright Statement - generic > flaws in the IETF's ISOC copyrigtht statement. > > > > Private reply: > > > > OK, but I don't see a solution that would not completely cripple the > > process. > > The question then is whether the IETF as it is, is more important than > individual rights and the problem is that I think that the IETF has a lot on > the line here. > > My take is that if some serious changes are not made that there is possibly > some antitrust litigation coming and well - yes it likely will force some > serious changes on he IETF, but there is this fundamental question to answer > now, whether the IETF's processes that were grandfathered prior to the > existance of most of this IP are still workable now that there is a serious > necessity to address the ownership issues. > > > > So you run the risk or "releasing" something that is IPR > > while keeping the process moving. > > Which brings up the issues of damage control and how to react to being > formally notified by someone's lawyers that they are not to happy with > something. > > > The "Note Well" stuff is at least > > a recognition that there may be a problem and the IETF wants to avoid > > it. > > And to some extent the Note Well is better than nothing but it still only > addresses what people say in their own persona. Not what they also say as > their sponsor's Agent. > > > It may not satisfy your legal sensibilities, but I very much doubt > > that a waterproof solution can be found that will satisfy the IETF. > > I dont think that the IETF really has a choice here. > > Its an issue of legal necessity not one of "style"... > > > > > > Ole > > > > > > > > Ole J. Jacobsen > > Editor and Publisher, The Internet Protocol Journal > > Tel: +1 408-527-8972 GSM: +1 415-370-4628 > > E-mail: ole@cisco.com URL: http://www.cisco.com/ipj > > > > > > > > > From problem-statement-bounces@alvestrand.no Mon Jul 7 01:12:13 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01019 for ; Mon, 7 Jul 2003 01:12:12 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 86CBD6256B; Mon, 7 Jul 2003 07:11:42 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id 230976230D; Mon, 7 Jul 2003 07:11:40 +0200 (CEST) Date: Mon, 07 Jul 2003 07:11:40 +0200 From: Harald Tveit Alvestrand To: Dave Crocker Message-ID: <552230000.1057554700@askvoll.hjemme.alvestrand.no> In-Reply-To: <1101423707.20030706085955@brandenburg.com> References: <120210000.1055072340@askvoll.hjemme.alvestrand.no> <481518433.20030608091336@brandenburg.com> <125670000.1055090084@askvoll.hjemme.alvestrand.no> <721113479.20030608173246@brandenburg.com> <148310000.1055147276@askvoll.hjemme.alvestrand.no> <1101423707.20030706085955@brandenburg.com> X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: problem-statement@alvestrand.no Subject: Re: ISSUE: Determinants for timeliness missing in section 2.1 X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: quoted-printable --On s=F8ndag, juli 06, 2003 08:59:55 +0200 Dave Crocker = wrote: > HTA> When we have the case of "plenty of people .... that had a very = clear > HTA> vision of what they wanted to achieve", and have "requirements to > satisfy HTA> additional constraints", the people imposing additional > constraints are HTA> people too, and part of the community. What's more, > in the cases where HTA> those "imposing" people are chosen as leaders of > the community, they HTA> believe that they represent other members of the > community - and may even HTA> be right. > > This was an extremely helpful posting. I think it honestly and > accurately highlights two points of disparity. > > One is that the folks imposing those additional requirements are not the > folks doing the work to satisfy them. Consult one of Randy's learned > texts on management about the effect of a pattern of such impositions on > productivity and morale. A pattern of imposing, like this, needs to be > balanced by an accompanying pattern of being perceived to help achieve > timely and productive results. [I'm not convinced that this point achieves anything but pointless debate=20 about who is doing "real" work.... I won't pursue at this time] > > The other point of disparity is that this is a community that supposedly > has its ultimate authority in the community, not in its "leaders". > Leaders in this community are supposed to be facilitators at pursuing > community rough consensus, rather than folks who "impose" requirements. We agree. When the leaders are wrong, and impose additional requirements that are=20 *not* the community's, the leaders need reeducation wrt what the=20 requirements that the community wants *really* are. I still have not been so educated in the IMPP case, it seems, but that is a = debate for another forum. From problem-statement-bounces@alvestrand.no Mon Jul 7 01:48:40 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01645 for ; Mon, 7 Jul 2003 01:48:39 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8CAB66230D; Mon, 7 Jul 2003 07:48:08 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by eikenes.alvestrand.no (Postfix) with ESMTP id A2C126230D for ; Mon, 7 Jul 2003 07:48:06 +0200 (CEST) Message-ID: <006501c3444b$5d344b10$826015ac@dclkempt40> From: "James Kempf" To: "Brian E Carpenter" , "Hallam-Baker, Phillip" References: <2A1D4C86842EE14CA9BC80474919782E0D22D0@mou1wnexm02.verisign.com> <3F084029.16753D46@hursley.ibm.com> Date: Mon, 7 Jul 2003 07:48:12 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: Fixed font v multiple fonts X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit IMHO, the font's don't make a big difference. One thing that does is the inability to do good graphics. It is extremely difficult, almost impossible, to include graphs of data in IETF documents. This makes it very hard to present data derived from experiments as underlying support for a particular engineering approach to a protocol design. I think this might help to re-enforce the tendency in IETF for people's opinions on technical matters to be more important than experimental data. Also, good quality graphics of system designs are difficult to do with ASCII, ASCII drawing packages not widthstanding. Though the correlation is somewhat more problemantic, I wonder if this doesn't contribute some to the tendency in IETF to avoid looking at the larger scale system aspects of a particular problem, and concentrate more on the point protocol aspects. The premise here is that the difficulty in communicating the result has a tendency to supress the conversation. For a good example of both these effects, see the IKEv2 draft. While reading the draft, I found myself looking for some graphs of data to support the redesign of IKE, and some good system diagrams explaining the underlying system and protocol flows in all the cases that are discussed in the text. The few ASCII diagrams in the document are utterly inadequate, IMHO, for conveying the complexity that the protocol is trying to capture. jak ----- Original Message ----- From: "Brian E Carpenter" To: "Hallam-Baker, Phillip" Cc: Sent: Sunday, July 06, 2003 5:28 PM Subject: Fixed font v multiple fonts > "Hallam-Baker, Phillip" wrote: > ... > > 2.2 > > > > This section should address the fact that IETF documents are poorly > > formatted in a fixed width font making them VERY hard to read. They look > > like a second rate piece of work and many engineers will avoid IETF process > > for that reason alone. > > Well, I'm currently working both in the IETF (one fixed width font) and > in the GGF (as many variable fonts as you want). I find IETF documents > substantially easier to deal with. They are much smaller, which is an > immense advantage when you are on the road or on a lousy hotel wireless > network. They are much easier to discuss on mailing lists by trivial cut > and paste. Even the diagrams can easily be cut, pasted, and updated. > > Against this is is the lack of italics or shading to distinguish symbols > and examples from text; that is certainly an advantage in GGF documents. > > There may be some arguments for having the final product look pretty, > by use of multiple fonts and artistic diagrams. But in my experience, > using these techniques in documents under development is a problem > in itself. > > Brian > > > From problem-statement-bounces@alvestrand.no Mon Jul 7 03:26:57 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16230 for ; Mon, 7 Jul 2003 03:26:56 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B832062582; Mon, 7 Jul 2003 09:26:24 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from netcore.fi (netcore.fi [193.94.160.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id EA3BA622AC for ; Mon, 7 Jul 2003 09:26:22 +0200 (CEST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h677Q8d09832; Mon, 7 Jul 2003 10:26:08 +0300 Date: Mon, 7 Jul 2003 10:26:08 +0300 (EEST) From: Pekka Savola To: "Hallam-Baker, Phillip" In-Reply-To: <2A1D4C86842EE14CA9BC80474919782E0D22DC@mou1wnexm02.verisign.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: "'Melinda Shore'" Cc: "'problem-statement@alvestrand.no'" Cc: Brian E Carpenter Subject: RE: Fixed font v multiple fonts X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no On Sun, 6 Jul 2003, Hallam-Baker, Phillip wrote: > Why do I have to waste my time fighting Word to make it produce > baddly formatted text that usually prints out wrong on the > printer anyway? It is out fault if you're using a word processor which is unoptimal for the task, or haven't looked at various templates for that particular word processor if you want to use it in any case? Some (most?) don't use Word for producing Internet Drafts, and are quite happy about it. No fighting is necessary. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From problem-statement-bounces@alvestrand.no Mon Jul 7 10:49:27 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28167 for ; Mon, 7 Jul 2003 10:49:24 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7282061B83; Mon, 7 Jul 2003 16:48:48 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from relay2.softcomca.com (relay2.softcomca.com [168.144.1.68]) by eikenes.alvestrand.no (Postfix) with ESMTP id 165CA61A96 for ; Mon, 7 Jul 2003 15:53:53 +0200 (CEST) Received: from M2W035.mail2web.com ([168.144.251.140]) by relay2.softcomca.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 7 Jul 2003 09:53:52 -0400 Message-ID: <157240-2200371713535294@M2W035.mail2web.com> X-Priority: 3 X-Originating-IP: 216.62.6.129 X-URL: http://mail2web.com/ From: "spencer@mcsr-labs.org" To: problem-statement@alvestrand.no Date: Mon, 7 Jul 2003 09:53:52 -0400 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 07 Jul 2003 13:53:52.0220 (UTC) FILETIME=[32F169C0:01C3448F] Subject: RE: Comments on problem statement X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list Reply-To: spencer@mcsr-labs.org List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: quoted-printable Dear Phillip, I'm on the problem statement editor team, but am speaking only for myself=2E=2E=2E And thank you for your comments on the draft - we wish we had more comments=2E Spencer ----- Original Message -----=20 From: "Hallam-Baker, Phillip" To: Sent: Saturday, July 05, 2003 8:30 AM Subject: Comments on problem statement > 1=2E1 > > These failures are just those that afflict many small organizations > trying to make the transition from a small organization which can be > run informally and where essentially all participants fully share the= > aims, values and motivations of the leadership, > > That is NOT the issue, the problem has nothing to do with shared values,= > this statement contains exactly the type of arrogant assumption that has= > poisoned relationships between the establishment and the proletariat=2E > > When there is a problem with the proletariat refusing to be led blindly the > establishment complain sniffily about 'lack of shared values' - thus putting > themselves up on a pedestal=2E > > Can't you folk see how insulting this attitude is? > Speaking only for myself - I wasn't trying to insult anyone=2E I believe t= his text came from discussions about the expanded scope of IETF work during the 1990s, in several areas where we were absorbing new groups of participants who had not previously been active in developing protocols for the Internet=2E The influx of telecom participants, the influx of WWW participants (we even had an HTML working group for a while!), and the influx of wireless participants are the types of things I was thinking about=2E This wasn't to say that any of these folks weren't smart - they were often smart about things that didn't overlap a lot with what IETF was doing in the early 1990s=2E Not just an IETF issue - My boss at Fujits= u told me that's why he hired me in 2000=2E "Please send text=2E" There are more people on the editor team who think they are newbies than think they are oldies=2E Dave Crocker's lowest- numbered RFC is 351, but that's about 1800 lower than the average for the editor team=2E We're not trying to insult the proletariat, we think they include us=2E=2E=2E > The PROBLEM is a well known one that there is a functional limit of abou= t > 150 people for informally organized groups=2E It is a basic limitation o= f the > human brain, it simply does not have enough RAM to maintain knowledge of= > relationships amongst bigger groups=2E I would agree with this, and in my spare time, I'm trying to remember time= s when we've scaled anything without inserting levels of hiearchy=2E So far,= without success=2E Please send text that does not require the over-decimat= ion=20 of the IETF to 150 participants! > > > 2=2E2 > > This section should address the fact that IETF documents are poorly > formatted in a fixed width font making them VERY hard to read=2E They lo= ok > like a second rate piece of work and many engineers will avoid IETF process > for that reason alone=2E I hope this is an overstatement, but even if it's not, XML2RFC has been very useful for me, and seems like a step in the right direction=2E If you= don't like the way ftp://ftp=2Erfc-editor=2Eorg/in-notes/rfc2629=2Etxt loo= ks, maybe Marshall Rose didn't, either - at least, he generated http://xml=2Eresource=2Eorg/public/rfc/html/rfc2629=2Ehtml from the same input file=2E I would like to see us spending more time talking about what specifications should look like, but starting= with XML is one way that lets us stop talking about the universality of=20= pure text and start talking about what is actually useful in a specification - because we can always generate an RFC that looks (way too much?) like ftp://ftp=2Erfc-editor=2Eorg/in-notes/rfc1=2Etxt=2E=2E= =2E If I understand the COACH BoF agenda and scope, this is probably a more appropriate topic there, as we move into solution space=2E=2E=2E > [deleted down to] > > > 2=2E6 The IETF Management Structure is not Matched to the Current Size a= nd > Complexity of the IETF > > IT could well be that the ROLE of the IETF management structure is not > matched to the current size and scope=2E The management structure is > considerably larger than OASIS which at this point is managing an equivalent > number of active specifications=2E > > If the management does less the problem is reduced=2E To do less the > management have to relinquish control over the process outcome=2E > > I fail to see the fearful penalties that the IESG believe will attend a > faulty spec=2E In my experience completely broken specs don't make it to= > production=2E There is plenty of brokeness that went into the Web but th= at > almost always happened as a result of someone deliberately circumventing= the > process completely=2E > My impression (please correct me if I'm wrong) is that we started out worrying that a faulty congestion control or routing specification might=20= result in a disaster, but in recent years, the worry has been that faulty=20= specifications take years, if not decades, to disappear (see the "web=20 server releases never disappear" discussions in the late 1990s, for=20 example)=2E So I'm not sure we still have an overwhelming "fear" - but we=20= act a lot like we did when we had such a fear=2E My opinions only, of course=2E Spencer -------------------------------------------------------------------- mail2web - Check your email from the web at http://mail2web=2Ecom/ =2E From problem-statement-bounces@alvestrand.no Mon Jul 7 10:49:40 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28197 for ; Mon, 7 Jul 2003 10:49:39 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7401C61B90; Mon, 7 Jul 2003 16:48:57 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by eikenes.alvestrand.no (Postfix) with ESMTP id EE7FA61A96 for ; Mon, 7 Jul 2003 16:24:20 +0200 (CEST) Received: from BBFUJIP.brandenburg.com (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h67ERPF08443; Mon, 7 Jul 2003 07:27:27 -0700 Date: Sun, 6 Jul 2003 23:02:17 +0200 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/11) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <18451966043.20030706230217@brandenburg.com> To: Bernard Aboba In-Reply-To: References: MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: MAJOR ISSUE: Causes of "problems" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Bernard, BA> So is "scope expansion" a potential *cause* of "problems"? Or is it a BA> "problem" in its own right? By way of trying to pursue the question you asked (...) Perhaps both? Expansion of scope means we spread our limited resources thinner. This means we cannot provide as much (necessary) attention to individual bits of work. In general, we often seem to treat ourselves as having infinite resources. For a community well-versed in queuing theory, this is rather strange. Expansion of scope also risks our working on things we know little about. The dangers of that are pretty obvious. In general, we seem to focus only on whether a topic is important, and not very much on whether we are community that is competent to work on it. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Mon Jul 7 10:49:54 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28225 for ; Mon, 7 Jul 2003 10:49:52 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7D2E161B96; Mon, 7 Jul 2003 16:49:04 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by eikenes.alvestrand.no (Postfix) with ESMTP id 220FE61B83 for ; Mon, 7 Jul 2003 16:39:19 +0200 (CEST) Received: from BBFUJIP.brandenburg.com (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h67EgbF09021; Mon, 7 Jul 2003 07:42:39 -0700 Date: Mon, 7 Jul 2003 16:39:38 +0200 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/11) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <391303013.20030707163938@brandenburg.com> To: avri In-Reply-To: References: <70696325.1057000829@p3.JCK.COM> MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Cc: "problem-statement@alvestrand.no" Subject: Accomodating ESL speakers X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list Reply-To: Dave Crocker List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit avri, a> do is indeed a significant part of the problem in my opinion. Those of a> us a> who can command the language to do what we want it to do (well I a> don't always succeed) and those of us who can play the process game, a> often think that everyone can do what we can do. It is not the case. If we are going to try to be sensitive to IETF participants who speak English as a second language, we might want to start with the way we conduct our meetings, before worrying about our appeals processes. As a community of individuals, we are grotesquely insensitive to these participants. We speak much too fast, and often in incomplete sentences. We use idioms all the time. We get impatient when someone requests that we repeat ourselves. And then, of course, there is the dominant "American" style of interactions, which can most kindly be described as wildly different from what is normal in most other countries, especially for formal situations like a standards meeting. At any rate, one of the major benefits of good presentation slides is their benefit to non-native english speakers. I suspect that the real-time jabber transcriptions can be equally useful for them. In general, our Internet Drafts requirements are quite loose, with respect to language. This seems helpful for non-native english speakers. However, as John K. notes, it is not unreasonable to find someone to help with the language, just as it is good to find help for ancillary technical matters that pertain to the content. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Mon Jul 7 12:49:50 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03318 for ; Mon, 7 Jul 2003 12:49:49 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DA93861B87; Mon, 7 Jul 2003 18:49:18 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by eikenes.alvestrand.no (Postfix) with ESMTP id A61CE61A96; Mon, 7 Jul 2003 17:03:43 +0200 (CEST) Received: from BBFUJIP.brandenburg.com (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h67F73F10432; Mon, 7 Jul 2003 08:07:05 -0700 Date: Mon, 7 Jul 2003 17:03:43 +0200 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/11) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1012748672.20030707170343@brandenburg.com> To: Harald Tveit Alvestrand In-Reply-To: <552230000.1057554700@askvoll.hjemme.alvestrand.no> References: <120210000.1055072340@askvoll.hjemme.alvestrand.no> <481518433.20030608091336@brandenburg.com> <125670000.1055090084@askvoll.hjemme.alvestrand.no> <721113479.20030608173246@brandenburg.com> <148310000.1055147276@askvoll.hjemme.alvestrand.no> <1101423707.20030706085955@brandenburg.com> <552230000.1057554700@askvoll.hjemme.alvestrand.no> MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: ISSUE: Determinants for timeliness missing in section 2.1 X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list Reply-To: Dave Crocker List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Harald, >> One is that the folks imposing those additional requirements are not the >> folks doing the work to satisfy them. Consult one of Randy's learned >> texts on management about the effect of a pattern of such impositions on ... HTA> [I'm not convinced that this point achieves anything but pointless debate HTA> about who is doing "real" work.... I won't pursue at this time] Harald, if you had really chosen not to pursue it, then you would not have written something that rejected it as "pointless debate", particularly when I offered it as a fundamental point, which I encourage you to consider further: I was referring to situations in which we have people doing real work of real quality for a real market, and the work is delayed for external factors, by people who are not perceived as helping to resolve the problems. The de-motivating effect of such forces is not "pointless", although it often makes participation seem that way. The IETF has, historically, given priority to the people who do the work. Others are not irrelevant, but there is a clear -- and, I believe, entirely appropriate -- difference in their role. It does not take much of a review of IETF history to see that most generalized requirements for "coordination" -- and most especially those that are imposed post-hoc -- are not successful, except at causing delay. Feel free to cite examples to the contrary. I do not know of any myself. It is particularly problematic to impose delays *after* work has been done that followed its charter, proceeded in a timely fashion, and shows all the signs of having an eager community to implement it. HTA> I still have not been so educated in the IMPP case, it seems, but that is a HTA> debate for another forum. Problems with IMPP are one thing, and convincing the IETF Chair who happened to previously be chair of IMPP, is another. Neither is the issue, here. The issue I was citing was forcing XMPP to be delayed, when there are no known problems with it. Citing the need to resolve IMPP matters, prior to processing XMPP working group output, is a very good example of a post-hoc requirement that is -- at very best -- only going to cause delay. So far, no one has stated that there are any technical problems with XMPP. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Mon Jul 7 12:49:57 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03341 for ; Mon, 7 Jul 2003 12:49:55 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CD25261B90; Mon, 7 Jul 2003 18:49:26 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from relay2.softcomca.com (relay2.softcomca.com [168.144.1.68]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9372961B83 for ; Mon, 7 Jul 2003 17:04:08 +0200 (CEST) Received: from M2W041.mail2web.com ([168.144.251.147]) by relay2.softcomca.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 7 Jul 2003 11:04:07 -0400 Message-ID: <410-220037171547515@M2W041.mail2web.com> X-Priority: 3 X-Originating-IP: 216.62.6.129 X-URL: http://mail2web.com/ From: "spencer@mcsr-labs.org" To: problem-statement@alvestrand.no Date: Mon, 7 Jul 2003 11:04:07 -0400 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 07 Jul 2003 15:04:07.0848 (UTC) FILETIME=[03A73280:01C34499] Subject: Re: MAJOR ISSUE: Causes of problems X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list Reply-To: spencer@mcsr-labs.org List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: quoted-printable Dear Dave, I think this falls in the same category as a group of people who know what synchronization does to congestion, but who continue to let all of the afternoon sessions out at the same time the cookies arrive=2E We should know better, but=2E=2E=2E Spencer ----- Original Message -----=20 From: "Dave Crocker" To: "Bernard Aboba" Cc: Sent: Sunday, July 06, 2003 4:02 PM Subject: Re: MAJOR ISSUE: Causes of "problems" >=20 > In general, we often seem to treat ourselves as having infinite > resources=2E For a community well-versed in queuing theory, this is > rather strange=2E -------------------------------------------------------------------- mail2web - Check your email from the web at http://mail2web=2Ecom/ =2E From problem-statement-bounces@alvestrand.no Mon Jul 7 14:24:44 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06311 for ; Mon, 7 Jul 2003 14:24:42 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CD41B61B88; Mon, 7 Jul 2003 20:24:11 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from warlock.qualcomm.com (warlock.qualcomm.com [129.46.50.49]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6E09F61B83; Mon, 7 Jul 2003 20:24:04 +0200 (CEST) Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by warlock.qualcomm.com (8.12.9/8.12.3/1.0) with ESMTP id h67HZvTo009520; Mon, 7 Jul 2003 10:35:57 -0700 (PDT) Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h67HZpBd009601 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 7 Jul 2003 10:35:51 -0700 (PDT) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by sabrina.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h67HZmBC029461; Mon, 7 Jul 2003 10:35:49 -0700 (PDT) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: <1012748672.20030707170343@brandenburg.com> References: <120210000.1055072340@askvoll.hjemme.alvestrand.no> <481518433.20030608091336@brandenburg.com> <125670000.1055090084@askvoll.hjemme.alvestrand.no> <721113479.20030608173246@brandenburg.com> <148310000.1055147276@askvoll.hjemme.alvestrand.no> <1101423707.20030706085955@brandenburg.com> <552230000.1057554700@askvoll.hjemme.alvestrand.no> <1012748672.20030707170343@brandenburg.com> Date: Mon, 7 Jul 2003 10:35:53 -0700 To: Dave Crocker , Harald Tveit Alvestrand From: hardie@qualcomm.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: problem-statement@alvestrand.no, Dave Crocker Subject: Re: ISSUE: Determinants for timeliness missing in section 2.1 X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Dave, Harald, In the interests of more light, less heat, for this particular list, may I suggest that we continue discussion of the IMPP situation either on the IETF main list or in person? The particulars of the situation may require public discussion, but I think the main problem for this list has already been raised: It is difficult to manage dependencies between groups and the result of creating those dependencies may be that the output of a group is slower than it would be without that dependency or set of dependencies. I'll send a follow-up message to the individuals on the XMPP specifics; if they indicate there is broad interest or others indicate broad interest, we'll explore an appropriate public forum to discuss it. As a _very_ brief note on the subject, I last week asked the Chairs of XMMP to hold the XMPP core documents in their queue or understand that I will hold them in my queue prior to issuing an IETF last call. This is because the current XMPP charter imposes a dependency on IMPP and there has a been a challenge by Dave and Marshall on the appropriateness of the work project and output of IMPP. Though the IMPP-related mechanisms have been put into a separate document, I do not believe that the IETF last call can adequately assess the set of documents if the scope is not known, that is, we're not sure whether they are meant to be part of a mesh of cooperating IM systems or meant to stand alone (the question of how to judge "completeness" in 2026 terms being critical). Were we not about to have a face-to-face meeting, the IESG would have considered the IMPP documents on this Thursday's conference call, but I have held them off so we could gather community input in Vienna. They are on the IESG's tentative agenda for its Sunday meeting, and I know of at least one person planning to speak to the subject at the IESG open mic. Again, I believe follow-ups to this belong elsewhere; if you are interested in following up _prior_ to Vienna, please let me know by email if you are not on the cc list now. thanks, Ted Hardie (Area Advisor for XMPP & IMPP) At 5:03 PM +0200 7/7/03, Dave Crocker wrote: > > >The issue I was citing was forcing XMPP to be delayed, when there are no >known problems with it. Citing the need to resolve IMPP matters, prior >to processing XMPP working group output, is a very good example of a >post-hoc requirement that is -- at very best -- only going to cause >delay. > >So far, no one has stated that there are any technical problems with >XMPP. > >d/ >-- > Dave Crocker > Brandenburg InternetWorking > Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Mon Jul 7 16:46:03 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14507 for ; Mon, 7 Jul 2003 16:46:02 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A0B9561B88; Mon, 7 Jul 2003 22:45:31 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by eikenes.alvestrand.no (Postfix) with ESMTP id 07AB961B83 for ; Mon, 7 Jul 2003 22:45:30 +0200 (CEST) Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h67KjRfU023295; Mon, 7 Jul 2003 13:45:27 -0700 (PDT) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h67KjJQ05585; Mon, 7 Jul 2003 22:45:19 +0200 (MEST) Date: Mon, 7 Jul 2003 22:44:47 +0200 (CEST) From: Erik Nordmark To: "Bound, Jim" In-Reply-To: "Your message with ID" <9C422444DE99BC46B3AD3C6EAFC9711B032413E2@tayexc13.americas.cpqcorp.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Cc: problem-statement@alvestrand.no, Erik Nordmark , Charlie Perkins Subject: RE: The need for smaller protocol specifications X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list Reply-To: Erik Nordmark List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Did you intend to send this to the list? Read like more of a personal note to me. Let's discover what good beer we can find in Vienna and chat then!! When will you arrive? I'm coming in Sat afternoon and have an IESG meeting part of Sunday. Erik >----- Begin Included Message -----< Date: Thu, 3 Jul 2003 00:53:23 -0400 From: "Bound, Jim" Subject: RE: The need for smaller protocol specifications To: "Erik Nordmark" , "Charlie Perkins" Cc: problem-statement@alvestrand.no, "Bound, Jim" Erik, I am off this list but your catching up on old email I guess. I will respond to you privately engineer to engineer not IETF politician to politician which I will not even bother with anymore and ignore. But there was something else that came up and as you ship products too, is that the IETF needs to ship a product faster and leaner and more often. Never has the IETF been the subject of concern in the industry as it is today many factions, entities, and governments are highly concerned the IETF has lost it completely to achieve time to market. I am on vacation now and your one of the few humans on the planet that I will respond to in the all to infrequent exercise of doing something besides our technology work/life. Or we can talk in Vienna privately. The problem is treat this work here with a deliverable and fix the IESG work load. There are individual problem children across the IETF with bad manners, impolite, and a legend in their own mind. So what!! they exist everywhere in all aspects of life and here in the IETF. It is unfortuneate when they are leaders but that happens too. But if you all focus on time-to-market and the mass numbers of specs using SIR or some other such group most of the problems that can be resolved will begin to get fixed. To bad you left the IESG and that put me over the top, after the Nomcom decided Scott should not stay, for now I give up and will watch the IESG on my work in detail. But given your rationale I would have done the same and why I am riding my harley around the east coast and your resignation influenced me too, so in that respect thanks for that "honest" open mail. Like common sense that is rare to see these days. /jim > -----Original Message----- > From: Erik Nordmark [mailto:Erik.Nordmark@sun.com] > Sent: Wednesday, July 02, 2003 12:11 PM > To: Charlie Perkins; Bound, Jim > Cc: problem-statement@alvestrand.no > Subject: Re: The need for smaller protocol specifications > > > > I'm going to try to describe what I see as a major problem, but the > > solution is not a black-and-white cure-all rule. It's more > a matter > > of perspective, balance, and judgement. > > > > Put simply, protocol specifications are being required to > contain too > > many features. In my favorite example, a very simple signaling > > protocol specification was eventually required to also incorporate > > other related specifications: > > - A discovery algorithm > > - A key distribution algorithm > > - Renumbering algorithms > > - Compatibility recipes for an incompatible security protocol > > - other stuff too. > > Let me try to add my 2 cents on this topic even though I'm > behind on the list. > > The way I would characterize the problem is that the > protocols the IETF undetakes today might take a longer time > to develop because: > - the problem is harder - we've solved the easy problems already > - we as a community place higher requirements (for instance, > deployable security > for the protocol; congestion control; and we might desire > less manual > configuration; etc) > - interaction with other artifacts, whether our own protocol > specifications > or something else that is deployed on the net. > > If you look at the third bullet alone for Internet Area stuff > there is an amazing list. Making it concrete using mobile > IPv6 (Charlie's example) I immediately come up with: > - interaction with DHCP (assigned home and/or care-of addresses) > - interaction with stateless addrconf (assigned home and/or > care-of addresses) > - interaction with RFC 3041 temporary addresses (assigned as > home and/or > care-of addresses) > - interaction with IPsec for protecting the data traffic (as > opposed to > using IPsec to protect the Mobile IPv6 signalling protocol itself) > - interaction with renumbering (the home link and/or the > visited link) > - combinations of the above... > > For other protocols there might be concerns about other > interactions, such as > interaction with NAT boxes in the path. Presumably there are > other lists that are more pertinent for other parts of the stack. > > My point isn't about Mobile IPv6 or the individual items in > the above lists, > but about the total complexity of the space. > > I suspect that as a result of this, protocol specifications > become longer and more complex and, even if the solutions to > deal with individual pieces are separable, in order to get > the protocol approved it might be necessary to deal with > many, if not all, of the issues. > > Presumably the community doesn't want to compromise away some > key requirements (such as a reasonable level of security; > congestion control) but what about the interaction with other > protocols and artifacts; is it ok to not worry about those > initially? As a hypothetical example, would there have been > concerns if DHCPv6 worked and Mobile IPv6 > worked, but the combination couldn't be made to work? (Again, > I'm not asking about the specifics but about the general case > of interaction with existing protocols or protocols that are > being developed in parallel.) > > In other cases working groups have first specified a protocol > and later made some extensions to e.g. make it cope better > with NATs. While such an approach could be taken for more of > the "interactions" above to make smaller separate > specifications, it doesn't really address the > complexity of the total solution. > > So I think part of the issue is that protocols end up being > complex because they need to fit into a complex world, and at > least some of that complex world the IETF has created itself. > Restraining what the community creates could be one approach > to limit the complexity. Perhaps better modularity and/or > less number of ways to do the same thing is another way. [As > an aside, note that in the above list there are interactions > with the 3 different ways that IPv6 addresses can be autoconfigured.] > > > Jim said: > > PROBLEM: The IETF process to complete specifications puts to many > > features in those initial specifications. [This would be sub bullet > > again above]. > > In Charlie's example many the "features" aren't there as > improvements to the > protocol itself (the dynamic home agent discovery might be), > but instead driven by the complexity outside of the protocol > being specified. > > One possible problem could be that WGs wants to put too many > features in the > initial specification. > Another possible problem could be that the external word (or > the IETF community, or the IESG) requires interaction with > too many different things. From the wording above I can't > tell whether you had one or both of these in mind. > > Erik > > >----- End Included Message -----< From problem-statement-bounces@alvestrand.no Tue Jul 8 03:25:21 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12777 for ; Tue, 8 Jul 2003 03:25:20 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3CFC361B89; Tue, 8 Jul 2003 09:24:50 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from netcore.fi (netcore.fi [193.94.160.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 01D7561B87 for ; Tue, 8 Jul 2003 09:24:48 +0200 (CEST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h687OXI23014; Tue, 8 Jul 2003 10:24:33 +0300 Date: Tue, 8 Jul 2003 10:24:32 +0300 (EEST) From: Pekka Savola To: todd glassey In-Reply-To: <02fb01c34476$b6724e40$020aff0a@tsg1> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: "'Melinda Shore'" , problem-statement@alvestrand.no, "Hallam-Baker, Phillip" , Brian E Carpenter Subject: Re: Fixed font v multiple fonts X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no On Mon, 7 Jul 2003, todd glassey wrote: > Word is the most common word process in use on the planet today, so by > eliminating it you not only constrain the people that use it as their > primary text formatting tool, but essentially add another hurdle to the > everyman's participating in the IETF. Is it useful for "everyman" to participate in the IETF? Killing bad ideas is difficult enough already.. ;-) > Word's problem simply put is the template and the failing of the IETF to > create a reliable set of templates with Microsoft. But that was probably > intentional too - Is there a problem with RFC3285 (and possibly revised templates)? > ----- Original Message ----- > From: "Pekka Savola" > To: "Hallam-Baker, Phillip" > Cc: "'Melinda Shore'" ; ; > "Brian E Carpenter" > Sent: Monday, July 07, 2003 12:26 AM > Subject: RE: Fixed font v multiple fonts > > > > On Sun, 6 Jul 2003, Hallam-Baker, Phillip wrote: > > > Why do I have to waste my time fighting Word to make it produce > > > baddly formatted text that usually prints out wrong on the > > > printer anyway? > > > > It is out fault if you're using a word processor which is unoptimal for > > the task, or haven't looked at various templates for that particular word > > processor if you want to use it in any case? > > > > Some (most?) don't use Word for producing Internet Drafts, and are quite > > happy about it. No fighting is necessary. > > > > -- > > Pekka Savola "You each name yourselves king, yet the > > Netcore Oy kingdom bleeds." > > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From problem-statement-bounces@alvestrand.no Tue Jul 8 04:52:36 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14564 for ; Tue, 8 Jul 2003 04:52:35 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8A02D61B89; Tue, 8 Jul 2003 10:52:04 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [194.196.100.236]) by eikenes.alvestrand.no (Postfix) with ESMTP id D808461B88 for ; Tue, 8 Jul 2003 10:52:02 +0200 (CEST) Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by d12lmsgate-3.de.ibm.com (8.12.9/8.12.8) with ESMTP id h688posn076418; Tue, 8 Jul 2003 10:51:53 +0200 Received: from ochsehorn.zurich.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.5) with SMTP id h688pixv248740; Tue, 8 Jul 2003 10:51:44 +0200 Received: from gsine06.us.sine.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA27718 from ; Tue, 8 Jul 2003 10:51:41 +0200 Message-Id: <3F0A785A.DD4C267F@hursley.ibm.com> Date: Tue, 08 Jul 2003 09:52:58 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: spencer@mcsr-labs.org References: <410-220037171547515@M2W041.mail2web.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: MAJOR ISSUE: Causes of problems X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Indeed. This is exactly why I harp on about expanding the number of people trusted to perform peer review, over in solution space. The problem here is indeed that we have made the IESG into a bottleneck for peer review, with evident consequences for queueing times. Brian "spencer@mcsr-labs.org" wrote: > > Dear Dave, > > I think this falls in the same category as a group of people > who know what synchronization does to congestion, but > who continue to let all of the afternoon sessions out at the > same time the cookies arrive. > > We should know better, but... > > Spencer > > ----- Original Message ----- > From: "Dave Crocker" > To: "Bernard Aboba" > Cc: > Sent: Sunday, July 06, 2003 4:02 PM > Subject: Re: MAJOR ISSUE: Causes of "problems" > > > > > In general, we often seem to treat ourselves as having infinite > > resources. For a community well-versed in queuing theory, this is > > rather strange. > > -------------------------------------------------------------------- > mail2web - Check your email from the web at > http://mail2web.com/ . From problem-statement-bounces@alvestrand.no Tue Jul 8 09:34:55 2003 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21184 for ; Tue, 8 Jul 2003 09:34:54 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 77ED761B89; Tue, 8 Jul 2003 15:34:23 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5B9CE61AD5 for ; Tue, 8 Jul 2003 15:34:22 +0200 (CEST) Received: from mou1wnexc02.verisign.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.9/) with ESMTP id h68DYFch026285; Tue, 8 Jul 2003 06:34:16 -0700 (PDT) Received: by mou1wnexc02.verisign.com with Internet Mail Service (5.5.2653.19) id ; Tue, 8 Jul 2003 06:34:15 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E0D22ED@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'Pekka Savola'" , todd glassey Date: Tue, 8 Jul 2003 06:34:14 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Cc: "'Melinda Shore'" , problem-statement@alvestrand.no, "Hallam-Baker, Phillip" , Brian E Carpenter Subject: RE: Fixed font v multiple fonts X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no > Is it useful for "everyman" to participate in the IETF? If the current rate of people leaving continues pretty soon you are going to be saying yes. > Killing bad ideas is difficult enough already.. ;-) If there was a working decision procedure it would not be necessary for every bad idea to continue on forever. > Is there a problem with RFC3285 (and possibly revised templates)? Well it does not work on the MAC for starters as there is no generic print driver and going from the RFC format to Doc format is entirely manual. Is there any problem with RFC 2854, a format for which there is no shortage of editors of every type? The issue isn't the file format, the issue is who gets to choose. In the IETF it is a directive that comes from on high, you are going to do things our way, you get no choice, our way is best, the fact that you even suggest any other way makes you sound like a crank. Phill From problem-statement-bounces@alvestrand.no Tue Jul 8 09:57:34 2003 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21733 for ; Tue, 8 Jul 2003 09:57:33 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4687661B89; Tue, 8 Jul 2003 15:57:04 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from torntsims03.hsia.fairmont.com (smtp.hsia.fairmont.com [142.131.15.59]) by eikenes.alvestrand.no (Postfix) with ESMTP id 32C7A61B89 for ; Tue, 8 Jul 2003 15:57:02 +0200 (CEST) Received: from apocalypse.org (unverified [142.131.77.128]) by torntsims03.hsia.fairmont.com (Vircom SMTPRS 2.0.244) with ESMTP id for ; Tue, 8 Jul 2003 07:50:14 -0400 Date: Tue, 8 Jul 2003 07:54:09 -0400 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: avri To: problem-statement@alvestrand.no Content-Transfer-Encoding: quoted-printable In-Reply-To: <391303013.20030707163938@brandenburg.com> Message-Id: X-Mailer: Apple Mail (2.552) Subject: Re: Accomodating ESL speakers X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: quoted-printable On m=E5ndag, jul 7, 2003, at 10:39 Canada/Eastern, Dave Crocker wrote: > As a community of individuals, we are grotesquely insensitive to these > participants. We speak much too fast, and often in incomplete=20 > sentences. > We use idioms all the time. We get impatient when someone requests = that > we repeat ourselves. > > And then, of course, there is the dominant "American" style of > interactions, which can most kindly be described as wildly different > from what is normal in most other countries, especially for formal > situations like a standards meeting. > > i personally agree completely. having spent the last few years working=20= outside the US i found i was guilty of much of that. and still am to=20= some extent. our entire tirade against slideware - especially wordy slideware - is=20 part of that. before going to live outside the US, i would be happy=20 with slides that contained a picture or two. now i have learned that=20 if i want non-native english speakers to understand my presentation, i=20= should include lots of words explaining my point. something that is=20 somewhat frowned upon at the ietf. a. From problem-statement-bounces@alvestrand.no Tue Jul 8 09:59:34 2003 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21824 for ; Tue, 8 Jul 2003 09:59:33 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CD75B61B89; Tue, 8 Jul 2003 15:59:03 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from mtiwmhc11.worldnet.att.net (mtiwmhc11.worldnet.att.net [204.127.131.115]) by eikenes.alvestrand.no (Postfix) with ESMTP id 77D8261AD5 for ; Tue, 8 Jul 2003 15:59:02 +0200 (CEST) Received: from tsg1 (79.sanjose-08-09rs16rt.ca.dial-access.att.net[12.81.3.79]) by mtiwmhc11.worldnet.att.net (mtiwmhc11) with SMTP id <2003070813585511100n274te>; Tue, 8 Jul 2003 13:58:56 +0000 Message-ID: <00e001c34558$fbec1ea0$020aff0a@tsg1> From: "todd glassey" To: "Brian E Carpenter" , References: <410-220037171547515@M2W041.mail2web.com> <3F0A785A.DD4C267F@hursley.ibm.com> Date: Tue, 8 Jul 2003 06:52:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Cc: problem-statement@alvestrand.no Subject: Re: MAJOR ISSUE: Causes of problems X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit So Brian - wouldn't redefining the standard's workflow to be a mechanical process of "cafeteria style steps" be better. It certainly would alleviate the congestion since the IESG would have less peer review in their level. Todd ----- Original Message ----- From: "Brian E Carpenter" To: Cc: Sent: Tuesday, July 08, 2003 12:52 AM Subject: Re: MAJOR ISSUE: Causes of problems > Indeed. This is exactly why I harp on about expanding the > number of people trusted to perform peer review, over > in solution space. > > The problem here is indeed that we have made the IESG > into a bottleneck for peer review, with evident consequences > for queueing times. > > Brian > > "spencer@mcsr-labs.org" wrote: > > > > Dear Dave, > > > > I think this falls in the same category as a group of people > > who know what synchronization does to congestion, but > > who continue to let all of the afternoon sessions out at the > > same time the cookies arrive. > > > > We should know better, but... > > > > Spencer > > > > ----- Original Message ----- > > From: "Dave Crocker" > > To: "Bernard Aboba" > > Cc: > > Sent: Sunday, July 06, 2003 4:02 PM > > Subject: Re: MAJOR ISSUE: Causes of "problems" > > > > > > > > In general, we often seem to treat ourselves as having infinite > > > resources. For a community well-versed in queuing theory, this is > > > rather strange. > > > > -------------------------------------------------------------------- > > mail2web - Check your email from the web at > > http://mail2web.com/ . > From problem-statement-bounces@alvestrand.no Tue Jul 8 10:00:16 2003 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21977 for ; Tue, 8 Jul 2003 10:00:15 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8295061B8B; Tue, 8 Jul 2003 15:59:46 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from EXECDSL.COM (ns.execdsl.net [208.184.15.238]) by eikenes.alvestrand.no (Postfix) with ESMTP id 85F4861AD5 for ; Tue, 8 Jul 2003 15:59:44 +0200 (CEST) Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 5000242 for problem-statement@alvestrand.no; Tue, 08 Jul 2003 09:55:52 -0400 Message-Id: <5.1.0.14.0.20030708095100.0277b228@mail.stevecrocker.com> X-Sender: joel@stevecrocker.com@mail.stevecrocker.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 08 Jul 2003 09:54:44 -0400 To: problem-statement@alvestrand.no From: "Joel M. Halpern" In-Reply-To: <2A1D4C86842EE14CA9BC80474919782E0D22ED@mou1wnexm02.verisig n.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: RE: Fixed font v multiple fonts X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Phrased differently, it is quite clear that our decision process and not clear enough or strong enough. Many working group chairs find it difficult to deal with repeated raising of the same issue. The IETF list and plenary find it extremely difficult to avoid rediscussing the same topics. One part of this is that it is actually difficult for someone new to know what many of the decisions of a working group have been. Some of the problem tracking tools we are starting to use should help that. Additionally, there seems to be a tendency historically for vociferous individuals (and we have plenty of those) to keep pushing even when many folks think that an issue is settled. Sometimes this has even turned out to be a good thing. WHich of course makes it that much harder to craft rules preventing it... Yours, Joel M. Halpern At 06:34 AM 7/8/2003 -0700, Hallam-Baker, Phillip wrote: >If there was a working decision procedure it would not be necessary for >every bad idea to continue on forever. From problem-statement-bounces@alvestrand.no Tue Jul 8 10:08:03 2003 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22764 for ; Tue, 8 Jul 2003 10:08:03 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 35ECF61B8E; Tue, 8 Jul 2003 16:07:33 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from torntsims03.hsia.fairmont.com (smtp.hsia.fairmont.com [142.131.15.59]) by eikenes.alvestrand.no (Postfix) with ESMTP id C22E961B8D for ; Tue, 8 Jul 2003 16:07:31 +0200 (CEST) Received: from apocalypse.org (unverified [142.131.77.128]) by torntsims03.hsia.fairmont.com (Vircom SMTPRS 2.0.244) with ESMTP id for ; Tue, 8 Jul 2003 08:00:05 -0400 Date: Tue, 8 Jul 2003 08:03:58 -0400 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: avri To: problem-statement@alvestrand.no Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <4182A739-B13C-11D7-A876-000393CC2112@apocalypse.org> X-Mailer: Apple Mail (2.552) Subject: Re: Fixed font v multiple fonts X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit On tisdag, jul 8, 2003, at 03:24 Canada/Eastern, Pekka Savola wrote: > On Mon, 7 Jul 2003, todd glassey wrote: >> Word is the most common word process in use on the planet today, so by >> eliminating it you not only constrain the people that use it as their >> primary text formatting tool, but essentially add another hurdle to >> the >> everyman's participating in the IETF. > > Is it useful for "everyman" to participate in the IETF? > > Killing bad ideas is difficult enough already.. ;-) > i personally do not wish to support the use of word at all, and i believe one does not need word to produce ids. i do support the notion that everyone should be enabled to participate, including those who have barely moved over the digital divide. so i think a fair number of considerations must be discussed in any attempt to change formats. a. From problem-statement-bounces@alvestrand.no Tue Jul 8 10:08:21 2003 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22831 for ; Tue, 8 Jul 2003 10:08:20 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BB41A61B93; Tue, 8 Jul 2003 16:07:51 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by eikenes.alvestrand.no (Postfix) with ESMTP id D0A8761B92 for ; Tue, 8 Jul 2003 16:07:50 +0200 (CEST) Received: from tsg1 (79.sanjose-08-09rs16rt.ca.dial-access.att.net[12.81.3.79]) by mtiwmhc12.worldnet.att.net (mtiwmhc12) with SMTP id <2003070814070711200k06a7e>; Tue, 8 Jul 2003 14:07:08 +0000 Message-ID: <00e701c3455a$21022df0$020aff0a@tsg1> From: "todd glassey" To: "avri" , References: Date: Tue, 8 Jul 2003 07:06:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: Re: Accomodating ESL speakers X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 8bit Avri - the problem is with creating a homogeneous set of Intellectual Properties that can all be evaluated equally as a standard, and the issues of opening that to multiple languages complicates the matter terribly. I do understand that the largest part of the world speaks something other than English, but it (English) has been the mainstay of the IETF's and the Internet Standards disclosure models from day one. To bring into that any other languages complicates the qualifying of standards tremendously since then the Editors MUST be fluent in those languages from a technical sense so that they can see for instance, how a French or Hebrew update tracks the original English printing on RFCXXXX for instance, and that will clearly increase the complexity and cost of processing standards as well as slow the publishing process down tremendously, oh and it also opens the Editors to commercial liabilities for any screwups therein. I would because of these simple facts propose that for now, that English remain the official filing language until such time as the IESG can formally afford or get interpretive services as part of its operations model. Todd Glassey ----- Original Message ----- From: "avri" To: Sent: Tuesday, July 08, 2003 4:54 AM Subject: Re: Accomodating ESL speakers On måndag, jul 7, 2003, at 10:39 Canada/Eastern, Dave Crocker wrote: > As a community of individuals, we are grotesquely insensitive to these > participants. We speak much too fast, and often in incomplete > sentences. > We use idioms all the time. We get impatient when someone requests that > we repeat ourselves. > > And then, of course, there is the dominant "American" style of > interactions, which can most kindly be described as wildly different > from what is normal in most other countries, especially for formal > situations like a standards meeting. > > i personally agree completely. having spent the last few years working outside the US i found i was guilty of much of that. and still am to some extent. our entire tirade against slideware - especially wordy slideware - is part of that. before going to live outside the US, i would be happy with slides that contained a picture or two. now i have learned that if i want non-native english speakers to understand my presentation, i should include lots of words explaining my point. something that is somewhat frowned upon at the ietf. a. From problem-statement-bounces@alvestrand.no Tue Jul 8 12:54:35 2003 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00480 for ; Tue, 8 Jul 2003 12:54:34 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 252FC61B8E; Tue, 8 Jul 2003 18:54:07 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8D78F61B8B for ; Tue, 8 Jul 2003 18:54:05 +0200 (CEST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id C5D046A902; Tue, 8 Jul 2003 17:48:54 +0300 (EEST) Message-ID: <3F0AD941.8030507@piuha.net> Date: Tue, 08 Jul 2003 17:46:25 +0300 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: todd glassey References: <00e701c3455a$21022df0$020aff0a@tsg1> In-Reply-To: <00e701c3455a$21022df0$020aff0a@tsg1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no, avri Subject: Re: Accomodating ESL speakers X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list Reply-To: jari.arkko@piuha.net List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit todd glassey wrote: > To bring into that any other languages complicates the qualifying of > standards tremendously since then the Editors MUST be fluent in those > languages from a technical sense so that they can see for instance, how a > French or Hebrew update tracks the original English printing on RFCXXXX for > instance, and that will clearly increase the complexity and cost of > processing standards as well as slow the publishing process down Todd, I don't think anyone suggested that the IETF switch to multiple languages. That would be a bad move, IMHO. The point was that even when staying with English, different meeting styles can make it harder or easier for ESL folks to participate. Personally, I'd say the IETF is doing pretty well in this regard compared to many other standardization forums; we do a lot of our work in the mailing lists where everything is written down, you can take your time to work through the text etc. However, in the meetings the situation is not as easy as that. The aggressive style, the quick pace (typically we have just 6 hours of f2f time per *year* per group). It makes a big difference who is speaking, too. Some folks should just slow down; I know cases where the discussion partners of an important discussion in some WG simply could not decipher what the fast speaking partner was saying. And of course, the worst case scenario is an ESL speaker (original language X) speaks incomprehensible English and another ESL person (original language Y) tries to understand ;-) --Jari From problem-statement-bounces@alvestrand.no Tue Jul 8 15:08:05 2003 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05450 for ; Tue, 8 Jul 2003 15:08:03 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3556561B8E; Tue, 8 Jul 2003 21:07:34 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from thunker.thunk.org (thunk.org [140.239.227.29]) by eikenes.alvestrand.no (Postfix) with ESMTP id C71B961B8D for ; Tue, 8 Jul 2003 21:07:32 +0200 (CEST) Received: from [32.97.110.142] (helo=think.thunk.org) authenticated as tytso by thunker.thunk.org with asmtp (tls_cipher TLSv1:DES-CBC3-SHA:168) (Exim 3.35 #1 (Debian)) id 19Zxnt-0003p7-00; Tue, 08 Jul 2003 15:07:06 -0400 Received: from tytso authenticated as tytso by think.thunk.org with local (Exim 3.35 #1 (Debian)) id 19ZxnM-0000rb-00; Tue, 08 Jul 2003 15:06:32 -0400 Date: Tue, 8 Jul 2003 15:06:31 -0400 From: "Theodore Ts'o" To: Jari Arkko Message-ID: <20030708190631.GD1673@think> References: <00e701c3455a$21022df0$020aff0a@tsg1> <3F0AD941.8030507@piuha.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F0AD941.8030507@piuha.net> User-Agent: Mutt/1.5.4i Cc: avri , problem-statement@alvestrand.no Subject: Re: Accomodating ESL speakers X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no On Tue, Jul 08, 2003 at 05:46:25PM +0300, Jari Arkko wrote: > > And of course, the worst case scenario is an ESL speaker > (original language X) speaks incomprehensible English > and another ESL person (original language Y) tries to > understand ;-) > It's a problem when some really smart people try to talk as fast as possible to keep up with their thoughts. The problem isn't necessarily limited to native english speakers, too. I've sometimes really had problems trying to follow an ESL speaker who spoke English with a very heavy accent, but who was also speaking very quickly, and on a technically deep enough topic that trying to decipher his accent as well as keep up with his train of thought was a very large challenge. - Ted From problem-statement-bounces@alvestrand.no Tue Jul 8 17:14:25 2003 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10840 for ; Tue, 8 Jul 2003 17:14:24 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 20DFA61B8E; Tue, 8 Jul 2003 23:13:55 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by eikenes.alvestrand.no (Postfix) with ESMTP id BCB5961B8D for ; Tue, 8 Jul 2003 23:13:52 +0200 (CEST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h68LCTN02504; Tue, 8 Jul 2003 17:12:30 -0400 (EDT) Date: Tue, 8 Jul 2003 17:12:28 -0400 From: Keith Moore To: "Hallam-Baker, Phillip" Message-Id: <20030708171228.1d01f1dd.moore@cs.utk.edu> In-Reply-To: <2A1D4C86842EE14CA9BC80474919782E0D22DF@mou1wnexm02.verisign.com> References: <2A1D4C86842EE14CA9BC80474919782E0D22DF@mou1wnexm02.verisign.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: pbaker@verisign.com, moore@cs.utk.edu, brian@hursley.ibm.com, problem-statement@alvestrand.no Subject: Re: Fixed font v multiple fonts X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit > From my point of view it is almost impossible to accurately compare a > cryptographic algorithm described in the litterature with the alleged > same algorithm in an IETF RFC. last I knew it was still possible to publish RFCs in PostScript, or perhaps even PDF, as an alternate to the ASCII version. I've even had reasonable luck with producing I-Ds in multiple formats from the same revisable source. it might take a bit of special handling by the RFC editor but the case you cite seems like adequate justification. From problem-statement-bounces@alvestrand.no Tue Jul 8 17:19:11 2003 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10969 for ; Tue, 8 Jul 2003 17:19:10 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B6B0061B8E; Tue, 8 Jul 2003 23:18:41 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by eikenes.alvestrand.no (Postfix) with ESMTP id ED2C461B8D for ; Tue, 8 Jul 2003 23:18:39 +0200 (CEST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h68LHJN02836; Tue, 8 Jul 2003 17:17:19 -0400 (EDT) Date: Tue, 8 Jul 2003 17:17:18 -0400 From: Keith Moore To: "Steve Silverman" Message-Id: <20030708171718.7cfdb719.moore@cs.utk.edu> In-Reply-To: References: <2A1D4C86842EE14CA9BC80474919782E0D22DF@mou1wnexm02.verisign.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: pbaker@verisign.com, moore@cs.utk.edu, problem-statement@alvestrand.no Subject: lack of democratic decision-making X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit > o The lack of a formal democratic (or quasi-democratic) > decision-making process. Technical quality, fairness, expedience are all valid goals, probably in that order. I don't view democracy as a valid goal, nor the absence of democracy as a problem. That's why we don't make decisions by voting. Keith From problem-statement-bounces@alvestrand.no Tue Jul 8 22:05:20 2003 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19080 for ; Tue, 8 Jul 2003 22:05:19 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B9ABB61B95; Wed, 9 Jul 2003 04:04:46 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by eikenes.alvestrand.no (Postfix) with ESMTP id D565661B96 for ; Wed, 9 Jul 2003 04:04:28 +0200 (CEST) Received: from tsg1 (unknown[12.81.13.198]) by mtiwmhc12.worldnet.att.net (mtiwmhc12) with SMTP id <20030709020350112004cgpke>; Wed, 9 Jul 2003 02:03:50 +0000 Message-ID: <018c01c345be$3dab5fd0$020aff0a@tsg1> From: "todd glassey" To: "avri" , References: <4182A739-B13C-11D7-A876-000393CC2112@apocalypse.org> Date: Tue, 8 Jul 2003 19:01:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: Re: Fixed font v multiple fonts X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Hmmm... ----- Original Message ----- From: "avri" To: Sent: Tuesday, July 08, 2003 5:03 AM Subject: Re: Fixed font v multiple fonts > > On tisdag, jul 8, 2003, at 03:24 Canada/Eastern, Pekka Savola wrote: > > > On Mon, 7 Jul 2003, todd glassey wrote: > >> Word is the most common word process in use on the planet today, so by > >> eliminating it you not only constrain the people that use it as their > >> primary text formatting tool, but essentially add another hurdle to > >> the > >> everyman's participating in the IETF. > > > > Is it useful for "everyman" to participate in the IETF? It is mandatory, not "useful". > > > > Killing bad ideas is difficult enough already.. ;-) > > > > i personally do not wish to support the use of word at all, > and i believe one does not need word to produce ids. > > i do support the notion that everyone should be enabled to > participate, including those who have barely moved over the > digital divide. so i think a fair number of considerations must be > discussed in any attempt to change formats. > > a. > From problem-statement-bounces@alvestrand.no Tue Jul 8 22:05:22 2003 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19095 for ; Tue, 8 Jul 2003 22:05:21 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 04E1861B9A; Wed, 9 Jul 2003 04:04:49 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by eikenes.alvestrand.no (Postfix) with ESMTP id DD19561B95 for ; Wed, 9 Jul 2003 04:04:26 +0200 (CEST) Received: from tsg1 (unknown[12.81.13.198]) by mtiwmhc12.worldnet.att.net (mtiwmhc12) with SMTP id <20030709020345112004cgpie>; Wed, 9 Jul 2003 02:03:46 +0000 Message-ID: <018a01c345be$3b5a6af0$020aff0a@tsg1> From: "todd glassey" To: "Theodore Ts'o" , "Jari Arkko" References: <00e701c3455a$21022df0$020aff0a@tsg1> <3F0AD941.8030507@piuha.net> <20030708190631.GD1673@think> Date: Tue, 8 Jul 2003 18:48:58 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Cc: problem-statement@alvestrand.no, avri Subject: Re: Accomodating ESL speakers X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit The issue then is how to apply Note Well to that since it is all about how the vocal incantations or declarations are snapped up. Todd ----- Original Message ----- From: "Theodore Ts'o" To: "Jari Arkko" Cc: "todd glassey" ; ; "avri" Sent: Tuesday, July 08, 2003 12:06 PM Subject: Re: Accomodating ESL speakers > On Tue, Jul 08, 2003 at 05:46:25PM +0300, Jari Arkko wrote: > > > > And of course, the worst case scenario is an ESL speaker > > (original language X) speaks incomprehensible English > > and another ESL person (original language Y) tries to > > understand ;-) > > > > It's a problem when some really smart people try to talk as fast as > possible to keep up with their thoughts. The problem isn't > necessarily limited to native english speakers, too. I've sometimes > really had problems trying to follow an ESL speaker who spoke English > with a very heavy accent, but who was also speaking very quickly, and > on a technically deep enough topic that trying to decipher his accent > as well as keep up with his train of thought was a very large challenge. > > - Ted From problem-statement-bounces@alvestrand.no Tue Jul 8 22:08:52 2003 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19147 for ; Tue, 8 Jul 2003 22:08:52 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 141CD61B96; Wed, 9 Jul 2003 04:08:23 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from mtiwmhc11.worldnet.att.net (mtiwmhc11.worldnet.att.net [204.127.131.115]) by eikenes.alvestrand.no (Postfix) with ESMTP id 137CF61B95 for ; Wed, 9 Jul 2003 04:08:21 +0200 (CEST) Received: from tsg1 (unknown[12.81.13.198]) by mtiwmhc11.worldnet.att.net (mtiwmhc11) with SMTP id <20030709020817111002c3dse>; Wed, 9 Jul 2003 02:08:19 +0000 Message-ID: <01ed01c345be$dda3d3f0$020aff0a@tsg1> From: "todd glassey" To: "Keith Moore" , "Hallam-Baker, Phillip" References: <2A1D4C86842EE14CA9BC80474919782E0D22DF@mou1wnexm02.verisign.com> <20030708171228.1d01f1dd.moore@cs.utk.edu> Date: Tue, 8 Jul 2003 19:07:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Cc: Keith Moore , "Hallam-Baker, Phillip" , Brian E Carpenter , problem-statement@alvestrand.no Subject: Re: Fixed font v multiple fonts X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit My understanding is that PDF Documents require a Text Submittal as well. As does PS. Todd ----- Original Message ----- From: "Keith Moore" To: "Hallam-Baker, Phillip" Cc: ; ; ; Sent: Tuesday, July 08, 2003 2:12 PM Subject: Re: Fixed font v multiple fonts > > From my point of view it is almost impossible to accurately compare a > > cryptographic algorithm described in the litterature with the alleged > > same algorithm in an IETF RFC. > > last I knew it was still possible to publish RFCs in PostScript, or > perhaps even PDF, as an alternate to the ASCII version. I've even had > reasonable luck with producing I-Ds in multiple formats from the same > revisable source. it might take a bit of special handling by the RFC > editor but the case you cite seems like adequate justification. > From problem-statement-bounces@alvestrand.no Wed Jul 9 08:57:42 2003 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29256 for ; Wed, 9 Jul 2003 08:57:41 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 041C861B9C; Wed, 9 Jul 2003 14:57:11 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9350961B9B for ; Wed, 9 Jul 2003 14:57:08 +0200 (CEST) Received: from mou1wnexc01.verisign.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.9/) with ESMTP id h69Cv62Q021983; Wed, 9 Jul 2003 05:57:06 -0700 (PDT) Received: by mou1wnexc01.verisign.com with Internet Mail Service (5.5.2653.19) id ; Wed, 9 Jul 2003 05:57:06 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E0D22F1@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'todd glassey'" , Keith Moore , "Hallam-Baker, Phillip" Date: Wed, 9 Jul 2003 05:57:03 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Cc: Keith Moore , "Hallam-Baker, Phillip" , Brian E Carpenter , problem-statement@alvestrand.no Subject: RE: Fixed font v multiple fonts X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no It is also the case that postscript is the only alternative actually sanctioned. If the rules were interpreted strictly PDF would also be barred. If postscript, why not HTML? Postscript is a completely proprietary format that is subject to arbitrary change by a single vendor. It is also an output only format. With HTML, or any XML markup I can specify the semantic purpose of a chunk of text:

Put ASN.1 schema here...

Phill > -----Original Message----- > From: todd glassey [mailto:todd.glassey@worldnet.att.net] > Sent: Tuesday, July 08, 2003 10:07 PM > To: Keith Moore; Hallam-Baker, Phillip > Cc: Hallam-Baker, Phillip; Keith Moore; Brian E Carpenter; > problem-statement@alvestrand.no > Subject: Re: Fixed font v multiple fonts > > > My understanding is that PDF Documents require a Text > Submittal as well. As > does PS. > > Todd > ----- Original Message ----- > From: "Keith Moore" > To: "Hallam-Baker, Phillip" > Cc: ; ; > ; > > Sent: Tuesday, July 08, 2003 2:12 PM > Subject: Re: Fixed font v multiple fonts > > > > > From my point of view it is almost impossible to > accurately compare a > > > cryptographic algorithm described in the litterature with > the alleged > > > same algorithm in an IETF RFC. > > > > last I knew it was still possible to publish RFCs in PostScript, or > > perhaps even PDF, as an alternate to the ASCII version. > I've even had > > reasonable luck with producing I-Ds in multiple formats > from the same > > revisable source. it might take a bit of special handling > by the RFC > > editor but the case you cite seems like adequate justification. > > > From problem-statement-bounces@alvestrand.no Wed Jul 9 10:12:36 2003 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02074 for ; Wed, 9 Jul 2003 10:12:35 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 74F7861B9D; Wed, 9 Jul 2003 16:12:05 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from mallard.mail.pas.earthlink.net (mallard.mail.pas.earthlink.net [207.217.120.48]) by eikenes.alvestrand.no (Postfix) with ESMTP id 01FAE61B9C for ; Wed, 9 Jul 2003 16:12:04 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by mallard.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19aFfo-0006vo-00; Wed, 09 Jul 2003 07:11:56 -0700 Date: Wed, 9 Jul 2003 10:09:41 -0400 From: Keith Moore To: "Hallam-Baker, Phillip" Message-Id: <20030709100941.2377a39e.moore@cs.utk.edu> In-Reply-To: <2A1D4C86842EE14CA9BC80474919782E0D22F1@mou1wnexm02.verisign.com> References: <2A1D4C86842EE14CA9BC80474919782E0D22F1@mou1wnexm02.verisign.com> X-Mailer: Sylpheed version 0.9.1 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no, moore@cs.utk.edu Subject: Re: Fixed font v multiple fonts X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit On Wed, 9 Jul 2003 05:57:03 -0700 "Hallam-Baker, Phillip" wrote: ] It is also the case that postscript is the only alternative actually ] sanctioned. If the rules were interpreted strictly PDF would also be barred. ] ] If postscript, why not HTML? Postscript is a completely proprietary format ] that is subject to arbitrary change by a single vendor. It is also an output ] only format. since I don't think this is a 'problem' and therefore not within the charter of this group, I suggest that this a topic best discussed in private mail. Keith From problem-statement-bounces@alvestrand.no Wed Jul 9 10:30:58 2003 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02881 for ; Wed, 9 Jul 2003 10:30:46 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 148BD61B9C; Wed, 9 Jul 2003 16:30:11 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by eikenes.alvestrand.no (Postfix) with ESMTP id CC50061B9B for ; Wed, 9 Jul 2003 16:30:08 +0200 (CEST) Received: from mou1wnexc02.verisign.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.9/) with ESMTP id h69EU7ch021138; Wed, 9 Jul 2003 07:30:07 -0700 (PDT) Received: by mou1wnexc02.verisign.com with Internet Mail Service (5.5.2653.19) id ; Wed, 9 Jul 2003 07:30:07 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E0D22F3@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'Keith Moore'" , "Hallam-Baker, Phillip" Date: Wed, 9 Jul 2003 07:30:07 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Cc: problem-statement@alvestrand.no Subject: RE: Fixed font v multiple fonts X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Failure to use sound engineering principles is in the charter. Requiring all communication to take place through a medium that does not support graphs, mathematical notations, schematics, drawings or even italics is one of the main reasons that use of modern engineering methods is impossible in the IETF. Phill > -----Original Message----- > From: Keith Moore [mailto:moore@cs.utk.edu] > Sent: Wednesday, July 09, 2003 10:10 AM > To: Hallam-Baker, Phillip > Cc: moore@cs.utk.edu; problem-statement@alvestrand.no > Subject: Re: Fixed font v multiple fonts > > > On Wed, 9 Jul 2003 05:57:03 -0700 > "Hallam-Baker, Phillip" wrote: > > ] It is also the case that postscript is the only alternative actually > ] sanctioned. If the rules were interpreted strictly PDF > would also be barred. > ] > ] If postscript, why not HTML? Postscript is a completely > proprietary format > ] that is subject to arbitrary change by a single vendor. It > is also an output > ] only format. > > since I don't think this is a 'problem' and therefore not > within the charter > of this group, I suggest that this a topic best discussed in > private mail. > > Keith > From problem-statement-bounces@alvestrand.no Wed Jul 9 10:32:21 2003 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02975 for ; Wed, 9 Jul 2003 10:32:18 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BC7E161B9F; Wed, 9 Jul 2003 16:31:44 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from pintail.mail.pas.earthlink.net (pintail.mail.pas.earthlink.net [207.217.120.122]) by eikenes.alvestrand.no (Postfix) with ESMTP id EC34761B9D for ; Wed, 9 Jul 2003 16:31:42 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by pintail.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19aFyn-0000Rs-00; Wed, 09 Jul 2003 07:31:33 -0700 Date: Wed, 9 Jul 2003 10:29:17 -0400 From: Keith Moore To: "Hallam-Baker, Phillip" Message-Id: <20030709102917.48ac58f4.moore@cs.utk.edu> In-Reply-To: <2A1D4C86842EE14CA9BC80474919782E0D22F3@mou1wnexm02.verisign.com> References: <2A1D4C86842EE14CA9BC80474919782E0D22F3@mou1wnexm02.verisign.com> X-Mailer: Sylpheed version 0.9.1 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: pbaker@verisign.com, moore@cs.utk.edu, problem-statement@alvestrand.no Subject: Re: Fixed font v multiple fonts X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit On Wed, 9 Jul 2003 07:30:07 -0700 "Hallam-Baker, Phillip" wrote: ] Requiring all communication to take place through a medium that does not ] support graphs, mathematical notations, schematics, drawings or even italics ] is one of the main reasons that use of modern engineering methods is ] impossible in the IETF. but this is not required. so your premise is false. we have enough real problems without having to tackle non-problems. From problem-statement-bounces@alvestrand.no Wed Jul 9 10:45:08 2003 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03288 for ; Wed, 9 Jul 2003 10:45:07 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1B89C61BA0; Wed, 9 Jul 2003 16:44:38 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4285161B9F for ; Wed, 9 Jul 2003 16:44:36 +0200 (CEST) Received: from mou1wnexc01.verisign.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.9/) with ESMTP id h69EiZ2Q012770; Wed, 9 Jul 2003 07:44:35 -0700 (PDT) Received: by mou1wnexc01.verisign.com with Internet Mail Service (5.5.2653.19) id ; Wed, 9 Jul 2003 07:44:35 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E0D22F4@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'Keith Moore'" , "Hallam-Baker, Phillip" Date: Wed, 9 Jul 2003 07:44:35 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Cc: problem-statement@alvestrand.no, "Hallam-Baker, Phillip" Subject: RE: Fixed font v multiple fonts X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Modern engineering methods not required? I regard that statement as a real problem. Phill > -----Original Message----- > From: Keith Moore [mailto:moore@cs.utk.edu] > Sent: Wednesday, July 09, 2003 10:29 AM > To: Hallam-Baker, Phillip > Cc: moore@cs.utk.edu; pbaker@verisign.com; > problem-statement@alvestrand.no > Subject: Re: Fixed font v multiple fonts > > > On Wed, 9 Jul 2003 07:30:07 -0700 > "Hallam-Baker, Phillip" wrote: > > ] Requiring all communication to take place through a medium > that does not > ] support graphs, mathematical notations, schematics, > drawings or even italics > ] is one of the main reasons that use of modern engineering methods is > ] impossible in the IETF. > > but this is not required. so your premise is false. > > we have enough real problems without having to tackle non-problems. > From problem-statement-bounces@alvestrand.no Wed Jul 9 12:55:36 2003 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09762 for ; Wed, 9 Jul 2003 12:55:35 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 48C1361B9E; Wed, 9 Jul 2003 18:55:06 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by eikenes.alvestrand.no (Postfix) with ESMTP id 658CE61B9D for ; Wed, 9 Jul 2003 18:55:04 +0200 (CEST) Received: from tsg1 (unknown[12.81.13.198]) by mtiwmhc12.worldnet.att.net (mtiwmhc12) with SMTP id <20030709165456112004erlve>; Wed, 9 Jul 2003 16:54:57 +0000 Message-ID: <02a901c3463a$b70dac80$020aff0a@tsg1> From: "todd glassey" To: "Hallam-Baker, Phillip" , "Keith Moore" References: <2A1D4C86842EE14CA9BC80474919782E0D22F1@mou1wnexm02.verisign.com> Date: Wed, 9 Jul 2003 06:17:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Cc: problem-statement@alvestrand.no, Keith Moore , Brian E Carpenter Subject: Re: Fixed font v multiple fonts X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit I agree with Phillip 100%. The IETF needs to open submittals to more than just ASCII Text. I also would like to see some method of accepting digital signatures as well as part of an identity verification program (even if its not mandatory)... Todd ----- Original Message ----- From: "Hallam-Baker, Phillip" To: "'todd glassey'" ; "Keith Moore" ; "Hallam-Baker, Phillip" Cc: "Hallam-Baker, Phillip" ; "Keith Moore" ; "Brian E Carpenter" ; Sent: Wednesday, July 09, 2003 5:57 AM Subject: RE: Fixed font v multiple fonts > It is also the case that postscript is the only alternative actually > sanctioned. If the rules were interpreted strictly PDF would also be barred. > > If postscript, why not HTML? Postscript is a completely proprietary format > that is subject to arbitrary change by a single vendor. It is also an output > only format. > > > With HTML, or any XML markup I can specify the semantic purpose of a chunk > of text: > >

> Put ASN.1 schema here... >

> > > Phill > > > -----Original Message----- > > From: todd glassey [mailto:todd.glassey@worldnet.att.net] > > Sent: Tuesday, July 08, 2003 10:07 PM > > To: Keith Moore; Hallam-Baker, Phillip > > Cc: Hallam-Baker, Phillip; Keith Moore; Brian E Carpenter; > > problem-statement@alvestrand.no > > Subject: Re: Fixed font v multiple fonts > > > > > > My understanding is that PDF Documents require a Text > > Submittal as well. As > > does PS. > > > > Todd > > ----- Original Message ----- > > From: "Keith Moore" > > To: "Hallam-Baker, Phillip" > > Cc: ; ; > > ; > > > > Sent: Tuesday, July 08, 2003 2:12 PM > > Subject: Re: Fixed font v multiple fonts > > > > > > > > From my point of view it is almost impossible to > > accurately compare a > > > > cryptographic algorithm described in the litterature with > > the alleged > > > > same algorithm in an IETF RFC. > > > > > > last I knew it was still possible to publish RFCs in PostScript, or > > > perhaps even PDF, as an alternate to the ASCII version. > > I've even had > > > reasonable luck with producing I-Ds in multiple formats > > from the same > > > revisable source. it might take a bit of special handling > > by the RFC > > > editor but the case you cite seems like adequate justification. > > > > > From problem-statement-bounces@alvestrand.no Thu Jul 10 07:48:21 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27692 for ; Thu, 10 Jul 2003 07:48:20 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 048A261BAD; Thu, 10 Jul 2003 13:47:51 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from sentosa.post1.com (sentosa.post1.com [202.27.17.100]) by eikenes.alvestrand.no (Postfix) with SMTP id 598776256B for ; Mon, 7 Jul 2003 08:12:47 +0200 (CEST) Received: (qmail 43489 invoked from network); 7 Jul 2003 06:18:39 -0000 Received: from ida120.ida.gov.sg (HELO pobox.org.sg) (210.24.194.120) by sentosa.post1.com with SMTP; 7 Jul 2003 06:18:39 -0000 Message-ID: <3F090F6A.4050504@pobox.org.sg> Date: Mon, 07 Jul 2003 14:12:58 +0800 From: James Seng User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en, zh-cn, zh-tw, ja, ko MIME-Version: 1.0 To: "Hallam-Baker, Phillip" References: <2A1D4C86842EE14CA9BC80474919782E0D22D8@mou1wnexm02.verisign.com> In-Reply-To: <2A1D4C86842EE14CA9BC80474919782E0D22D8@mou1wnexm02.verisign.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 10 Jul 2003 13:47:50 +0200 Subject: Re: ADs who are also WG chairs X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit You reach this conclusion from..erm 1 wg out of 100+ wgs in IETF? Assuming it is indeed a failure (and you have not convience me that there is a process failure in DNSEXT), you cannot extend one example to all other wgs. Sorry, your story dont sell. -James Seng Hallam-Baker, Phillip wrote: >>Once again, 'democratic' is not one of our core principle, AFAIK. >>Running code & rough consensus is the IETF core principle. > > > No, the core principle is top down organization, control by the few. > > Consensus or running code did not enter into the DNSEXT OPTIN > process. > > If the IESG has any value it will refuse the DNSSEC specs as > broken of its own accord. Instead however it will be too timid > to challenge Randy. > > What "consensus" means is people are too frightened to rock the > boat lest their behavior cause someone who is obstructionist > and determined to get their own way start blocking your projects > in retaliation. > > Phill > > From problem-statement-bounces@alvestrand.no Thu Jul 10 07:48:25 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27712 for ; Thu, 10 Jul 2003 07:48:24 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 964AF61BB1; Thu, 10 Jul 2003 13:47:51 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by eikenes.alvestrand.no (Postfix) with ESMTP id 63DF961B9D for ; Wed, 9 Jul 2003 21:57:39 +0200 (CEST) Received: from dfnjgl21 (12-237-229-250.client.attbi.com[12.237.229.250](untrusted sender)) by comcast.net (rwcrmhc12) with SMTP id <20030709195730014007v7e6e> (Authid: j.pathak@comcast.net); Wed, 9 Jul 2003 19:57:30 +0000 Message-ID: <021301c34654$55e760d0$0200a8c0@DFNJGL21> From: "Spencer Dawkins" To: References: <2A1D4C86842EE14CA9BC80474919782E0D22F1@mou1wnexm02.verisign.com> <02a901c3463a$b70dac80$020aff0a@tsg1> Date: Wed, 9 Jul 2003 14:57:29 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailman-Approved-At: Thu, 10 Jul 2003 13:47:50 +0200 Subject: Re: Fixed font v multiple fonts X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list Reply-To: Spencer Dawkins List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Could someone who feels passionate about this issue please send text? because problems that don't get into the problem-statement draft aren't going to change much as a result of anything this WG does... Spencer ----- Original Message ----- From: "todd glassey" To: "Hallam-Baker, Phillip" ; "Keith Moore" Cc: ; "Keith Moore" ; "Brian E Carpenter" Sent: Wednesday, July 09, 2003 8:17 AM Subject: Re: Fixed font v multiple fonts > I agree with Phillip 100%. The IETF needs to open submittals to more than > just ASCII Text. I also would like to see some method of accepting digital > signatures as well as part of an identity verification program (even if its > not mandatory)... > > Todd From problem-statement-bounces@alvestrand.no Thu Jul 10 07:48:28 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27731 for ; Thu, 10 Jul 2003 07:48:27 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7FB5561BB5; Thu, 10 Jul 2003 13:47:52 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from albatross.tn.sw.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by eikenes.alvestrand.no (Postfix) with ESMTP id A556361B9B for ; Thu, 10 Jul 2003 13:25:17 +0200 (CEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h6ABPHIi003223; Thu, 10 Jul 2003 13:25:17 +0200 (MEST) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 10 Jul 2003 13:25:17 +0200 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: Keith Moore , "Hallam-Baker, Phillip" Date: Thu, 10 Jul 2003 13:25:15 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-Mailman-Approved-At: Thu, 10 Jul 2003 13:47:50 +0200 Cc: problem-statement@alvestrand.no Subject: RE: Fixed font v multiple fonts X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no I totally agree with Keith here, this is not a subject for this WG. Regarding the RFC document format, the RFC ASCII format is in my opinion outstanding, compared to the complicated formatting rules used by other organizations where you waste lots of time just on getting the document format right. /L-E > -----Original Message----- > From: Keith Moore [mailto:moore@cs.utk.edu] > Sent: den 9 juli 2003 16:29 > To: Hallam-Baker, Phillip > Cc: pbaker@verisign.com; moore@cs.utk.edu; > problem-statement@alvestrand.no > Subject: Re: Fixed font v multiple fonts > > > On Wed, 9 Jul 2003 07:30:07 -0700 > "Hallam-Baker, Phillip" wrote: > > ] Requiring all communication to take place through a medium > that does not > ] support graphs, mathematical notations, schematics, > drawings or even italics > ] is one of the main reasons that use of modern engineering methods is > ] impossible in the IETF. > > but this is not required. so your premise is false. > > we have enough real problems without having to tackle non-problems. > From problem-statement-bounces@alvestrand.no Thu Jul 10 08:11:08 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28358 for ; Thu, 10 Jul 2003 08:11:07 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BCB1B61BAE; Thu, 10 Jul 2003 14:10:38 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4737761B9B for ; Thu, 10 Jul 2003 14:10:37 +0200 (CEST) Received: from BBFUJIP.brandenburg.com (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h6ACDiF10662; Thu, 10 Jul 2003 05:13:46 -0700 Date: Wed, 9 Jul 2003 22:07:48 +0200 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/11) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <67103775571.20030709220748@brandenburg.com> To: hardie@qualcomm.com In-Reply-To: References: <120210000.1055072340@askvoll.hjemme.alvestrand.no> <481518433.20030608091336@brandenburg.com> <125670000.1055090084@askvoll.hjemme.alvestrand.no> <721113479.20030608173246@brandenburg.com> <148310000.1055147276@askvoll.hjemme.alvestrand.no> <1101423707.20030706085955@brandenburg.com> <552230000.1057554700@askvoll.hjemme.alvestrand.no> <1012748672.20030707170343@brandenburg.com> MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: ISSUE: Determinants for timeliness missing in section 2.1 X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list Reply-To: Dave Crocker List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Ted, Light is great. Excellent idea... hqc> of the situation may require public discussion, but I think the main problem hqc> for this list has already been raised: hqc> It is difficult to manage dependencies between groups and hqc> the result of creating those dependencies may be that hqc> the output of a group is slower than it would be without that hqc> dependency or set of dependencies. My original note focused on a particular kind of delay. XMPP was merely cited as an example. The focus was on XMPP, not IMPP. Deferring debate about IMPP is certainly fine with me, since it was not something I was raising. However, with all due respect, I must observe that your summary does not cover the point I was/am making.. My point was about a certain *kind* of delay, and a certain *aspect* of purported coordination. The difference between that point and your summary is significant. The text I wrote said: I was referring to situations in which we have people doing real work of real quality for a real market, and the work is delayed for external factors, by people who are not perceived as helping to resolve the problems. The de-motivating effect of such forces is not "pointless", although it often makes participation seem that way. and with respect to the current example of XMPP: The issue I was citing was forcing XMPP to be delayed, when there are no known problems with it. Citing the need to resolve IMPP matters, prior to processing XMPP working group output, is a very good example of a post-hoc requirement that is -- at very best -- only going to cause delay. In other words, the point I was raising is exactly NOT about the difficulty of coordinating dependent effort. It was/is about: a) the artificial creation of process dependencies, in the absence of any clear technical dependency, and b) post-hoc creation of dependencies, even though a working group has fulfilled its charter and has a ready constituency awaiting publication of its work. hqc> Though the IMPP-related mechanisms have been put into a separate hqc> document, I do not believe that the IETF last call can adequately hqc> assess the set of documents if the scope is not known, that is, hqc> we're not sure whether they are meant to be part of a mesh of hqc> cooperating IM systems or meant to stand alone (the question of how hqc> to judge "completeness" in 2026 terms being critical). I believe the general form of your statement, here, is that the IETF should not issue any components of a set of specifications, until we are completely clear on all the ways it will be used. No doubt, that is not what you intended to imply, but I would request you to consider carefully the interpretation I am offering. I believe it represents a natural derivation of what you *did* write and it is a very, very slippery slope to take a step on. In effect it means that we can arbitrarily delay issuing specifications which appear to be well written and usable, but for which we have some ill-defined discomfort about its use. And, of course, this is not a forum for trying to resolve IMPP or XMPP questions. However it *is* a forum for considering problems with timeliness. And I think you have demonstrated a very basic issue with the role the IETF is attempting to take in standards management. At base, the question is just what level and type of gate-keeping is appropriate for the IESG should perform, for work that has a clear community constituency, produces competent specifications, and which fulfills its charter in a timely fashion. The concept that there is some higher-level "coordination" (or, rather, orchestration) that the IESG should be doing sounds quite reasonable, but has not been anything that we have done successfully. And it's always dangerous to take on such a task when the existing track record suggests we will doing it badly. In other words, abstractly purporting to perform coordination on efforts that have little or no known technical dependency, but is instead based more on ill-specified "discomfort" is only effective at introducing uncertainty and delay. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Thu Jul 10 09:19:10 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00756 for ; Thu, 10 Jul 2003 09:19:09 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CB76E61BAD; Thu, 10 Jul 2003 15:18:39 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3775361BA0 for ; Thu, 10 Jul 2003 15:18:37 +0200 (CEST) Received: from MOU1WNEXC03.verisign.com (verisign.com [65.205.251.57]) by peacock.verisign.com (8.12.9/) with ESMTP id h6ADIYch011958; Thu, 10 Jul 2003 06:18:34 -0700 (PDT) Received: by mou1wnexc03.verisign.com with Internet Mail Service (5.5.2653.19) id ; Thu, 10 Jul 2003 06:18:34 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E0D22FC@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'Lars-Erik Jonsson (LU/EAB)'" , Keith Moore , "Hallam-Baker, Phillip" Date: Thu, 10 Jul 2003 06:18:32 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Cc: problem-statement@alvestrand.no Subject: RE: Fixed font v multiple fonts X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no > I totally agree with Keith here, this is not a subject for this WG. Apparently on the grounds that you don't think it is a problem. The PROBLEM I see with the IETF is that the top down management insists on having its way on every damn last thing. Including this issue. If the IETF establishment won't even budge on this one then there is zero value to the rest of PROBLEM. > Regarding the RFC document format, the RFC ASCII format is in > my opinion outstanding, compared to the complicated > formatting rules used by other organizations where you waste > lots of time just on getting the document format right. I have never spent half as much time getting a document format right as I have for the IETF. Even the W3C rules for HTML are not as much hassle. Again, the issue is who gets to decide. From problem-statement-bounces@alvestrand.no Thu Jul 10 09:39:07 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01545 for ; Thu, 10 Jul 2003 09:39:07 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 95E9E61B9F; Thu, 10 Jul 2003 15:38:38 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0334561B9B for ; Thu, 10 Jul 2003 15:38:37 +0200 (CEST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h6ADcYpZ009916; Thu, 10 Jul 2003 06:38:35 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJJ38861; Thu, 10 Jul 2003 06:38:34 -0700 (PDT) Message-Id: <200307101338.AJJ38861@mira-sjc5-c.cisco.com> To: "Hallam-Baker, Phillip" From: Melinda Shore In-Reply-To: Message from pbaker@verisign.com of "Thu, 10 Jul 2003 06:18:32 PDT." <2A1D4C86842EE14CA9BC80474919782E0D22FC@mou1wnexm02.verisign.com> Date: Thu, 10 Jul 2003 09:38:33 -0400 Cc: problem-statement@alvestrand.no Subject: Re: Fixed font v multiple fonts X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no > The PROBLEM I see with the IETF is that the top down management insists on > having its way on every damn last thing. Including this issue. We really need to have a description of why this issue is a problem for the IETF (i.e. not a matter of individual preference) or have it dropped. Thanks, Melinda From problem-statement-bounces@alvestrand.no Thu Jul 10 09:41:55 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01715 for ; Thu, 10 Jul 2003 09:41:54 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 39D8061BAD; Thu, 10 Jul 2003 15:41:26 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from sentosa.post1.com (sentosa.post1.com [202.27.17.100]) by eikenes.alvestrand.no (Postfix) with SMTP id DAA1861BA0 for ; Thu, 10 Jul 2003 15:41:22 +0200 (CEST) Received: (qmail 1707 invoked from network); 10 Jul 2003 13:47:02 -0000 Received: from bb-203-125-7-219.singnet.com.sg (HELO pobox.org.sg) (203.125.7.219) by sentosa.post1.com with SMTP; 10 Jul 2003 13:47:02 -0000 Message-ID: <3F0D6CF6.9020508@pobox.org.sg> Date: Thu, 10 Jul 2003 21:41:10 +0800 From: James Seng User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en, zh-cn, zh-tw, ja, ko MIME-Version: 1.0 To: "Hallam-Baker, Phillip" References: <2A1D4C86842EE14CA9BC80474919782E0D22FC@mou1wnexm02.verisign.com> In-Reply-To: <2A1D4C86842EE14CA9BC80474919782E0D22FC@mou1wnexm02.verisign.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no, Keith Moore , "'Lars-Erik Jonsson (LU/EAB)'" Subject: Re: Fixed font v multiple fonts X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit I guess when the rough consensus is not going your way, it is "top-down decision". Hello?? Lars have his rights to his opinion as much as you do. -James Seng > I have never spent half as much time getting a document format right as I > have for the IETF. Even the W3C rules for HTML are not as much hassle. > > Again, the issue is who gets to decide. From problem-statement-bounces@alvestrand.no Thu Jul 10 10:18:13 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04195 for ; Thu, 10 Jul 2003 10:18:12 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5E98A61BB4; Thu, 10 Jul 2003 16:17:45 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0D5B161BB9 for ; Thu, 10 Jul 2003 16:17:43 +0200 (CEST) Received: from tsg1 (121.sanjose-13-14rs16rt.ca.dial-access.att.net[12.81.5.121]) by mtiwmhc12.worldnet.att.net (mtiwmhc12) with SMTP id <20030710141739112004coh7e>; Thu, 10 Jul 2003 14:17:40 +0000 Message-ID: <007f01c346ee$02e41a50$020aff0a@tsg1> From: "todd glassey" To: "Hallam-Baker, Phillip" , "'Lars-Erik Jonsson (LU/EAB)'" , "Keith Moore" References: <2A1D4C86842EE14CA9BC80474919782E0D22FC@mou1wnexm02.verisign.com> Date: Thu, 10 Jul 2003 06:56:44 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Cc: problem-statement@alvestrand.no Subject: Re: Fixed font v multiple fonts X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit The real problem Phillip is that you are right. The IETF is a an empire and it will fall - but there are too many people that have their entire lives and their income dependant on keeping the IETF ass it is today, and in a state where they and ONLY THEY, make the calls. I harken this to the last days of Rome - and I wonder how this city will be 'sacked' Todd ----- Original Message ----- From: "Hallam-Baker, Phillip" To: "'Lars-Erik Jonsson (LU/EAB)'" ; "Keith Moore" ; "Hallam-Baker, Phillip" Cc: Sent: Thursday, July 10, 2003 6:18 AM Subject: RE: Fixed font v multiple fonts > > > I totally agree with Keith here, this is not a subject for this WG. > > Apparently on the grounds that you don't think it is a problem. > > The PROBLEM I see with the IETF is that the top down management insists on > having its way on every damn last thing. Including this issue. > > If the IETF establishment won't even budge on this one then there is zero > value to the rest of PROBLEM. > > > > Regarding the RFC document format, the RFC ASCII format is in > > my opinion outstanding, compared to the complicated > > formatting rules used by other organizations where you waste > > lots of time just on getting the document format right. > > > I have never spent half as much time getting a document format right as I > have for the IETF. Even the W3C rules for HTML are not as much hassle. > > Again, the issue is who gets to decide. > From problem-statement-bounces@alvestrand.no Thu Jul 10 10:22:46 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04376 for ; Thu, 10 Jul 2003 10:22:44 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BDE3161BA0; Thu, 10 Jul 2003 16:22:14 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from thunker.thunk.org (thunk.org [140.239.227.29]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1B97161B9F for ; Thu, 10 Jul 2003 16:22:14 +0200 (CEST) Received: from [206.135.70.116] (helo=think.thunk.org) authenticated as tytso by thunker.thunk.org with asmtp (tls_cipher TLSv1:DES-CBC3-SHA:168) (Exim 3.35 #1 (Debian)) id 19acJ5-0005Nk-00; Thu, 10 Jul 2003 10:22:00 -0400 Received: from tytso authenticated as tytso by think.thunk.org with local (Exim 3.35 #1 (Debian)) id 19acIT-00022D-00; Thu, 10 Jul 2003 10:21:21 -0400 Date: Thu, 10 Jul 2003 10:21:21 -0400 From: "Theodore Ts'o" To: James Seng Message-ID: <20030710142121.GA6924@think> References: <2A1D4C86842EE14CA9BC80474919782E0D22FC@mou1wnexm02.verisign.com> <3F0D6CF6.9020508@pobox.org.sg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F0D6CF6.9020508@pobox.org.sg> User-Agent: Mutt/1.5.4i Cc: Keith Moore , problem-statement@alvestrand.no, "Hallam-Baker, Phillip" , "'Lars-Erik Jonsson (LU/EAB)'" Subject: Re: Fixed font v multiple fonts X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no On Thu, Jul 10, 2003 at 09:41:10PM +0800, James Seng wrote: > I guess when the rough consensus is not going your way, it is "top-down > decision". Hello?? > > Lars have his rights to his opinion as much as you do. Congratulations to Lars for being promoted to being part of the "top-down clique". When I disagreed with Phil earlier, I found out that in the world according to Phil, I'm apparently doing it only to suck up to the "ruling clique" so that I could someday be on the IESG or even the IAB some day. Never mind the fact that I have absolutely no interest in either job... - Ted From problem-statement-bounces@alvestrand.no Thu Jul 10 10:35:42 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05033 for ; Thu, 10 Jul 2003 10:35:41 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 92CA961BAE; Thu, 10 Jul 2003 16:35:12 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by eikenes.alvestrand.no (Postfix) with ESMTP id 25B7661BAD for ; Thu, 10 Jul 2003 16:35:10 +0200 (CEST) Received: from mou1wnexc01.verisign.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.9/) with ESMTP id h6AEZ62Q027679; Thu, 10 Jul 2003 07:35:06 -0700 (PDT) Received: by mou1wnexc01.verisign.com with Internet Mail Service (5.5.2653.19) id ; Thu, 10 Jul 2003 07:35:06 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E0D22FE@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'James Seng'" , "Hallam-Baker, Phillip" Date: Thu, 10 Jul 2003 07:35:02 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Cc: problem-statement@alvestrand.no, Keith Moore , "'Lars-Erik Jonsson (LU/EAB)'" Subject: RE: Fixed font v multiple fonts X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Lars does not have the right to impose his decision on me. As for rough consensus, the PROBLEM I am identifying is that there is simply no forum where the majority of the membership can give their views on the matter. I am raising it as a problem because it was raised as one of the reasons why a group of prominent engineers want to propose changes to SMTP, MIME and S/MIME outside of IETF process. It is certainly not the most important, but it is the easiest one to fix. I would have thought that the near certainty that the Internet standards are going to be forked would be a concern to this group. Obviously I was wrong, you would all much rather run a debating society with no influence where you are in absolute control. Phill > -----Original Message----- > From: James Seng [mailto:jseng@pobox.org.sg] > Sent: Thursday, July 10, 2003 9:41 AM > To: Hallam-Baker, Phillip > Cc: 'Lars-Erik Jonsson (LU/EAB)'; Keith Moore; > problem-statement@alvestrand.no > Subject: Re: Fixed font v multiple fonts > > > I guess when the rough consensus is not going your way, it is > "top-down > decision". Hello?? > > Lars have his rights to his opinion as much as you do. > > -James Seng > > > I have never spent half as much time getting a document > format right as I > > have for the IETF. Even the W3C rules for HTML are not as > much hassle. > > > > Again, the issue is who gets to decide. > > From problem-statement-bounces@alvestrand.no Thu Jul 10 10:36:44 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05112 for ; Thu, 10 Jul 2003 10:36:43 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 60B1561BAE; Thu, 10 Jul 2003 16:36:16 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from EXECDSL.COM (ns.execdsl.net [208.184.15.238]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0D62061BAD for ; Thu, 10 Jul 2003 16:36:15 +0200 (CEST) Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 5013189 for problem-statement@alvestrand.no; Thu, 10 Jul 2003 10:22:29 -0400 Message-Id: <5.1.0.14.0.20030710101757.01888910@mail.stevecrocker.com> X-Sender: joel@stevecrocker.com@mail.stevecrocker.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 10 Jul 2003 10:22:14 -0400 To: problem-statement@alvestrand.no From: "Joel M. Halpern" In-Reply-To: <2A1D4C86842EE14CA9BC80474919782E0D22FC@mou1wnexm02.verisig n.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: RE: Fixed font v multiple fonts X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no I have trouble seeing this as an issue about "who gets to decide". There have been repeated discussions of the question on the IETF list (where it belongs). Each time, it is quite clear that the rough consensus of the community is to retain the current policy because its benefits exceed its drawbacks. Folks have noticed that there are some difficulties preparing documents, so they have built tools to help. There is a MS Word template. There are a set of tools that Marshall Rose has pulled together to allow one to prepare the material in XML. What is being said here is that the question of what the format for documents should be is not a core problem. Given that we have evidence of significant discussion and community input on that topic, I do not see evidence that this is a "top-down" problem, or even evidence that there is a community perception of a top down order. Yours, Joel M. Halpern At 06:18 AM 7/10/2003 -0700, Hallam-Baker, Phillip wrote: > > > I totally agree with Keith here, this is not a subject for this WG. > >Apparently on the grounds that you don't think it is a problem. > >The PROBLEM I see with the IETF is that the top down management insists on >having its way on every damn last thing. Including this issue. > >If the IETF establishment won't even budge on this one then there is zero >value to the rest of PROBLEM. > > > > Regarding the RFC document format, the RFC ASCII format is in > > my opinion outstanding, compared to the complicated > > formatting rules used by other organizations where you waste > > lots of time just on getting the document format right. > > >I have never spent half as much time getting a document format right as I >have for the IETF. Even the W3C rules for HTML are not as much hassle. > >Again, the issue is who gets to decide. From problem-statement-bounces@alvestrand.no Thu Jul 10 12:19:51 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10368 for ; Thu, 10 Jul 2003 12:19:50 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2A1DC61BB2; Thu, 10 Jul 2003 18:19:23 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from [192.168.1.4] (nat.alvestrand.no [217.13.28.204]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1D75761BAE; Thu, 10 Jul 2003 18:19:21 +0200 (CEST) Date: Thu, 10 Jul 2003 18:20:39 +0200 From: Harald Tveit Alvestrand To: "Hallam-Baker, Phillip" , "'James Seng'" Message-ID: <180130000.1057854039@askvoll.hjemme.alvestrand.no> In-Reply-To: <2A1D4C86842EE14CA9BC80474919782E0D22FE@mou1wnexm02.verisign.com> References: <2A1D4C86842EE14CA9BC80474919782E0D22FE@mou1wnexm02.verisign.com > X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: problem-statement@alvestrand.no, Keith Moore , "'Lars-Erik Jonsson (LU/EAB)'" Subject: RE: Fixed font v multiple fonts X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit --On torsdag, juli 10, 2003 07:35:02 -0700 "Hallam-Baker, Phillip" wrote: > Lars does not have the right to impose his decision on me. > > As for rough consensus, the PROBLEM I am identifying is that there is > simply no forum where the majority of the membership can give their views > on the matter. The closest thing we have is the IETF plenary. And it's been consistently *against* any particular proposed change to document formast. If you don't want to respect that - your choice. > I am raising it as a problem because it was raised as one of the reasons > why a group of prominent engineers want to propose changes to SMTP, MIME > and S/MIME outside of IETF process. > > It is certainly not the most important, but it is the easiest one to fix. As you've seen - that's probably not true (that it's easy to fix). > I would have thought that the near certainty that the Internet standards > are going to be forked would be a concern to this group. Obviously I was > wrong, you would all much rather run a debating society with no influence > where you are in absolute control. As in open source, the power to fork is the last recourse against inappropriate leadership. So I won't claim that they're wrong to do so. But until they show their faces and say what they want, I cannot possibly evaluate their desire to change these protocols. [[Out of curiosity: What are the permitted submission formats to OASIS? Am I allowed to use ASCII? (their publication formats are PDF and HTML - a brief scan of their website showed no policy document about input formats.) ]] Harald From problem-statement-bounces@alvestrand.no Thu Jul 10 14:10:23 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14888 for ; Thu, 10 Jul 2003 14:10:22 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A748E61BA0; Thu, 10 Jul 2003 20:09:52 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0349A61B9F for ; Thu, 10 Jul 2003 20:09:51 +0200 (CEST) Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h6AI9iBd018218 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 10 Jul 2003 11:09:44 -0700 (PDT) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by crowley.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h6AI9gix021663; Thu, 10 Jul 2003 11:09:42 -0700 (PDT) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: <67103775571.20030709220748@brandenburg.com> References: <120210000.1055072340@askvoll.hjemme.alvestrand.no> <481518433.20030608091336@brandenburg.com> <125670000.1055090084@askvoll.hjemme.alvestrand.no> <721113479.20030608173246@brandenburg.com> <148310000.1055147276@askvoll.hjemme.alvestrand.no> <1101423707.20030706085955@brandenburg.com> <552230000.1057554700@askvoll.hjemme.alvestrand.no> <1012748672.20030707170343@brandenburg.com> <67103775571.20030709220748@brandenburg.com> Date: Thu, 10 Jul 2003 11:09:39 -0700 To: Dave Crocker From: hardie@qualcomm.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: problem-statement@alvestrand.no Subject: Re: ISSUE: Determinants for timeliness missing in section 2.1 X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no At 10:07 PM +0200 7/9/03, Dave Crocker the following as proposed problems: > > a) the artificial creation of process dependencies, in the absence of > any clear technical dependency, and > > b) post-hoc creation of dependencies, even though a working group has > fulfilled its charter and has a ready constituency awaiting > publication of its work. > Charters do create dependencies, though, both on work that is completed (as Lemonade on Conneg) and work that is ongoing (as XMPP on IMPP). Charters are reviewed by the community, and it may well be that some form of highlighting that there will be dependencies would be useful. Working groups also create dependencies (for example, one of the candidate solutions for CRISP might require an extension for LDAP). Those dependencies are on technical output, not "process dependencies" in the sense of "you appeal to the IAB after the appeal to the IESG has returned". There may be a judgement call in whether a particular technical output is or is not required to construct a particular solution and whether or not it is required to evaluate that solution. Making those explicit is very important, so that there is not a "pocket veto" effect of WG chair or AD saying to themselves "I'd like to see how FOO comes out before sending this into the next bucket, so I'll wait". Explicit statements about the dependencies mean that the other interested parties can discuss it when necessary. This working group is not the place to have those discussions, though. On the other, possibly larger question, on the creation of dependencies more generally, I believe we disagree. In draft-hardie-12-2-1-00.txt, I have this as one of the heresies: 1.6 Dependencies. The work of one group must be able to depend on the work of another. An organization with expected output of the IETF must be able to have the work of one unit depend on the work of another. Working groups commonly divide their work into multiple related documents, rather than trying to create a single, monolithic specification. The IETF as a larger community needs to be able to do the same thing, by allowing specific groups' work to depend on that being done at other layers or in other areas. One advantage the IETF has in open review and input is that when one group's lack of conclusive output is gating other work, those waiting can add their energy to the working group they depend on. In other words, I see handling of dependencies as something which presents challenges, but it is not in and of itself a problem in my view. My opinion, Ted Hardie From problem-statement-bounces@alvestrand.no Thu Jul 10 19:02:06 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26259 for ; Thu, 10 Jul 2003 19:02:05 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0F99B61BA0; Fri, 11 Jul 2003 01:01:38 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by eikenes.alvestrand.no (Postfix) with ESMTP id B750E61B9F for ; Fri, 11 Jul 2003 01:01:36 +0200 (CEST) Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h6AN1XZf003000 for ; Thu, 10 Jul 2003 16:01:34 -0700 (PDT) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by neophyte.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h6AN1Wuh029272 for ; Thu, 10 Jul 2003 16:01:32 -0700 (PDT) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: Date: Thu, 10 Jul 2003 16:01:27 -0700 To: problem-statement@alvestrand.no From: hardie@qualcomm.com Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable Subject: Open source foundation structures article (includes IETF mention) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: quoted-printable http://workingknowledge.hbs.edu/pubitem.jhtml?id=3D3582&t=3Dtechnology The article discusses why the open source community has created certain kinds of organizational structures to support its work. It cites the IETF as a "nonprofit professional society" and relates that to other work. This is just an interview, the larger work will=20 be in Making Sense of the Bazaar: Perspectives on Open Source and Free Software ,=20 Siobh=E1n O'Mahony, ed. O'Reilly & Associates Publications, 2003, which is still forthcoming. regards, Ted Hardie From problem-statement-bounces@alvestrand.no Thu Jul 10 19:25:10 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26659 for ; Thu, 10 Jul 2003 19:25:10 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CCFAF61BAD; Fri, 11 Jul 2003 01:24:42 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6DA0D61BA0 for ; Fri, 11 Jul 2003 01:24:40 +0200 (CEST) Received: from tsg1 (105.sanjose-08-09rs16rt.ca.dial-access.att.net[12.81.3.105]) by mtiwmhc12.worldnet.att.net (mtiwmhc12) with SMTP id <20030710232437112004jikhe>; Thu, 10 Jul 2003 23:24:38 +0000 Message-ID: <00bf01c3473a$69c55080$020aff0a@tsg1> From: "todd glassey" To: "James Seng" , "Hallam-Baker, Phillip" References: <2A1D4C86842EE14CA9BC80474919782E0D22FC@mou1wnexm02.verisign.com> <3F0D6CF6.9020508@pobox.org.sg> Date: Thu, 10 Jul 2003 15:29:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Cc: problem-statement@alvestrand.no, Keith Moore , "'Lars-Erik Jonsson (LU/EAB)'" Subject: Re: Fixed font v multiple fonts X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit James - the problem is that a consensus doesn't exist in the IETF. A consensus is based on a concept of a number of people actually being able to vote on something and that doesn't exist here. What does exist here is a concept of micro-special interest groups that come together to specifically advance **their** initiatives at the expense and to stop all others that would compete with them. If you doubt this do a work flow analysis on RFC2026, RFC2223, and RFC2418 as it pertains to the standards track processes. What you will find is that you are clearly wrong here, and that also is one of the problems with the IETF. What I am saying is that in the current system any group of people declaring themselves the majority first are accorded that. Today the mighty win always in the IETF, but this too ***is*** going to change. Todd Glassey ----- Original Message ----- From: "James Seng" To: "Hallam-Baker, Phillip" Cc: ; "Keith Moore" ; "'Lars-Erik Jonsson (LU/EAB)'" Sent: Thursday, July 10, 2003 6:41 AM Subject: Re: Fixed font v multiple fonts > I guess when the rough consensus is not going your way, it is "top-down > decision". Hello?? > > Lars have his rights to his opinion as much as you do. > > -James Seng > > > I have never spent half as much time getting a document format right as I > > have for the IETF. Even the W3C rules for HTML are not as much hassle. > > > > Again, the issue is who gets to decide. > > From problem-statement-bounces@alvestrand.no Thu Jul 10 19:50:54 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27091 for ; Thu, 10 Jul 2003 19:50:53 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7D97A61BA0; Fri, 11 Jul 2003 01:50:24 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from sentosa.post1.com (sentosa.post1.com [202.27.17.100]) by eikenes.alvestrand.no (Postfix) with SMTP id 2F52C61B9F for ; Fri, 11 Jul 2003 01:50:21 +0200 (CEST) Received: (qmail 6513 invoked from network); 10 Jul 2003 23:56:05 -0000 Received: from bb-203-125-7-219.singnet.com.sg (HELO pobox.org.sg) (203.125.7.219) by sentosa.post1.com with SMTP; 10 Jul 2003 23:56:05 -0000 Message-ID: <3F0DFBB7.8010305@pobox.org.sg> Date: Fri, 11 Jul 2003 07:50:15 +0800 From: James Seng User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en, zh-cn, zh-tw, ja, ko MIME-Version: 1.0 To: "Hallam-Baker, Phillip" References: <2A1D4C86842EE14CA9BC80474919782E0D22FE@mou1wnexm02.verisign.com> In-Reply-To: <2A1D4C86842EE14CA9BC80474919782E0D22FE@mou1wnexm02.verisign.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no, Keith Moore , "'Lars-Erik Jonsson (LU/EAB)'" Subject: Re: Fixed font v multiple fonts X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Hallam-Baker, Phillip wrote: > Lars does not have the right to impose his decision on me. And you have the right to impose your decision on him? For one who advocate "openness and democratic", I expect you to have more tolerance for differences in opinions. ps: For a person working on IDN and other I18N issues in IETF, I think that ASCII format has its limitation. Perhaps something along this? http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office > I am raising it as a problem because it was raised as one of the reasons why > a group of prominent engineers want to propose changes to SMTP, MIME and > S/MIME outside of IETF process. Sure they can. Heck, I even redesigned DNS in my lab but that does not means anyone else should care about it. > It is certainly not the most important, but it is the easiest one to fix. Once again, I disagree with you. It isn't as simple as it you think. > I would have thought that the near certainty that the Internet standards are > going to be forked would be a concern to this group. Obviously I was wrong, > you would all much rather run a debating society with no influence where you > are in absolute control. While there is a issue with the "balance of power" within IETF, the ultimate power still lies in the users to adopt the standard in IETF. NOTHING in the current process prevents industry to adopt or user dropping IETF standards. The fact they still doing using the technology suggest that IETF must be doing something right. Of course, that does not means everything is "right". -James Seng From problem-statement-bounces@alvestrand.no Thu Jul 10 19:55:27 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27223 for ; Thu, 10 Jul 2003 19:55:26 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3A3B261BA0; Fri, 11 Jul 2003 01:54:58 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from sentosa.post1.com (sentosa.post1.com [202.27.17.100]) by eikenes.alvestrand.no (Postfix) with SMTP id 9694861B9F for ; Fri, 11 Jul 2003 01:54:55 +0200 (CEST) Received: (qmail 6537 invoked from network); 11 Jul 2003 00:00:39 -0000 Received: from bb-203-125-7-219.singnet.com.sg (HELO pobox.org.sg) (203.125.7.219) by sentosa.post1.com with SMTP; 11 Jul 2003 00:00:39 -0000 Message-ID: <3F0DFCC9.7000101@pobox.org.sg> Date: Fri, 11 Jul 2003 07:54:49 +0800 From: James Seng User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en, zh-cn, zh-tw, ja, ko MIME-Version: 1.0 To: todd glassey References: <2A1D4C86842EE14CA9BC80474919782E0D22FC@mou1wnexm02.verisign.com> <3F0D6CF6.9020508@pobox.org.sg> <00bf01c3473a$69c55080$020aff0a@tsg1> In-Reply-To: <00bf01c3473a$69c55080$020aff0a@tsg1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Keith Moore , problem-statement@alvestrand.no, "Hallam-Baker, Phillip" , "'Lars-Erik Jonsson (LU/EAB)'" Subject: Re: Fixed font v multiple fonts X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Ah, but we dont do "consensus", unlike JTC1 or other organisation. We do "rough consensus" and there is a big differences. "If you are in Rome, do as a Roman." You can't compare IETF culture with any other organisation just like you cannot compare a Chinese culture using American culture presumation. -James Seng todd glassey wrote: > James - the problem is that a consensus doesn't exist in the IETF. A > consensus is based on a concept of a number of people actually being able to > vote on something and that doesn't exist here. What does exist here is a > concept of micro-special interest groups that come together to specifically > advance **their** initiatives at the expense and to stop all others that > would compete with them. If you doubt this do a work flow analysis on > RFC2026, RFC2223, and RFC2418 as it pertains to the standards track > processes. > > What you will find is that you are clearly wrong here, and that also is one > of the problems with the IETF. What I am saying is that in the current > system any group of people declaring themselves the majority first are > accorded that. > > Today the mighty win always in the IETF, but this too ***is*** going to > change. > > Todd Glassey > > ----- Original Message ----- > From: "James Seng" > To: "Hallam-Baker, Phillip" > Cc: ; "Keith Moore" ; > "'Lars-Erik Jonsson (LU/EAB)'" > Sent: Thursday, July 10, 2003 6:41 AM > Subject: Re: Fixed font v multiple fonts > > > >>I guess when the rough consensus is not going your way, it is "top-down >>decision". Hello?? >> >>Lars have his rights to his opinion as much as you do. >> >>-James Seng >> >> >>>I have never spent half as much time getting a document format right as > > I > >>>have for the IETF. Even the W3C rules for HTML are not as much hassle. >>> >>>Again, the issue is who gets to decide. >> >> > > > From problem-statement-bounces@alvestrand.no Thu Jul 10 20:57:30 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28643 for ; Thu, 10 Jul 2003 20:57:29 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 279A261BAD; Fri, 11 Jul 2003 02:57:01 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4D2F061BA0 for ; Fri, 11 Jul 2003 02:56:59 +0200 (CEST) Received: from mou1wnexc01.verisign.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.9/) with ESMTP id h6B0uv2Q027604; Thu, 10 Jul 2003 17:56:57 -0700 (PDT) Received: by mou1wnexc01.verisign.com with Internet Mail Service (5.5.2653.19) id ; Thu, 10 Jul 2003 17:56:57 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E0D230E@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'James Seng'" , "Hallam-Baker, Phillip" Date: Thu, 10 Jul 2003 17:56:56 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Cc: problem-statement@alvestrand.no, Keith Moore , "'Lars-Erik Jonsson (LU/EAB)'" Subject: RE: Fixed font v multiple fonts X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no > > Hallam-Baker, Phillip wrote: > > Lars does not have the right to impose his decision on me. Lars is free to present his work as shoddily as he chooses. He is not free to impose his choices on me. From problem-statement-bounces@alvestrand.no Thu Jul 10 21:12:40 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29055 for ; Thu, 10 Jul 2003 21:12:39 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C21AD61BAE; Fri, 11 Jul 2003 03:12:10 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0234261BAD for ; Fri, 11 Jul 2003 03:12:09 +0200 (CEST) Received: from tsg1 (105.sanjose-08-09rs16rt.ca.dial-access.att.net[12.81.3.105]) by mtiwmhc12.worldnet.att.net (mtiwmhc12) with SMTP id <20030711011206112006lhm1e>; Fri, 11 Jul 2003 01:12:07 +0000 Message-ID: <013801c34749$6d5a8760$020aff0a@tsg1> From: "todd glassey" To: "Hallam-Baker, Phillip" , "Melinda Shore" References: <200307101338.AJJ38861@mira-sjc5-c.cisco.com> Date: Thu, 10 Jul 2003 18:11:49 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Cc: problem-statement@alvestrand.no Subject: Re: Fixed font v multiple fonts X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Melinda Shore" To: "Hallam-Baker, Phillip" Cc: Sent: Thursday, July 10, 2003 6:38 AM Subject: Re: Fixed font v multiple fonts > > The PROBLEM I see with the IETF is that the top down management insists on > > having its way on every damn last thing. Including this issue. > > We really need to have a description of why this issue is a > problem for the IETF (i.e. not a matter of individual > preference) or have it dropped. Becuase of the words "Fair and Open" which appear ubiquitously in many IETF structural documents. > > Thanks, > > Melinda From problem-statement-bounces@alvestrand.no Thu Jul 10 21:44:03 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29723 for ; Thu, 10 Jul 2003 21:44:02 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6240361BAD; Fri, 11 Jul 2003 03:43:34 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by eikenes.alvestrand.no (Postfix) with ESMTP id A9BF761BA0 for ; Fri, 11 Jul 2003 03:43:32 +0200 (CEST) Received: from tsg1 (105.sanjose-08-09rs16rt.ca.dial-access.att.net[12.81.3.105]) by mtiwmhc12.worldnet.att.net (mtiwmhc12) with SMTP id <2003071101432911200dq7jee>; Fri, 11 Jul 2003 01:43:31 +0000 Message-ID: <017101c3474d$cfdff240$020aff0a@tsg1> From: "todd glassey" To: "James Seng" References: <2A1D4C86842EE14CA9BC80474919782E0D22FC@mou1wnexm02.verisign.com> <3F0D6CF6.9020508@pobox.org.sg> <00bf01c3473a$69c55080$020aff0a@tsg1> <3F0DFCC9.7000101@pobox.org.sg> Date: Thu, 10 Jul 2003 18:42:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Cc: Keith Moore , problem-statement@alvestrand.no, "Hallam-Baker, Phillip" , "'Lars-Erik Jonsson (LU/EAB)'" Subject: Re: Fixed font v multiple fonts X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit We are not talking about the Chinese Culture, or the current government of China, we are talking about that the IETF standards process is more like "The Family Feud" than anyone ever bargained for. You argue a bunch of questions before the WG Chair and then republish your big guess just to get to round three where the IESG stumps you with a no-faith vote, or avoids the question all together. Hell there is no "legal" reason for the IETF to publish anything, and if you doubt that read the RFC's and the new IPR documents where the IP Rights are defined. Its hysterical. Todd ----- Original Message ----- From: "James Seng" To: "todd glassey" Cc: "Hallam-Baker, Phillip" ; ; "Keith Moore" ; "'Lars-Erik Jonsson (LU/EAB)'" Sent: Thursday, July 10, 2003 4:54 PM Subject: Re: Fixed font v multiple fonts > Ah, but we dont do "consensus", unlike JTC1 or other organisation. We do > "rough consensus" and there is a big differences. No we dont. What we do is a "public agreement" process wherein a group of three or four individuals make virtually all, if not in fact all the decisions on each and every one of the IETF's standard initiatives within their hosting WG, and any dissenterrs voices have been set up to be eliminated via RFC2418 or other disicplinary processes. > > "If you are in Rome, do as a Roman." Oh you mean spend... that's it, spend... > > You can't compare IETF culture with any other organisation just like you > cannot compare a Chinese culture using American culture presumation. Right - but any analyst can build an IETF Standards workflow from RFC2026, 2223, 2418 and the new IPR I-D's and document the various decision gates and their influencing or controling factors... When done one would then extract specific phrases and ideas codified in these three secular IETF documents and point out how the work flows violate the words and certainly their spirit... Hmmmm - > > -James Seng > > todd glassey wrote: > > > James - the problem is that a consensus doesn't exist in the IETF. A > > consensus is based on a concept of a number of people actually being able to > > vote on something and that doesn't exist here. What does exist here is a > > concept of micro-special interest groups that come together to specifically > > advance **their** initiatives at the expense and to stop all others that > > would compete with them. If you doubt this do a work flow analysis on > > RFC2026, RFC2223, and RFC2418 as it pertains to the standards track > > processes. > > > > What you will find is that you are clearly wrong here, and that also is one > > of the problems with the IETF. What I am saying is that in the current > > system any group of people declaring themselves the majority first are > > accorded that. > > > > Today the mighty win always in the IETF, but this too ***is*** going to > > change. > > > > Todd Glassey > > > > ----- Original Message ----- > > From: "James Seng" > > To: "Hallam-Baker, Phillip" > > Cc: ; "Keith Moore" ; > > "'Lars-Erik Jonsson (LU/EAB)'" > > Sent: Thursday, July 10, 2003 6:41 AM > > Subject: Re: Fixed font v multiple fonts > > > > > > > >>I guess when the rough consensus is not going your way, it is "top-down > >>decision". Hello?? > >> > >>Lars have his rights to his opinion as much as you do. > >> > >>-James Seng > >> > >> > >>>I have never spent half as much time getting a document format right as > > > > I > > > >>>have for the IETF. Even the W3C rules for HTML are not as much hassle. > >>> > >>>Again, the issue is who gets to decide. > >> > >> > > > > > > > > From problem-statement-bounces@alvestrand.no Fri Jul 11 02:07:46 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13023 for ; Fri, 11 Jul 2003 02:07:45 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E525A61BA0; Fri, 11 Jul 2003 08:07:15 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from sentosa.post1.com (sentosa.post1.com [202.27.17.100]) by eikenes.alvestrand.no (Postfix) with SMTP id 80EE061A93 for ; Fri, 11 Jul 2003 08:07:12 +0200 (CEST) Received: (qmail 11621 invoked from network); 11 Jul 2003 06:12:55 -0000 Received: from ida80.ida.gov.sg (HELO pobox.org.sg) (210.24.194.80) by sentosa.post1.com with SMTP; 11 Jul 2003 06:12:55 -0000 Message-ID: <3F0E540A.6070804@pobox.org.sg> Date: Fri, 11 Jul 2003 14:07:06 +0800 From: James Seng User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en, zh-cn, zh-tw, ja, ko MIME-Version: 1.0 To: todd glassey References: <2A1D4C86842EE14CA9BC80474919782E0D22FC@mou1wnexm02.verisign.com> <3F0D6CF6.9020508@pobox.org.sg> <00bf01c3473a$69c55080$020aff0a@tsg1> <3F0DFCC9.7000101@pobox.org.sg> <017101c3474d$cfdff240$020aff0a@tsg1> In-Reply-To: <017101c3474d$cfdff240$020aff0a@tsg1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no, "Hallam-Baker, Phillip" , Keith Moore , "'Lars-Erik Jonsson (LU/EAB)'" Subject: Re: Fixed font v multiple fonts X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Interesting. Perhaps you can enlighten all of us by pointing out the conflicts. But please do so in the IPR list and not here unless there is a wider IETF problem to address. -James Seng > Right - but any analyst can build an IETF Standards workflow from RFC2026, > 2223, 2418 and the new IPR I-D's and document the various decision gates > and their influencing or controling factors... When done one would then > extract specific phrases and ideas codified in these three secular IETF > documents and point out how the work flows violate the words and certainly > their spirit... Hmmmm - > From problem-statement-bounces@alvestrand.no Fri Jul 11 02:25:01 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17716 for ; Fri, 11 Jul 2003 02:25:00 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 76F8B61B9B; Fri, 11 Jul 2003 08:24:30 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from sentosa.post1.com (sentosa.post1.com [202.27.17.100]) by eikenes.alvestrand.no (Postfix) with SMTP id 2852661A93 for ; Fri, 11 Jul 2003 08:24:28 +0200 (CEST) Received: (qmail 11744 invoked from network); 11 Jul 2003 06:30:10 -0000 Received: from ida120.ida.gov.sg (HELO pobox.org.sg) (210.24.194.120) by sentosa.post1.com with SMTP; 11 Jul 2003 06:30:10 -0000 Message-ID: <3F0E5816.7060207@pobox.org.sg> Date: Fri, 11 Jul 2003 14:24:22 +0800 From: James Seng User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en, zh-cn, zh-tw, ja, ko MIME-Version: 1.0 To: "Hallam-Baker, Phillip" References: <2A1D4C86842EE14CA9BC80474919782E0D230E@mou1wnexm02.verisign.com> In-Reply-To: <2A1D4C86842EE14CA9BC80474919782E0D230E@mou1wnexm02.verisign.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no, Keith Moore , "'Lars-Erik Jonsson (LU/EAB)'" Subject: Re: Fixed font v multiple fonts X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Just have another thought, altho I may be over-generalizing...but bear with me for a moment. Some standard organisation achieve consensus by doing a UNION of the ideas, ie, if A propose X and B propose Y, so long there is no conflict, we put both X & Y into the standard. During voting, A dont object to Y if B dont object to X and vice versa (aka horse trading). The results is that it _is_ possible to achieve 100% consensus altho we have a bloated standard. IETF on the other hands prefers to do INTERSECTION of the ideas, ie, if A propose X and B propose Y, we take only the intersection of the ideas where there "rough consensus" and throw out those (from X or Y) that have does not have rough consensus. While this remove horse trading problem and gives us a leaner standards, it also means we have to live with only very baseline standards, and in some cases, everyone equally pissed too (aka distribution of pain). Which is comes back to the topic of "ASCII text" vs "other fancy document format". At this moment, we have rough consensus that ASCII text, with its limitation, is useful for the IETF. OTOH, there is no rough consensus for any other document format yet. (notice we doing INTERSECTION of ideas). Should we also allow other document format? If no, why not? (And in certain ways, people have absolute reasons to be angry). But if yes, are we ready to change the way we do this? Or a higher level question: Is the current way we process ideas, ie, taking only the parts which have rough consensus and leaving out those that dont have, a problem? -James Seng Hallam-Baker, Phillip wrote: >>Hallam-Baker, Phillip wrote: >> >>>Lars does not have the right to impose his decision on me. > > > Lars is free to present his work as shoddily as he chooses. He is not free > to impose his choices on me. > > From problem-statement-bounces@alvestrand.no Fri Jul 11 08:33:19 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27347 for ; Fri, 11 Jul 2003 08:33:18 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2F16161BB2; Fri, 11 Jul 2003 14:32:48 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by eikenes.alvestrand.no (Postfix) with ESMTP id AE70E61BB0 for ; Fri, 11 Jul 2003 14:32:46 +0200 (CEST) Received: from mou1wnexc02.verisign.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.9/) with ESMTP id h6BCWjch029213 for ; Fri, 11 Jul 2003 05:32:45 -0700 (PDT) Received: by mou1wnexc02.verisign.com with Internet Mail Service (5.5.2653.19) id ; Fri, 11 Jul 2003 05:32:45 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E0D230F@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'problem-statement@alvestrand.no'" Date: Fri, 11 Jul 2003 05:32:38 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: Plenary decision? X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no >The closest thing we have is the IETF plenary. And it's been consistently >*against* any particular proposed change to document formast. If you don't >want to respect that - your choice. I seem to recall raising the issue in a plenary. At no time was I aware that the plenary was the decision maker for the issue in question. This was I believe because of your reply 'There is a process", I remember that part of the reply because you neglected to say what the process was. So here we are in this forum and I find out that oh, the plenary was the decision making body! The only other plenary where I was present at which the issue was raised I raised it with Jon Postel who stated that he was not opposed in principle but did have a series of issues that needed to be met first which we could discuss offline. We were exchanging email on the subject just before Jon passed away. If the plenary is a decision making body as you are implying then why does it keep no minutes? It is possible that Harald is correct in his assertion, but I find no record in the minutes because there arn't any. Phill From problem-statement-bounces@alvestrand.no Fri Jul 11 09:01:25 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27987 for ; Fri, 11 Jul 2003 09:01:22 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C4F7361BB2; Fri, 11 Jul 2003 15:00:52 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by eikenes.alvestrand.no (Postfix) with ESMTP id C731F61BB0 for ; Fri, 11 Jul 2003 15:00:50 +0200 (CEST) Received: from BBFUJIP.brandenburg.com (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h6BD4QF13900; Fri, 11 Jul 2003 06:04:26 -0700 Date: Fri, 11 Jul 2003 15:01:25 +0200 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/11) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <431469092.20030711150125@brandenburg.com> To: hardie@qualcomm.com In-Reply-To: References: <120210000.1055072340@askvoll.hjemme.alvestrand.no> <481518433.20030608091336@brandenburg.com> <125670000.1055090084@askvoll.hjemme.alvestrand.no> <721113479.20030608173246@brandenburg.com> <148310000.1055147276@askvoll.hjemme.alvestrand.no> <1101423707.20030706085955@brandenburg.com> <552230000.1057554700@askvoll.hjemme.alvestrand.no> <1012748672.20030707170343@brandenburg.com> <67103775571.20030709220748@brandenburg.com> MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: ISSUE: Determinants for timeliness missing in section 2.1 X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit hardie, hqc> Charters do create dependencies, that warrants ensuring proper coordination between the dependent parts, not the entire body of work. hqc> On the other, possibly larger question, on the creation of hqc> dependencies more generally, hqc> I believe we disagree. we do. i'm contemplating a response to your I-D. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Fri Jul 11 10:37:00 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01749 for ; Fri, 11 Jul 2003 10:36:59 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 44C1661BB2; Fri, 11 Jul 2003 16:36:30 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from thunker.thunk.org (thunk.org [140.239.227.29]) by eikenes.alvestrand.no (Postfix) with ESMTP id EDC2A61BB0 for ; Fri, 11 Jul 2003 16:36:28 +0200 (CEST) Received: from [206.135.70.116] (helo=think.thunk.org) authenticated as tytso by thunker.thunk.org with asmtp (tls_cipher TLSv1:DES-CBC3-SHA:168) (Exim 3.35 #1 (Debian)) id 19az0X-0006VW-00; Fri, 11 Jul 2003 10:36:22 -0400 Received: from tytso authenticated as tytso by think.thunk.org with local (Exim 3.35 #1 (Debian)) id 19az0R-0000qS-00; Fri, 11 Jul 2003 10:36:15 -0400 Date: Fri, 11 Jul 2003 10:36:14 -0400 From: "Theodore Ts'o" To: "Hallam-Baker, Phillip" Message-ID: <20030711143614.GA3218@think> References: <2A1D4C86842EE14CA9BC80474919782E0D230F@mou1wnexm02.verisign.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2A1D4C86842EE14CA9BC80474919782E0D230F@mou1wnexm02.verisign.com> User-Agent: Mutt/1.5.4i Cc: "'problem-statement@alvestrand.no'" Subject: Re: Plenary decision? X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no On Fri, Jul 11, 2003 at 05:32:38AM -0700, Hallam-Baker, Phillip wrote: > I seem to recall raising the issue in a plenary. At no time was I > aware that the plenary was the decision maker for the issue in > question. > > This was I believe because of your reply 'There is a process", I > remember that part of the reply because you neglected to say what > the process was. > > So here we are in this forum and I find out that oh, the plenary was the > decision making body! Phill, First of all, thank you writing a much calmer and much more thoughtful e-mail. It may very well be that that the IETF has grown too large for our earlier, more informal mechanisms of governance. Just as in working group chairs have the power to determine rough consensus, and are charged with making good decisions about when there is rough conensensus, and when people are raising technical objections of the form, "it can't possibly work", versus "there are engineering tradeoffs here, and I happen to strongly prefer door A over door B" (where objections of the first kind must be taken care of as opposed to objections of the second, which you try to reduce but ultimately is not reduced down to zero because "rough consensus" doesn't mean unanimity), at least in my view of the world, that's what the IESG is charged with doing, on a larger scale for the entire IETF. This should be nothing new; it's in the TAO of the IETF, and in the newcomer's briefing, but since you seem to be have some doubts about what the process is, I thought it would be put it out explicitly. For questions like whether or not we use non-ASCII documents exclusively, currently, the process is the RFC Editor decides, with strong input/direction coming from the IAB and the IESG. On the other hand, if they don't respect the community consensus, there are many checks and balances, including (a) throwing the bums out, (b) the appeals process, (c) simply going to other standards bodies. That being said, the topic of non-ASCII RFC's comes up every couple of years, and at every IETF plenary that I can remember, the number of people who come up to mike who bring up advantages of ASCII and disadvantages of other formats generally run about four or five to one in favor of ASCII. So I would argue that given the current decision making process, the IESG did absolutely right thing. Furthermore, even if we believed that democracy was a magic wand that automatically produced technically superior standards, it seems pretty clear that ASCII would probably win out. > If the plenary is a decision making body as you are implying then why does > it keep no minutes? > > It is possible that Harald is correct in his assertion, but I find no > record in the minutes because there arn't any. It is not a decision making body, but it is the best way of measuring the general consensus of the community. Currently, we don't take minutes, but rely on memories and the IESG to judge that consensus. Your complaints about the IETF's about process, and who are the decision-making bodies, and your accusations of ruling cliques I think goes to the heart of the matter, which is fundamentally one about how we govern ourselves, and whether we should be using a very formal process, or an informal one. I view this as an engineering tradeoff. There are certainly advantages in using a very formal, structured meeting format where decisions are made via votes and minutes and Robert's Rule of Order. There are also advantages to using a system of judging rough consensus and an appeals process as a check and balance. Both schemes also have their disadvantages. Some people feel much more comfortable with standards bodies that use a very formal process. Others have noted that in the past, bodies that have gone down this past have sometimes gotten mired in bureaucracies, and result in people (and large corporations) who are really good at manipulated said process, but who are not necessarily good at producing good technical results. Certainly there was a time when our lightweight decision-making process was compared favorably to the process used by ISO and more formal standards making bodies. It is therefore ironic that one of the reasons why we're engaging in this problem-statement process is because we seem to be falling prey to many of the problems that we once caused a certain feeling of superiority over these more formal standards bodies. Is the answer to become more like these formal standards bodies? That seems to be what some people are suggesting. I am hoping though that there is something about our process of rough consensus and running code which is unique and better than a heavy-weight system based on process and votes. That is, I hope that while we are fixing some very real problems, that we don't end up throwing out the baby with the bathwater. On the other hand, it may be that that real problem is that smaller bodies are just naturally more lightweight (regardless of what scheme of polity they use), and that growth inevitably causes problems. In that case, the fact that some groups are trying out new standards organizations might not necessarily be such a terrible thing. - Ted From problem-statement-bounces@alvestrand.no Fri Jul 11 11:30:16 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03640 for ; Fri, 11 Jul 2003 11:30:14 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8B54B61BB2; Fri, 11 Jul 2003 17:29:45 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by eikenes.alvestrand.no (Postfix) with ESMTP id 98C9F61BB0 for ; Fri, 11 Jul 2003 17:29:43 +0200 (CEST) Received: from mou1wnexc01.verisign.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.9/) with ESMTP id h6BFTg2Q000264; Fri, 11 Jul 2003 08:29:42 -0700 (PDT) Received: by mou1wnexc01.verisign.com with Internet Mail Service (5.5.2653.19) id ; Fri, 11 Jul 2003 08:29:42 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E0D2313@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'Theodore Ts'o'" , "Hallam-Baker, Phillip" Date: Fri, 11 Jul 2003 08:29:41 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Cc: "'problem-statement@alvestrand.no'" Subject: RE: Plenary decision? X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no > Phill, > > First of all, thank you writing a much calmer and much more thoughtful > e-mail. Your comments would be far more effective if you did not start off your message with an unnecessary ad-hominem attack. While your projections appear to demand a public response given your treatment of our private conversations, I will leave that to the end of the note to avoid boring the group. The empirical fact that you refuse to accept is that the IETF decision making process is failling to create a result in a timeframe that is acceptable to any of the stakeholders except for the IETF. Furthermore forums with alleged 'heavyweight' processes are making decisions far faster than the IETF can hope to. With XKMS we have gone from starting a WG to the end of last call in 2 years. The only IETF working group I am aware of that has managed that is BEEP, which regretably failled to actually gain buy in from the key stakeholders in the process and has consequently been undeployed. In fact it is signal that a proposal can make it through the entire IETF process without notice being taken of the important fact that the XML Web Services world is based on XML Schema and not DTD, failure to recognize that issue is the principal reason that the market is unlikely to even get to consider BEEP. The XKMS experience is not isolated however, it is the norm. SAML 1.0 was completed in 18 months, WS-Security has begun interop testing after 9 months. The main reason for this is not the process, it is the cycle time. In the IETF the cycle time is in effect four months, the time between IETF meetings. In the other processes the cycle time is two weeks, the time between con-calls. The longer cycle time in the IETF is leading to disengagement. I have not read the core PKIX document now for several years. I am not sure that anyone else in the company has either. Response to Ted's personal attack: It is a pity that you have chosen to disregard the traditional netiquette of not posting private conversations to a public list in the manner you did. Perhaps I would be able to reply in the calmer more thoughtful mode that you claim to aspire to if you could bring your own behavior to meet the accepted social norms. In the political arena I am more familiar with, posting a vehement denial that you have ambitions to hold a particular post is itself regarded as being an exceptionally ambitious move, particularly when that denial is intentionally brought to the notice of a much wider constituency From problem-statement-bounces@alvestrand.no Fri Jul 11 11:48:05 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04057 for ; Fri, 11 Jul 2003 11:48:04 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2F81C61BB5; Fri, 11 Jul 2003 17:47:36 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5838861BB2 for ; Fri, 11 Jul 2003 17:47:33 +0200 (CEST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h6BFlUN26184; Fri, 11 Jul 2003 11:47:31 -0400 (EDT) Date: Fri, 11 Jul 2003 11:47:30 -0400 From: Keith Moore To: problem-statement@alvestrand.no Message-Id: <20030711114730.0e8831f4.moore@cs.utk.edu> In-Reply-To: <2A1D4C86842EE14CA9BC80474919782E0D2313@mou1wnexm02.verisign.com> References: <2A1D4C86842EE14CA9BC80474919782E0D2313@mou1wnexm02.verisign.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: pbaker@verisign.com, moore@cs.utk.edu Subject: Re: Plenary decision? X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit > > Phill, > > > > First of all, thank you writing a much calmer and much more > > thoughtful e-mail. > > Your comments would be far more effective if you did not start off > your message with an unnecessary ad-hominem attack. I formally request that the WG chairs remove Phill's posting privileges for excessive and repeated abuse and off-topic postings. Keith From problem-statement-bounces@alvestrand.no Fri Jul 11 12:25:25 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04843 for ; Fri, 11 Jul 2003 12:25:24 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E8D6761BB5; Fri, 11 Jul 2003 18:24:55 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7ABEF61BB4 for ; Fri, 11 Jul 2003 18:24:54 +0200 (CEST) Received: from MOU1WNEXC03.verisign.com (verisign.com [65.205.251.57]) by peacock.verisign.com (8.12.9/) with ESMTP id h6BGOrch008611; Fri, 11 Jul 2003 09:24:53 -0700 (PDT) Received: by mou1wnexc03.verisign.com with Internet Mail Service (5.5.2653.19) id ; Fri, 11 Jul 2003 09:24:53 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E0D2317@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'Theodore Ts'o'" , "Hallam-Baker, Phillip" Date: Fri, 11 Jul 2003 09:24:52 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Cc: "'problem-statement@alvestrand.no'" Subject: RE: Plenary decision? X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Oops, sorry, I suddenly realize that I had misread the start of Ted's post to be the opposite of what he intended. My appologies. > -----Original Message----- > From: Theodore Ts'o [mailto:tytso@mit.edu] > Sent: Friday, July 11, 2003 10:36 AM > To: Hallam-Baker, Phillip > Cc: 'problem-statement@alvestrand.no' > Subject: Re: Plenary decision? > > > On Fri, Jul 11, 2003 at 05:32:38AM -0700, Hallam-Baker, Phillip wrote: > > I seem to recall raising the issue in a plenary. At no time was I > > aware that the plenary was the decision maker for the issue in > > question. > > > > This was I believe because of your reply 'There is a process", I > > remember that part of the reply because you neglected to say what > > the process was. > > > > So here we are in this forum and I find out that oh, the > plenary was the > > decision making body! > > Phill, > > First of all, thank you writing a much calmer and much more thoughtful > e-mail. > > It may very well be that that the IETF has grown too large for our > earlier, more informal mechanisms of governance. Just as in working > group chairs have the power to determine rough consensus, and are > charged with making good decisions about when there is rough > conensensus, and when people are raising technical objections of the > form, "it can't possibly work", versus "there are engineering > tradeoffs here, and I happen to strongly prefer door A over door B" > (where objections of the first kind must be taken care of as opposed > to objections of the second, which you try to reduce but ultimately is > not reduced down to zero because "rough consensus" doesn't mean > unanimity), at least in my view of the world, that's what the IESG is > charged with doing, on a larger scale for the entire IETF. > > This should be nothing new; it's in the TAO of the IETF, and in the > newcomer's briefing, but since you seem to be have some doubts about > what the process is, I thought it would be put it out explicitly. > > For questions like whether or not we use non-ASCII documents > exclusively, currently, the process is the RFC Editor decides, with > strong input/direction coming from the IAB and the IESG. On the other > hand, if they don't respect the community consensus, there are many > checks and balances, including (a) throwing the bums out, (b) the > appeals process, (c) simply going to other standards bodies. > > That being said, the topic of non-ASCII RFC's comes up every couple of > years, and at every IETF plenary that I can remember, the number of > people who come up to mike who bring up advantages of ASCII and > disadvantages of other formats generally run about four or five to one > in favor of ASCII. So I would argue that given the current decision > making process, the IESG did absolutely right thing. Furthermore, > even if we believed that democracy was a magic wand that automatically > produced technically superior standards, it seems pretty clear that > ASCII would probably win out. > > > If the plenary is a decision making body as you are > implying then why does > > it keep no minutes? > > > > It is possible that Harald is correct in his assertion, but > I find no > > record in the minutes because there arn't any. > > It is not a decision making body, but it is the best way of measuring > the general consensus of the community. Currently, we don't take > minutes, but rely on memories and the IESG to judge that consensus. > > Your complaints about the IETF's about process, and who are the > decision-making bodies, and your accusations of ruling cliques I think > goes to the heart of the matter, which is fundamentally one about how > we govern ourselves, and whether we should be using a very formal > process, or an informal one. > > I view this as an engineering tradeoff. There are certainly > advantages in using a very formal, structured meeting format where > decisions are made via votes and minutes and Robert's Rule of Order. > There are also advantages to using a system of judging rough consensus > and an appeals process as a check and balance. Both schemes also have > their disadvantages. > > Some people feel much more comfortable with standards bodies that use > a very formal process. Others have noted that in the past, bodies > that have gone down this past have sometimes gotten mired in > bureaucracies, and result in people (and large corporations) who are > really good at manipulated said process, but who are not necessarily > good at producing good technical results. Certainly there was a time > when our lightweight decision-making process was compared favorably to > the process used by ISO and more formal standards making bodies. It > is therefore ironic that one of the reasons why we're engaging in this > problem-statement process is because we seem to be falling prey to > many of the problems that we once caused a certain feeling of > superiority over these more formal standards bodies. > > Is the answer to become more like these formal standards bodies? That > seems to be what some people are suggesting. I am hoping though that > there is something about our process of rough consensus and running > code which is unique and better than a heavy-weight system based on > process and votes. That is, I hope that while we are fixing some very > real problems, that we don't end up throwing out the baby with the > bathwater. > > On the other hand, it may be that that real problem is that smaller > bodies are just naturally more lightweight (regardless of what scheme > of polity they use), and that growth inevitably causes problems. In > that case, the fact that some groups are trying out new standards > organizations might not necessarily be such a terrible thing. > > - Ted > From problem-statement-bounces@alvestrand.no Fri Jul 11 13:12:16 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06413 for ; Fri, 11 Jul 2003 13:12:15 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id F130961BB2; Fri, 11 Jul 2003 19:11:45 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from mtiwmhc11.worldnet.att.net (mtiwmhc11.worldnet.att.net [204.127.131.115]) by eikenes.alvestrand.no (Postfix) with ESMTP id 789C361BAE for ; Fri, 11 Jul 2003 19:11:43 +0200 (CEST) Received: from tsg1 (105.sanjose-08-09rs16rt.ca.dial-access.att.net[12.81.3.105]) by mtiwmhc11.worldnet.att.net (mtiwmhc11) with SMTP id <2003071117113911100qov19e>; Fri, 11 Jul 2003 17:11:41 +0000 Message-ID: <021b01c347cf$761cff00$020aff0a@tsg1> From: "todd glassey" To: "James Seng" , "Hallam-Baker, Phillip" References: <2A1D4C86842EE14CA9BC80474919782E0D230E@mou1wnexm02.verisign.com> <3F0E5816.7060207@pobox.org.sg> Date: Fri, 11 Jul 2003 10:07:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Cc: problem-statement@alvestrand.no, Keith Moore , "'Lars-Erik Jonsson (LU/EAB)'" Subject: Re: Fixed font v multiple fonts X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "James Seng" To: "Hallam-Baker, Phillip" Cc: ; "Keith Moore" ; "'Lars-Erik Jonsson (LU/EAB)'" Sent: Thursday, July 10, 2003 11:24 PM Subject: Re: Fixed font v multiple fonts > Just have another thought, altho I may be over-generalizing...but bear > with me for a moment. > > Some standard organisation achieve consensus by doing a UNION of the > ideas, ie, if A propose X and B propose Y, so long there is no conflict, > we put both X & Y into the standard. > > During voting, A dont object to Y if B dont object to X and vice versa > (aka horse trading). The results is that it _is_ possible to achieve > 100% consensus altho we have a bloated standard. > > IETF on the other hands prefers to do INTERSECTION of the ideas, ie, if > A propose X and B propose Y, we take only the intersection of the ideas > where there "rough consensus" and throw out those (from X or Y) that > have does not have rough consensus. The problem is that this intersection becomes the one and only possiblity from that WG and that is where the restraint of trade and possibly antitrust type effects come into the play. A standard is critical for business development, as evidenced by the funding of the IETF and the standards process by people like Cisco and MCI/WordCom, who would not spend what they spend on developing protocols in this arena... if there were no BizDev value. The problem is that for some of those that participate that this effort went into developing their own wares whcih was totally cool, the problem is that the otherside is true as well, that the same development process also supresses any other competeitve efforts. If you doubt this then look to the standards track documents and answer the following questions: 1) How is a compentitve standards vetted and where? 2) How does a competitive standard challange and retire another standard? becuase if its in the same WG and the original standard's owners (and I am not referring to the IETF here) are not interested in letting userp their effort, then there is NO POSSIBLE WAY to get any competitve standard through the IETF or into standardship. I am sorry, I have done the work-flow and there is just no possible way in reality to unseat any incumbant standard no matter what the really high level ideal states in the controlling documents. > > While this remove horse trading problem and gives us a leaner standards, > it also means we have to live with only very baseline standards, and in > some cases, everyone equally pissed too (aka distribution of pain). No - what it means is that the company for organization funding the most number of voices in any WG wins, and does so always... period. There is nothing left to say here but if you or anyone else can prove otherwise, then please do... > > Which is comes back to the topic of "ASCII text" vs "other fancy > document format". At this moment, we have rough consensus that ASCII > text, with its limitation, is useful for the IETF. OTOH, there is no > rough consensus for any other document format yet. (notice we doing > INTERSECTION of ideas). No it doesnt. The issues of ASCII text only only serve today to make it harder to participate and any person would agree to that. The world has not stood still and is now to much more visual systems than straight ASCII terminals and refusing to acknowledge that makes it harder for the average person to participate in the IETF's processes, and I put it to you that this is an intentional thing these days. In the beginning it (ASCII only) made sense as the greatest-common-denominator but not anymore, but this specific tact is used by any number of people to control how difficult to create and file a document it is. > > Should we also allow other document format? If no, why not? (And in > certain ways, people have absolute reasons to be angry). But if yes, are > we ready to change the way we do this? > > Or a higher level question: Is the current way we process ideas, ie, > taking only the parts which have rough consensus and leaving out those > that dont have, a problem? James - the consensus issues are a fundamental structural problem with the WG's and the Standards Process. I have pointed out other scatter-effects from the same 'methods' and their implementation above... in closing here, its important to note that theses are totally separate issues from the "how documents are presented" or filing requirements therein. > > -James Seng > > Hallam-Baker, Phillip wrote: > > >>Hallam-Baker, Phillip wrote: > >> > >>>Lars does not have the right to impose his decision on me. > > > > > > Lars is free to present his work as shoddily as he chooses. He is not free > > to impose his choices on me. > > > > > From problem-statement-bounces@alvestrand.no Fri Jul 11 14:18:11 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08995 for ; Fri, 11 Jul 2003 14:18:08 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 031C261BB2; Fri, 11 Jul 2003 20:17:38 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from HALVESTR-W2K1.cisco.com (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 787DC61BAE; Fri, 11 Jul 2003 20:17:36 +0200 (CEST) Date: Fri, 11 Jul 2003 20:17:36 +0200 From: Harald Tveit Alvestrand To: "Hallam-Baker, Phillip" , "'problem-statement@alvestrand.no'" Message-ID: <24391182.1057954656@[192.168.1.245]> In-Reply-To: <2A1D4C86842EE14CA9BC80474919782E0D230F@mou1wnexm02.verisign.com> References: <2A1D4C86842EE14CA9BC80474919782E0D230F@mou1wnexm02.verisign.com > X-Mailer: Mulberry/3.0.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: Plenary decision? X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit --On 11. juli 2003 05:32 -0700 "Hallam-Baker, Phillip" wrote: >> The closest thing we have is the IETF plenary. And it's been >> consistently *against* any particular proposed change to document >> formast. If you don't want to respect that - your choice. > > I seem to recall raising the issue in a plenary. At no time was I aware > that the plenary was the decision maker for the issue in question. > you snipped the text I was responding to. You said: >> As for rough consensus, the PROBLEM I am identifying is that there is >> simply no forum where the majority of the membership can give their views >> on the matter. I agree that the plenary is not a very good decision making body. But it IS the closest thing we have to a forum where the majority of the membership can give their views on the matter - and that was what I was saying. Harald From problem-statement-bounces@alvestrand.no Fri Jul 11 15:21:50 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12219 for ; Fri, 11 Jul 2003 15:21:47 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B431661BB4; Fri, 11 Jul 2003 21:21:15 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6FF6C61BB0; Fri, 11 Jul 2003 21:21:13 +0200 (CEST) Received: from BBFUJIP.brandenburg.com (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h6BJOsF31297; Fri, 11 Jul 2003 12:24:54 -0700 Date: Fri, 11 Jul 2003 21:21:51 +0200 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/11) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <19724295234.20030711212151@brandenburg.com> To: Harald Tveit Alvestrand In-Reply-To: <24391182.1057954656@[192\.168\.1\.245]> References: <2A1D4C86842EE14CA9BC80474919782E0D230F@mou1wnexm02.verisign.com > <24391182.1057954656@[192.168.1.245]> MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Cc: "'problem-statement@alvestrand.no'" Subject: Re: Plenary decision? X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Harald, >>> As for rough consensus, the PROBLEM I am identifying is that there is >>> simply no forum where the majority of the membership can give their views >>> on the matter. HTA> I agree that the plenary is not a very good decision making body. HTA> But it IS the closest thing we have to a forum where the majority of the HTA> membership can give their views on the matter - and that was what I was HTA> saying. YUP. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Fri Jul 11 15:36:00 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13570 for ; Fri, 11 Jul 2003 15:35:58 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CD75B61BB4; Fri, 11 Jul 2003 21:35:26 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by eikenes.alvestrand.no (Postfix) with ESMTP id 456E761BB0; Fri, 11 Jul 2003 21:35:24 +0200 (CEST) Received: from mou1wnexc02.verisign.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.9/) with ESMTP id h6BJZNch012655; Fri, 11 Jul 2003 12:35:23 -0700 (PDT) Received: by mou1wnexc02.verisign.com with Internet Mail Service (5.5.2653.19) id <3XFYV9M0>; Fri, 11 Jul 2003 12:35:23 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E0D2319@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'Harald Tveit Alvestrand'" , "Hallam-Baker, Phillip" , "'problem-statement@alvestrand.no'" Date: Fri, 11 Jul 2003 12:35:21 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Plenary decision? X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no I am confused, are we in agreement here that there is no body that is competent to decide this issue or not? You seem to be arguing here that the plenary is not the appropriate forum to discuss the issue, but that its 'decision' on the matter should be respected even though nobody was aware that there was any decision being made. What I am looking for is an open process. I do not see one. And I do not think that the problem in this case is my dyslexia although that is the reason why I choose this particular substantive issue rather than another. > -----Original Message----- > From: Harald Tveit Alvestrand [mailto:harald@alvestrand.no] > Sent: Friday, July 11, 2003 2:18 PM > To: Hallam-Baker, Phillip; 'problem-statement@alvestrand.no' > Subject: Re: Plenary decision? > > > > > --On 11. juli 2003 05:32 -0700 "Hallam-Baker, Phillip" > wrote: > > >> The closest thing we have is the IETF plenary. And it's been > >> consistently *against* any particular proposed change to document > >> formast. If you don't want to respect that - your choice. > > > > I seem to recall raising the issue in a plenary. At no time > was I aware > > that the plenary was the decision maker for the issue in question. > > > > you snipped the text I was responding to. > > You said: > >> As for rough consensus, the PROBLEM I am identifying is > that there is > >> simply no forum where the majority of the membership can > give their views > >> on the matter. > > I agree that the plenary is not a very good decision making body. > But it IS the closest thing we have to a forum where the > majority of the > membership can give their views on the matter - and that was > what I was > saying. > > Harald > > > > From problem-statement-bounces@alvestrand.no Fri Jul 11 17:31:25 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18048 for ; Fri, 11 Jul 2003 17:31:24 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 40B7661BB5; Fri, 11 Jul 2003 23:30:55 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from thunker.thunk.org (thunk.org [140.239.227.29]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5617B61BB0; Fri, 11 Jul 2003 23:30:53 +0200 (CEST) Received: from [32.97.110.142] (helo=think.thunk.org) authenticated as tytso by thunker.thunk.org with asmtp (tls_cipher TLSv1:DES-CBC3-SHA:168) (Exim 3.35 #1 (Debian)) id 19b5Tb-0001rz-00; Fri, 11 Jul 2003 17:30:48 -0400 Received: from tytso authenticated as tytso by think.thunk.org with local (Exim 3.35 #1 (Debian)) id 19b5Tb-0001Gh-00; Fri, 11 Jul 2003 17:30:47 -0400 Date: Fri, 11 Jul 2003 17:30:47 -0400 From: "Theodore Ts'o" To: "Hallam-Baker, Phillip" Message-ID: <20030711213047.GB4249@think> References: <2A1D4C86842EE14CA9BC80474919782E0D2319@mou1wnexm02.verisign.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2A1D4C86842EE14CA9BC80474919782E0D2319@mou1wnexm02.verisign.com> User-Agent: Mutt/1.5.4i Cc: "'Harald Tveit Alvestrand'" , "'problem-statement@alvestrand.no'" Subject: Re: Plenary decision? X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no On Fri, Jul 11, 2003 at 12:35:21PM -0700, Hallam-Baker, Phillip wrote: > I am confused, are we in agreement here that there is no body that > is competent to decide this issue or not? > > You seem to be arguing here that the plenary is not the appropriate > forum to discuss the issue, but that its 'decision' on the matter > should be respected even though nobody was aware that there was > any decision being made. > > What I am looking for is an open process. I do not see one. The plenary is the appropriate place to discuss the issue, and in fact it represent a particular equine that has been bludgeoned to death many times before, and will no doubt be bludgeoned to death many times in the future. As I said, I can't remember a time when the people present who went up to mike to defend ASCII numbered less than at least 3 times number of people who wanted to use some propietary (i.e., MS Word) or non-editable (i.e., Postscript) formats. Of course, the tools and formats keep changing, and although I personally find Docbook to be infuriating because the tools all suck, at least there are some open formats that actually have some promise of providing better formatting for people who are must have pretty-printed standards. So certainly it's fair to hold repeat equinocides from time to time. The current process is that the IETF leadership takes the input from the plenary, and cogitates on it, and based on their determination of community consensus, takes action. Is it open? It depends on your definition of "open", I suppose. No one took votes, so if a democratic approach is the only way of determining openness, I suppose it wasn't open. However, there certainly was an opportunity to gether community input, and at least in this case, I believe the overwhelming community input was indeed respected. So the question is whether or not the way this particular issue turned out is a reason to indict the current process. I don't think it is. Give what I've seen of the people who have expressed their views at the microphone, if we had a vote, it probably would have been decisively in favor of ASCII. - Ted From problem-statement-bounces@alvestrand.no Fri Jul 11 19:14:59 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23681 for ; Fri, 11 Jul 2003 19:14:58 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 944DF61BB9; Sat, 12 Jul 2003 01:14:30 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by eikenes.alvestrand.no (Postfix) with ESMTP id 82BA661BB4; Sat, 12 Jul 2003 01:14:28 +0200 (CEST) Received: from mou1wnexc02.verisign.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.9/) with ESMTP id h6BNERch013601; Fri, 11 Jul 2003 16:14:27 -0700 (PDT) Received: by mou1wnexc02.verisign.com with Internet Mail Service (5.5.2653.19) id <3XFYWK76>; Fri, 11 Jul 2003 16:14:27 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E0D231B@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'Theodore Ts'o'" , "Hallam-Baker, Phillip" Date: Fri, 11 Jul 2003 16:14:23 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Cc: "'Harald Tveit Alvestrand'" , "'problem-statement@alvestrand.no'" Subject: RE: Plenary decision? X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no > As I said, I can't remember a time when the people > present who went up to mike to defend ASCII numbered less than at > least 3 times number of people who wanted to use some propietary > (i.e., MS Word) or non-editable (i.e., Postscript) formats. This is a straw man. HTML is a completely open format. If you use XHTML and define the schema appropriately you can easily verify that no proprietary extensions have been used. Alternatively there are plenty of tools to verify against a DTD. Phill From problem-statement-bounces@alvestrand.no Fri Jul 11 20:29:51 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27289 for ; Fri, 11 Jul 2003 20:29:50 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8FE6061BB2; Sat, 12 Jul 2003 02:29:20 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from HALVESTR-W2K1.cisco.com (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CBE2B61BB0 for ; Sat, 12 Jul 2003 02:29:18 +0200 (CEST) Date: Sat, 12 Jul 2003 02:29:13 +0200 From: Harald Tveit Alvestrand To: problem-statement@alvestrand.no Message-ID: <46687583.1057976953@localhost> X-Mailer: Mulberry/3.0.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Resolution of my issues raised on the -problem- document X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit I have read through the -problem- document, version -02, and compared it to the issues I raised on -01. I am satisfied that the issues I raised have been resolved. Thanks a lot, both to the editors and those who helped clarify and resolve the issues on the mailing list! Harald From problem-statement-bounces@alvestrand.no Sat Jul 12 10:29:53 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20920 for ; Sat, 12 Jul 2003 10:29:53 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9CE9D61BB4; Sat, 12 Jul 2003 16:29:23 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by eikenes.alvestrand.no (Postfix) with ESMTP id 508BE61BB4 for ; Sat, 12 Jul 2003 16:29:21 +0200 (CEST) Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e31.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h6CETJu8141792 for ; Sat, 12 Jul 2003 10:29:19 -0400 Received: from cichlid.adsl.duke.edu (sig-9-65-225-104.mts.ibm.com [9.65.225.104]) by westrelay01.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h6CETImS061344 for ; Sat, 12 Jul 2003 08:29:18 -0600 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id h6CERsC07562 for ; Sat, 12 Jul 2003 10:27:54 -0400 Message-Id: <200307121427.h6CERsC07562@cichlid.adsl.duke.edu> To: problem-statement@alvestrand.no In-Reply-To: Message from dhc@dcrocker.net of "Fri, 04 Jul 2003 19:31:50 +0200." <33367111668.20030704193150@brandenburg.com> Date: Sat, 12 Jul 2003 10:27:54 -0400 From: Thomas Narten Subject: Re: appeal mechanisms was Re: Ombuds-process X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no FYI, as an example of an actual appeal, here is a recent appeal the Internet ADs responded to. http://www.cs.duke.edu/~narten/ietf/sl-appeal-resp.txt From problem-statement-bounces@alvestrand.no Sat Jul 12 11:13:06 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22800 for ; Sat, 12 Jul 2003 11:13:05 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 88F9461BB3; Sat, 12 Jul 2003 17:12:36 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from d12lmsgate-5.de.ibm.com (d12lmsgate-5.de.ibm.com [194.196.100.238]) by eikenes.alvestrand.no (Postfix) with ESMTP id D431361BB2 for ; Sat, 12 Jul 2003 17:12:34 +0200 (CEST) Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by d12lmsgate-5.de.ibm.com (8.12.9/8.12.8) with ESMTP id h6CFCWu5033412 for ; Sat, 12 Jul 2003 17:12:33 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h6CFCXjR244400 for ; Sat, 12 Jul 2003 17:12:33 +0200 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id RAA53892; Sat, 12 Jul 2003 17:12:26 +0200 Message-ID: <3F102563.23FE0DF2@hursley.ibm.com> Date: Sat, 12 Jul 2003 17:12:35 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Thomas Narten References: <200307121427.h6CERsC07562@cichlid.adsl.duke.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: appeal mechanisms was Re: Ombuds-process X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit I think we do have a problem of lack of systematic archiving and announcing of appeals and responses. Brian Thomas Narten wrote: > > FYI, as an example of an actual appeal, here is a recent appeal the > Internet ADs responded to. > > http://www.cs.duke.edu/~narten/ietf/sl-appeal-resp.txt From problem-statement-bounces@alvestrand.no Sat Jul 12 11:26:23 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23378 for ; Sat, 12 Jul 2003 11:26:23 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3409861BB4; Sat, 12 Jul 2003 17:25:54 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0A21261BB2 for ; Sat, 12 Jul 2003 17:25:53 +0200 (CEST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6CFPqk28495 for ; Sat, 12 Jul 2003 18:25:52 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sat, 12 Jul 2003 18:25:52 +0300 Received: from esebe007.NOE.Nokia.com ([172.21.138.47]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Sat, 12 Jul 2003 18:25:51 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe007.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Sat, 12 Jul 2003 18:25:50 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sat, 12 Jul 2003 18:25:48 +0300 Message-ID: Thread-Topic: appeal mechanisms was Re: Ombuds-process Thread-Index: AcNIiAtRKl/bbEdJSyKd5AWyShWvKgAAbMTA From: To: , X-OriginalArrivalTime: 12 Jul 2003 15:25:50.0882 (UTC) FILETIME=[E0632820:01C34889] Cc: problem-statement@alvestrand.no Subject: RE: appeal mechanisms was Re: Ombuds-process X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: quoted-printable Brian, I agree - I think we should file it as an issue & suggest text. John > -----Original Message----- > From: ext Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: 12 July, 2003 18:13 > To: Thomas Narten > Cc: problem-statement@alvestrand.no > Subject: Re: appeal mechanisms was Re: Ombuds-process >=20 >=20 > I think we do have a problem of lack of systematic archiving=20 > and announcing of appeals and responses. >=20 > Brian >=20 > Thomas Narten wrote: > >=20 > > FYI, as an example of an actual appeal, here is a recent appeal the > > Internet ADs responded to. > >=20 > > http://www.cs.duke.edu/~narten/ietf/sl-appeal-resp.txt >=20 From problem-statement-bounces@alvestrand.no Sat Jul 12 12:57:24 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27413 for ; Sat, 12 Jul 2003 12:57:23 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E15BF61BB5; Sat, 12 Jul 2003 18:56:54 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by eikenes.alvestrand.no (Postfix) with ESMTP id 94A2C61BB3; Sat, 12 Jul 2003 18:56:52 +0200 (CEST) Received: from BBFUJIP.brandenburg.com (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h6CH0VF19042; Sat, 12 Jul 2003 10:00:31 -0700 Date: Sat, 12 Jul 2003 18:57:32 +0200 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/11) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <186102036600.20030712185732@brandenburg.com> To: "Hallam-Baker, Phillip" In-Reply-To: <2A1D4C86842EE14CA9BC80474919782E0D231B@mou1wnexm02.verisign.com> References: <2A1D4C86842EE14CA9BC80474919782E0D231B@mou1wnexm02.verisign.com> MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Cc: "'Harald Tveit Alvestrand'" , "'Theodore Ts'o'" , "'problem-statement@alvestrand.no'" Subject: Re: Plenary decision? X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list Reply-To: Dave Crocker List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Phillip, Like most things, what matters is the detail. Feel free to put together a formal specification of the formatting rules to be following, including character sets, format control constructs, etc. Since you say that all the necessary stuff already exists and is readily available, I'm sure your specification document will be quite short. However, in case you have not noticed, "HTML" is an ambiguous reference. Clearly anything specified for IETF documents must be precise and easily usable by the broadest audience possible. This includes text searchable, of course. In order to ensure ease of adoption and use, you should also consider including citations to the open tools that are readily available, for generating conformant documents, as well as tools for any other support functions that will make users happy with it. Until then, this debate is like so many other technical discussions in the IETF, where folks debate concepts, utterly ignoring the concrete details and minor matters of usability. d/ ps. Folks, until we see a specification for an alternative format, could we please constrain discussion of this topic to a recitation of the requirements. Having to repeat this debate every few years seems rather wasteful. HBP> This is a straw man. HTML is a completely open format. HBP> If you use XHTML and define the schema appropriately you can HBP> easily verify that no proprietary extensions have been used. HBP> Alternatively there are plenty of tools to verify against a DTD. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Sat Jul 12 18:22:13 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15887 for ; Sat, 12 Jul 2003 18:22:12 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 21A6961BB5; Sun, 13 Jul 2003 00:21:44 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from gull.mail.pas.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by eikenes.alvestrand.no (Postfix) with ESMTP id CCE5F61BB3 for ; Sun, 13 Jul 2003 00:21:42 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by gull.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19bSkL-0005he-00; Sat, 12 Jul 2003 15:21:37 -0700 Date: Sat, 12 Jul 2003 14:18:50 -0400 From: Keith Moore To: Dave Crocker Message-Id: <20030712141850.35422f0b.moore@cs.utk.edu> In-Reply-To: <186102036600.20030712185732@brandenburg.com> References: <2A1D4C86842EE14CA9BC80474919782E0D231B@mou1wnexm02.verisign.com> <186102036600.20030712185732@brandenburg.com> X-Mailer: Sylpheed version 0.9.1 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Whether HTML RFCs (was: Re: Plenary decision?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit ] Like most things, what matters is the detail. Feel free to put together ] a formal specification of the formatting rules to be following, ] including character sets, format control constructs, etc. Since you say ] that all the necessary stuff already exists and is readily available, ] I'm sure your specification document will be quite short. http://www.cs.utk.edu/~moore/opinions/whether-rfcs-in-html.html From problem-statement-bounces@alvestrand.no Sat Jul 12 19:28:06 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19766 for ; Sat, 12 Jul 2003 19:28:06 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0205D61BD6; Sun, 13 Jul 2003 01:27:38 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5D37C61BB5 for ; Sun, 13 Jul 2003 01:27:36 +0200 (CEST) Received: from ala-mrwtemp.windriver.com ([147.11.233.21]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id QAA05478; Sat, 12 Jul 2003 16:27:16 -0700 (PDT) Message-Id: <5.1.0.14.2.20030712192408.01b552c0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 12 Jul 2003 19:26:35 -0400 To: From: Margaret Wasserman In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: narten@us.ibm.com, problem-statement@alvestrand.no, brian@hursley.ibm.com Subject: RE: appeal mechanisms was Re: Ombuds-process X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Not to pick on John but... At 06:25 PM 7/12/2003 +0300, john.loughney@nokia.com wrote: >I agree - I think we should file it as an issue & suggest text. Where would you "file" this issue (about not having a common web repository for appeals/responses?)... It really doesn't belong in the problem statement, because I don't think anyone would argue that this issue is a serious, root cause problem facing the IETF... The same goes for a lot of other "issues" that have been raised on this list. In this case, it would probably take longer to document this problem than to fix it... Margaret From problem-statement-bounces@alvestrand.no Sun Jul 13 01:42:51 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11755 for ; Sun, 13 Jul 2003 01:42:51 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BB0B461BB2; Sun, 13 Jul 2003 07:42:20 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from sentosa.post1.com (sentosa.post1.com [202.27.17.100]) by eikenes.alvestrand.no (Postfix) with SMTP id 9A40C61AA5 for ; Sun, 13 Jul 2003 07:42:16 +0200 (CEST) Received: (qmail 35539 invoked from network); 13 Jul 2003 05:47:44 -0000 Received: from james-fujitsu.ietf57.telekom.at (HELO pobox.org.sg) (81.160.180.148) by sentosa.post1.com with SMTP; 13 Jul 2003 05:47:44 -0000 Message-ID: <3F10F127.5070801@pobox.org.sg> Date: Sun, 13 Jul 2003 13:41:59 +0800 From: James Seng User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en, zh-cn, zh-tw, ja, ko MIME-Version: 1.0 To: todd glassey References: <2A1D4C86842EE14CA9BC80474919782E0D230E@mou1wnexm02.verisign.com> <3F0E5816.7060207@pobox.org.sg> <021b01c347cf$761cff00$020aff0a@tsg1> In-Reply-To: <021b01c347cf$761cff00$020aff0a@tsg1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Keith Moore , problem-statement@alvestrand.no, "Hallam-Baker, Phillip" , "'Lars-Erik Jonsson (LU/EAB)'" Subject: Re: Fixed font v multiple fonts X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Todd, IETF function on two core principles: running codes & rough consensus. If you think that rough consensus is a fundamental problem, I suggest you start looking for an alt. organization to do your work. There are many other groups with what your perspection of the world should be. -James Seng todd glassey wrote: > James - the consensus issues are a fundamental structural problem with the > WG's and the Standards Process. I have pointed out other scatter-effects > from the same 'methods' and their implementation above... in closing here, > its important to note that theses are totally separate issues from the "how > documents are presented" or filing requirements therein. > From problem-statement-bounces@alvestrand.no Sun Jul 13 02:57:17 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27648 for ; Sun, 13 Jul 2003 02:57:16 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0BFE261BB9; Sun, 13 Jul 2003 08:56:47 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from cichlid.adsl.duke.edu (unknown [81.160.15.26]) by eikenes.alvestrand.no (Postfix) with ESMTP id BBC3061BB5 for ; Sun, 13 Jul 2003 08:56:44 +0200 (CEST) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id h6D6u3b16391; Sun, 13 Jul 2003 08:56:04 +0200 Message-Id: <200307130656.h6D6u3b16391@cichlid.adsl.duke.edu> To: Keith Moore In-Reply-To: Message from moore@cs.utk.edu of "Sat, 12 Jul 2003 14:18:50 EDT." <20030712141850.35422f0b.moore@cs.utk.edu> Date: Sun, 13 Jul 2003 08:56:03 +0200 From: Thomas Narten Cc: Dave Crocker , problem-statement@alvestrand.no Subject: Re: Whether HTML RFCs (was: Re: Plenary decision?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Another document folk interested in this topic might want to review is is: http://www.cs.columbia.edu/~hgs/tmp/rfc.txt Internet Engineering Task Force Internet Draft Schulzrinne schulzrinne-rfc-00.txt Columbia U. September 3, 2000 Expires: January 2001 Suggestions for Future Document Format Requirements for RFCs and Internet Drafts Abstract A dwindling fraction of authors of I-Ds and RFCs are still fluent in nroff, the official input format for RFCs. With the use of other tools, the consistency and layout quality of RFCs and I-Ds has suffered. Printing, hyperlinking and viewing of ASCII documents are unsatisfactory. In this document, we investigate how the I-D and RFC series can be upgraded in usability while maintaining stability, longevity and cross-platform abilities that have been hallmarks of the RFC series. 6 Acknowledgements This document attempts to summarize the discussion on the IAB, wg- chairs and IESG mailing lists that took place during August 2000. Any misrepresentations are the fault of the author. From problem-statement-bounces@alvestrand.no Sun Jul 13 10:06:59 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22921 for ; Sun, 13 Jul 2003 10:06:59 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id AB7D161BED; Sun, 13 Jul 2003 16:06:29 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from HALVESTR-W2K1.cisco.com (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B909D61AD5; Sun, 13 Jul 2003 16:06:28 +0200 (CEST) Date: Sun, 13 Jul 2003 15:49:45 +0200 From: Harald Tveit Alvestrand To: Margaret Wasserman Message-ID: <181120207.1058111385@localhost> In-Reply-To: <5.1.0.14.2.20030712192408.01b552c0@mail.windriver.com> References: <5.1.0.14.2.20030712192408.01b552c0@mail.windriver.com> X-Mailer: Mulberry/3.0.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: problem-statement@alvestrand.no Subject: RE: appeal mechanisms was Re: Ombuds-process X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit --On 12. juli 2003 19:26 -0400 Margaret Wasserman wrote: > > Not to pick on John but... > > At 06:25 PM 7/12/2003 +0300, john.loughney@nokia.com wrote: >> I agree - I think we should file it as an issue & suggest text. > > Where would you "file" this issue (about not having a common > web repository for appeals/responses?)... > > It really doesn't belong in the problem statement, because > I don't think anyone would argue that this issue is a serious, > root cause problem facing the IETF... The same goes for a > lot of other "issues" that have been raised on this list. > > In this case, it would probably take longer to document this > problem than to fix it... it belongs under "routine stuff that the IESG needs to handle, but where the IETF as such doesn't need to do anything". We've got running archives now of IESG appeals and responses and IAB appeals and responses; if we need AD appeals and responses, we can make that happen too. Recovering history is a problem. But I don't think that's something that has a huge impact on the future of the IETF. Harald From problem-statement-bounces@alvestrand.no Sun Jul 13 17:00:33 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05622 for ; Sun, 13 Jul 2003 17:00:32 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3F9A161B8C; Sun, 13 Jul 2003 23:00:03 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from znsgs01r.nortelnetworks.com (h33s128a211n47.user.nortelnetworks.com [47.211.128.33]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7CBDE61B83; Sun, 13 Jul 2003 23:00:01 +0200 (CEST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.160.46.124]) by znsgs01r.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h6DKxw322123; Sun, 13 Jul 2003 21:59:58 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sun, 13 Jul 2003 21:59:58 +0100 Message-ID: <4103264BC8D3D51180B7002048400C450162355E@zhard0jd.europe.nortel.com> From: "Elwyn Davies" To: "'Harald Tveit Alvestrand'" , problem-statement@alvestrand.no Date: Sun, 13 Jul 2003 21:59:58 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C34981.83BA459C" Subject: RE: Resolution of my issues raised on the -problem- document X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C34981.83BA459C Content-Type: text/plain; charset="iso-8859-1" Excellent - Thanks for the review. I am looking to see what if any open issues there are still to cover and will be mailing my views shortly. Regards, Elwyn > -----Original Message----- > From: Harald Tveit Alvestrand [mailto:harald@alvestrand.no] > Sent: 12 July 2003 01:29 > To: problem-statement@alvestrand.no > Subject: Resolution of my issues raised on the -problem- document > > > I have read through the -problem- document, version -02, and > compared it to > the issues I raised on -01. > > I am satisfied that the issues I raised have been resolved. > Thanks a lot, both to the editors and those who helped > clarify and resolve > the issues on the mailing list! > > Harald > > ------_=_NextPart_001_01C34981.83BA459C Content-Type: text/html; charset="iso-8859-1" RE: Resolution of my issues raised on the -problem- document

Excellent - Thanks for the review.

I am looking to see what if any open issues there are still to cover and will be mailing my views shortly.

Regards,
Elwyn

> -----Original Message-----
> From: Harald Tveit Alvestrand [mailto:harald@alvestrand.no]
> Sent: 12 July 2003 01:29
> To: problem-statement@alvestrand.no
> Subject: Resolution of my issues raised on the -problem- document
>
>
> I have read through the -problem- document, version -02, and
> compared it to
> the issues I raised on -01.
>
> I am satisfied that the issues I raised have been resolved.
> Thanks a lot, both to the editors and those who helped
> clarify and resolve
> the issues on the mailing list!
>
>                  Harald
>
>

------_=_NextPart_001_01C34981.83BA459C-- From problem-statement-bounces@alvestrand.no Sun Jul 13 20:22:51 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09602 for ; Sun, 13 Jul 2003 20:22:50 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9E97961B8D; Mon, 14 Jul 2003 02:22:20 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from mtiwmhc13.worldnet.att.net (mtiwmhc13.worldnet.att.net [204.127.131.117]) by eikenes.alvestrand.no (Postfix) with ESMTP id DF47661B8C for ; Mon, 14 Jul 2003 02:22:18 +0200 (CEST) Received: from tsg1 (unknown[12.81.8.203]) by mtiwmhc13.worldnet.att.net (mtiwmhc13) with SMTP id <20030714002215113009v2rqe>; Mon, 14 Jul 2003 00:22:16 +0000 Message-ID: <005801c3499d$e57e2b10$020aff0a@tsg1> From: "todd glassey" To: "James Seng" References: <2A1D4C86842EE14CA9BC80474919782E0D230E@mou1wnexm02.verisign.com> <3F0E5816.7060207@pobox.org.sg> <021b01c347cf$761cff00$020aff0a@tsg1> <3F10F127.5070801@pobox.org.sg> Date: Sun, 13 Jul 2003 15:04:09 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Cc: Keith Moore , problem-statement@alvestrand.no, "Hallam-Baker, Phillip" , "'Lars-Erik Jonsson (LU/EAB)'" Subject: Re: Fixed font v multiple fonts X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit No James - the IETF runs on the words Open and Fair. Read them as they apply to the Standards processes as per SS 1.2 of RFC2026 and the words in SS9 as well. These two simple words are the most important ones because they constrain how all of the other processes and methods of the IETF' are to be, no MUST be done, whether you interpret them as adverbs or adjectives. Either way meeting their mandate forces the form of all other processes. Not observing this requirement invalidates the entirety of the IETF's process, and it simply becomes a place where the person or organization with the most hand to count wins. Todd ----- Original Message ----- From: "James Seng" To: "todd glassey" Cc: "Hallam-Baker, Phillip" ; ; "Keith Moore" ; "'Lars-Erik Jonsson (LU/EAB)'" Sent: Saturday, July 12, 2003 10:41 PM Subject: Re: Fixed font v multiple fonts > Todd, > > IETF function on two core principles: running codes & rough consensus. > > If you think that rough consensus is a fundamental problem, I suggest > you start looking for an alt. organization to do your work. There are > many other groups with what your perspection of the world should be. > > -James Seng > > todd glassey wrote: > > > James - the consensus issues are a fundamental structural problem with the > > WG's and the Standards Process. I have pointed out other scatter-effects > > from the same 'methods' and their implementation above... in closing here, > > its important to note that theses are totally separate issues from the "how > > documents are presented" or filing requirements therein. > > > From problem-statement-bounces@alvestrand.no Mon Jul 14 02:18:02 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27013 for ; Mon, 14 Jul 2003 02:18:01 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5831461B8F; Mon, 14 Jul 2003 08:17:30 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by eikenes.alvestrand.no (Postfix) with ESMTP id 64C0961B8C; Mon, 14 Jul 2003 08:17:28 +0200 (CEST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6E6HRk22387; Mon, 14 Jul 2003 09:17:27 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 14 Jul 2003 09:17:27 +0300 Received: from esebe020.NOE.Nokia.com ([172.21.138.59]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 14 Jul 2003 09:17:26 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe020.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 14 Jul 2003 09:17:25 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 14 Jul 2003 09:17:25 +0300 Message-ID: Thread-Topic: appeal mechanisms was Re: Ombuds-process Thread-Index: AcNJR/eNloCRvSWhQS+1UEdWT6l/MgAg2PZw From: To: , X-OriginalArrivalTime: 14 Jul 2003 06:17:25.0703 (UTC) FILETIME=[9832CD70:01C349CF] Cc: problem-statement@alvestrand.no Subject: RE: appeal mechanisms was Re: Ombuds-process X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: quoted-printable Hi Harald & Margaret, > > Not to pick on John but... > > > > At 06:25 PM 7/12/2003 +0300, john.loughney@nokia.com wrote: > >> I agree - I think we should file it as an issue & suggest text. > > > > Where would you "file" this issue (about not having a common > > web repository for appeals/responses?)... > > > > It really doesn't belong in the problem statement, because > > I don't think anyone would argue that this issue is a serious, > > root cause problem facing the IETF... The same goes for a > > lot of other "issues" that have been raised on this list. > > > > In this case, it would probably take longer to document this > > problem than to fix it... I agree, I think that the problem documents are about ready for last = call, I don't think we want to drag this out too long - we should be=20 working on solutions. > it belongs under "routine stuff that the IESG needs to handle, but = where=20 > the IETF as such doesn't need to do anything". I agree. However, is there any place to to discuss / request such = things? John > We've got running archives now of IESG appeals and responses and IAB=20 > appeals and responses; if we need AD appeals and responses,=20 > we can make that happen too. Recovering history is a problem. But I=20 > don't think that's something that has a huge impact on the future of = the IETF. >=20 > Harald >=20 >=20 From problem-statement-bounces@alvestrand.no Mon Jul 14 02:28:00 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27820 for ; Mon, 14 Jul 2003 02:27:58 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0F98561B8E; Mon, 14 Jul 2003 08:27:28 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from znsgs01r.nortelnetworks.com (h33s128a211n47.user.nortelnetworks.com [47.211.128.33]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4CA1261B8C for ; Mon, 14 Jul 2003 08:27:26 +0200 (CEST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.160.46.124]) by znsgs01r.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h6E6ROi24777 for ; Mon, 14 Jul 2003 07:27:25 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 14 Jul 2003 07:27:25 +0100 Message-ID: <4103264BC8D3D51180B7002048400C4503631A9F@zhard0jd.europe.nortel.com> From: "Elwyn Davies" To: problem-statement@alvestrand.no Date: Mon, 14 Jul 2003 07:27:24 +0100 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: Open Issues/State of Play for issues draft (v02) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Hi. Looking at the document (draft-ietf-problem-issue-statement-02.txt) and the traffic on the mailing since this document went to the I-D editor, I believe that the following eight items may need to be updated or added to incorporate the discussions that were in progress at 30 June or have surfaced since: --------------------------------- Mailing list discussion: Further traffic on 'ISSUE: Determinants for timeliness in Section 2.1' This discussion centres on managing coordination and dependencies between the work of different WGs (including ensuring that dependencies between charters are appropriate and clearly understood by all parties). This appears to be a further manifestation of the problem documented in 2.3 relating the poor handling of large and complex problems. I suggest that the points could be summarised by modifying the following bullet point in 2.3: o The IETF does not posess effective formal mechanisms for inter-WG cooperation or communication. as follows o The IETF does not posess effective formal mechanisms for inter-WG cooperation, coordination or communication, including the handling of dependencies between the deliverables and processes specified in WG charters. ---------------------------------------- Ongoing mailing list discussion/Document drop-off: 'Re: appeal mechanisms was Re: Ombuds-process' Due to finger trouble during last minute editing the intended body of the section which addressed this problem was omitted. The intended text that follows appears to document the issue as it has been discussed: 2.6.8 Difficulty making technical and process appeals When an individual thinks that the process has produced a result that is harmful to the Internet or thinks that IETF processes have not been adhered to, there is no mechanism to aid that individual in seeking to change that result. ----------------------------------------- Further discussion of: 'Re: The need for smaller protocol specifications' This appears to be covered by the last para in section 2.3 and the second bullet point in 2.4, but a few extra words may be needed. Views? ----------------------------------------- Mailing list discussion: 'ADs who are also WG chairs' Potential open issue: Are 'barriers to concensus formation' adequately covered? This thread has strayed considerably from its ostensible title, which is covered fully by the discussion in the last para of section 2.6.6. The later discussions which appear to be about other consequences of the concentration of influence are, I believe, covered - so far as the problem at issue is concerned, as opposed to a solution to the problems - by section 2.6.6. It appears to me that the thread does not actually offer any concrete evidence that resolving the philsophical objection to the current 'rough concensus determined by WG chairs' mode of operation (by replacing it by some 'more democratic' process) would actually improve the quality, take up or timeliness of IETF standards. So, I don't think that it is proved that lack of democracy is a root cause problem, but that does not mean that some or all of the points made should not be considered when solutions are being considered. Accordingly I don't think we need to change the issues document in this direction. However it is possible that the coverage of problems with the WG concensus process is inadequate. The points raised by John Klensin in a thread started back on 7 March regarding ways in which the conscensus process can be subverted by off topic mail storms leading to concensus by exhaustion, effective exclusion of knowledgeable participants and unrepresentative solutions, may not be adequately covered. Views? ------------------------------------------ Mailing list discussion: MAJOR ISSUE: Causes of "problems" The original thrust of this issue is that the expansion of scope of the IETF's problem domain may be in itself a problem. This appears to be discussed right at the start of section 1 and section 2.1 notes as a problem that the IETF doesn't actually know what its scope ought to be at present. The problem of the space having got larger seems (IMHO) to pervade several of the succeeding issues, and I would therefore take the view that no further action is needed. ------------------------------------------- Mailing list discussion: 'Accommodating ESL speakers' This point is mentioned in section 2.6.6 as part of the matters that conspire to leave influence concentrated in too few hands. It should probably also be mentioned in the discussion of education in seection 2.8: Participants should be made aware that they are not just talking to mother tongue English speakers with a North American (esp. US) cultural outlook, and given guidance in how best to make their presentations comprehensible to the largest number of participants. ------------------------------------------- Mailing list discussion: 'Fixed font vs multiple fonts' etc The much flogged and thoroughly mortified equine of alternatives to ASCII documents has once again been resurrected and subjected to yet another painful and humiliating death. [Sorry: There has been yet another attempt to reopen the ASCII document decision without compelling new evidence of a wrong decision.] I think the discussion makes it clear that this is not a root cause of any problems that currently beset the IETF. However, there do seem to be a couple of points that might be considered as part of process improvement: 1. The archival format is effectively the final ASCII document rather than the original source which would be needed to recreate the document or form the basis of a revised version - at one point documents were almost all derived from nroff sources and could be submitted in this form (I seem to remember). I don't know if the RFC editor keeps these versions in case of later need (when maybe the original editor is no longer contactable, or has lost the sources), but this has become irrelevant when many documents are originated in different ways, in formats that are not acceptable to the I-D or RFC editors. So the RFC archives are based on a format which is not easily re-editable. This does not appear to be good engineering practice. Marshall Rose's XML format seems to be a good start on a new re-editable format whilst still being all ASCII and having many of the good characteristics of the old nroff format plus providing semantic clues which make generation of derivative documents and alternative formatting reasonably easy. [HTML as an archival format is much less good than nroff - no semantics and uncertainty about tag meanings. Word is a total non-starter because there is little guarantee of backwards compatibility apart from anything else.] 2. The lack of a standard way of archiving editable versions high resolution graphics (such as are sometimes exhibited only in Postscript (or PDF) versions of drafts) does seem to be a constraint on communication. The requirement to produce an ASCII version might be provided by generating a 'preview' version (such as is often available in EPS - embedded PostScript images). ------------------------------------ Mailing list discussion: 'Plenary decision?' Potential Open Issue: 'There does not seem to be a satisfactory way of testing concensus across a large portion of the stakeholders/participants/'members'.' Certain items of general interest to IETF stakeholders (such as the problem WG output) should be the subject of organization-wide (rough) concensus. Such items are usually presented to a plenary session at a f2f meeting, and the I* take the input as guidance towards a decision but it is not clear that the whole constituency is really made aware of the decision to be made so that all possible views can be heard - some of the IETF general mailing lists are the best vehicle for this but it is not clear that this system is used in a way that everybody knows about. -------------------------------------- A message has been received from Harald Alvestrand indicating that he is happy with the resolutions of the issues which he originally raised on v01 of the draft. Comments on the matters above or the issues which were already supposedly addressed either here or at the WG session on Tuesday morning please. We would like to get out a new version and go to last call on the issue document asap if at all possible. Regards, Rlwyn ---------------------------------------------------------------------------- ------ Elwyn B Davies Routing and Addressing Strategy Prime Portfolio Integration Solutions Ready Nortel Networks plc Email: elwynd@nortelnetworks.com Harlow Laboratories ESN 6-742-5498 London Road, Harlow, Direct Line +44-1279-405498 Essex, CM17 9NA, UK Fax +44-1279-402047 Registered Office: Maidenhead Office Park, Westacott Way, Company No. 3937799 Maidenhead, Berkshire, SSL6 3QH ---------------------------------------------------------------------------- This message may contain information proprietary to Nortel Networks plc so any unauthorised disclosure, copying or distribution of its contents is strictly prohibited. ---------------------------------------------------------------------------- "The Folly is mostly mine" and the opinions are mine and not those of my employer. ============================================================================ ====== From problem-statement-bounces@alvestrand.no Mon Jul 14 03:46:27 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29910 for ; Mon, 14 Jul 2003 03:46:26 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9202E61B8F; Mon, 14 Jul 2003 09:45:56 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from HALVESTR-W2K1.cisco.com (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1C76861B8E; Mon, 14 Jul 2003 09:45:55 +0200 (CEST) Date: Mon, 14 Jul 2003 08:44:34 +0200 From: Harald Tveit Alvestrand To: john.loughney@nokia.com Message-ID: <242008489.1058172274@localhost> In-Reply-To: References: X-Mailer: Mulberry/3.0.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: problem-statement@alvestrand.no Subject: RE: appeal mechanisms was Re: Ombuds-process X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit --On 14. juli 2003 09:17 +0300 john.loughney@nokia.com wrote: >> it belongs under "routine stuff that the IESG needs to handle, but where >> the IETF as such doesn't need to do anything". > > I agree. However, is there any place to to discuss / request such things? if we could get the IETF list under some kind of control, it might just possibly be the right place..... We could always create Yet Another Mailing List, but I'm leery of increasing the number of mailing lists that people have to be on in order to participate effectively with no limit..... From problem-statement-bounces@alvestrand.no Mon Jul 14 05:59:33 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04511 for ; Mon, 14 Jul 2003 05:59:32 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C5D9361B8E; Mon, 14 Jul 2003 11:59:02 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from smtp.ietf57.telekom.at (smtp.ietf57.telekom.at [81.160.16.8]) by eikenes.alvestrand.no (Postfix) with ESMTP id E164761B8C for ; Mon, 14 Jul 2003 11:59:00 +0200 (CEST) Received: from apocalypse.org (refuge.ietf57.telekom.at [81.160.131.243]) by smtp.ietf57.telekom.at (8.11.7+Sun/8.10.2) with ESMTP id h6E9wxk09470 for ; Mon, 14 Jul 2003 11:59:00 +0200 (MEST) Date: Mon, 14 Jul 2003 05:58:46 -0400 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed From: avri To: problem-statement@alvestrand.no Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.552) Subject: Agenda for Problem Meeting - 15 July X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Agenda 1. Discussion of Agenda 2. Discussion of open Problem Stmt Issues Issues as described in Elwyn's email to the list - Further traffic on 'ISSUE: Determinants for timeliness in Section 2.1' - Appeal mechanisms - The need for smaller protocol specifications' - 'ADs who are also WG chairs' - Causes of "problems" - Accommodating ESL speakers' - 'Fixed font vs multiple fonts' etc -Plenary decision 3. Discussion of Process Draft - Sense of the room regarding the near-term recommendations in the process document? - Do we think it makes sense to start an effort to understand our values, mission, scope and goals? Or is that just a waste of time? - Do we think that a leadership reorganization is necessary to address some of the problems in the problem statement? - Do we think that changes are required to the standards track process? - Should the efforts mentioned in the previous three bullets be undertaken serially, or in parallel? By a single group or multiple groups? - Is a WG the best way to affect these changes? Or is there some other way that would work better? 4. Open discussion on issues not covered. From problem-statement-bounces@alvestrand.no Mon Jul 14 10:33:10 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24471 for ; Mon, 14 Jul 2003 10:33:09 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3833461B91; Mon, 14 Jul 2003 16:32:39 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from smtp.ietf57.telekom.at (smtp.ietf57.telekom.at [81.160.16.8]) by eikenes.alvestrand.no (Postfix) with ESMTP id A041961B90 for ; Mon, 14 Jul 2003 16:32:37 +0200 (CEST) Received: from acm.org (refuge.ietf57.telekom.at [81.160.131.243]) by smtp.ietf57.telekom.at (8.11.7+Sun/8.10.2) with ESMTP id h6EEWbk09960 for ; Mon, 14 Jul 2003 16:32:37 +0200 (MEST) Date: Mon, 14 Jul 2003 16:32:35 +0200 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed From: Avri Doria To: problem-statement@alvestrand.no Content-Transfer-Encoding: 7bit Message-Id: <029CAF58-B608-11D7-93DF-000393CC2112@acm.org> X-Mailer: Apple Mail (2.552) Subject: Volunteers X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Hi, We need volunteers for scribe & note takers for the tuesday meeting. It is important that we get all of the comments and opinions of all the participants recorded. thanks in advance. a. From problem-statement-bounces@alvestrand.no Mon Jul 14 11:00:58 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27062 for ; Mon, 14 Jul 2003 11:00:57 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0BF5E61B91; Mon, 14 Jul 2003 17:00:28 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from ietf.org (odin.ietf.org [132.151.1.176]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7550C61B90 for ; Mon, 14 Jul 2003 17:00:25 +0200 (CEST) Received: from tigger (scoya.cnri.reston.va.us [10.27.5.106]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA27032; Mon, 14 Jul 2003 11:00:20 -0400 (EDT) Date: Mon, 14 Jul 2003 10:58:58 -0400 (Eastern Daylight Time) From: Steve Coya To: todd glassey In-Reply-To: <005801c3499d$e57e2b10$020aff0a@tsg1> Message-ID: X-X-Sender: scoya@odin.cnri.reston.va.us MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: problem-statement@alvestrand.no Subject: Re: Fixed font v multiple fonts X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no >> No James - the IETF runs on the words Open and Fair. Perhaps it's time to review what the IETF means by OPEN. OPEN means that participation in the IETF is available to anyone and everyone. There are no dues or consortium-type fees to participate (and no secret handshakes nor decoder rings). OPEN means that the use of our specifications are made available at no charge, and are not limited to those who have, had, or will participate in the IETF. They can even be used by other standards organizations. OPEN means that WG email archives are available for anyone to read. OPEN means that meeting minutes are made available to anyone who wishes to read them. OPEN means that anyone can walk up to the plenary microphone. OPEN means that new ideas can be submitted for deliberation and consideration. OPEN does NOT mean these ideas are always accepted and incorporated. New ideas does not include old ideas that were not chosen by the working group. OPEN does NOT mean compliant with every possible definition (or interpretation or assumption) of the word OPEN. Steve From problem-statement-bounces@alvestrand.no Tue Jul 15 03:38:33 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29643 for ; Tue, 15 Jul 2003 03:38:33 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A79DD61B92; Tue, 15 Jul 2003 09:38:04 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from HALVESTR-W2K1.cisco.com (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C246A61B90 for ; Tue, 15 Jul 2003 09:38:02 +0200 (CEST) Date: Tue, 15 Jul 2003 09:23:57 +0200 From: Harald Tveit Alvestrand To: problem-statement@alvestrand.no Message-ID: <76947454.1058261037@localhost> X-Mailer: Mulberry/3.0.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Discussion of section 2.6.8 "Difficulty making technical and process appeals" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Discussion of this topic in the WG meeting is over. I think the text currently in 2.6.8 is adequate, and I did not say so in time. If any change should be done, it should be to the section heading, which assumes that the appeals procedure is the right tool; the text of the section actually would allow a "solution" that helped people do what Margaret suggested in the meeting - that the "right solution" is often to figure out who the right person to talk to is, and then talk to that person. notwithstanding the above, I think we need to think about procedures to record a history of grievances that are "too small to bother appealing" - if there are twenty small grievances, they point as much to something worth fixing as one that's big enough to trigger an appeal. Don't know how to go about it, though. Harald From problem-statement-bounces@alvestrand.no Wed Jul 16 04:53:33 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21681 for ; Wed, 16 Jul 2003 04:53:32 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4FBE361B9F; Wed, 16 Jul 2003 10:53:04 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from sentosa.post1.com (sentosa.post1.com [202.27.17.100]) by eikenes.alvestrand.no (Postfix) with SMTP id B112461A93 for ; Wed, 16 Jul 2003 10:53:01 +0200 (CEST) Received: (qmail 85363 invoked from network); 16 Jul 2003 08:58:14 -0000 Received: from james-fujitsu.ietf57.telekom.at (HELO pobox.org.sg) (81.160.159.172) by sentosa.post1.com with SMTP; 16 Jul 2003 08:58:14 -0000 Message-ID: <3F15125B.2090501@pobox.org.sg> Date: Wed, 16 Jul 2003 16:52:43 +0800 From: James Seng User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en, zh-cn, zh-tw, ja, ko MIME-Version: 1.0 To: problem-statement@alvestrand.no Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [Fwd: Re: rough consensus (was Re: "trouble maker")] X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit following from the brief discussion at the mike on "rough consensus", I would like to raise the ambiguity of "rough consensus" as a problem. The current rough consnsus _process_ as defined in RFC 2418 basically say "It is up to the Chair to determine if rough consensus has been reach." Because of this ambiguity, there is a general perspection that the "Chair has all the power => top-down". And what "rough consensus" the Chairs determined may also be disagree by a some people, a few may be become dissent, likewise due to this ambiguity. While a formal definition may be hard to nail down, it would be useful to cite several examples of past experiences. It also helpful to document some of the consideration and the thinking process the wg chairs takes to determine rough consensus. -James Seng -------- Original Message -------- Subject: Re: rough consensus (was Re: "trouble maker") Date: Fri, 27 Jun 2003 03:43:09 +0800 From: James Seng To: Avri Doria CC: problem-statement@alvestrand.no, Harald Alvestrand I believe the general problem is our current process of letting wg chairs determine rough consensus without a general definition. (Yes, I know it is a feature too :P) Since people have different opinion of the "rough consensus", those (especially the doc authors or someone with more then casual interest[1]) who disagree with the chair become resentful of the IETF process. Personally, I already lost count how many times it happens. It is not healty. [1] "more then casual interest" != vested interest. (See Keith v.s NAT, no offense intended :-) -James Seng Avri Doria wrote: > Hi, > > This has been a very interesting discussion, and I beleive that > it is important that the details of this issue be debated and resolved. > I do not believe that should be done on this list. It was good to get > the problem discussed so that people could do an abstraction of it > for the problem statement, but I would like to avoid dwelling on the > specific arguments relating to it any longer. > > At this point I ask that people concentrate on the general language > for the problem statement so that we can make sure that the problem > is reflected adequately in the problem statement. > > Thanks > > Avri > co-chair > > > > > On torsdag, jun 26, 2003, at 13:45 Asia/Seoul, Harald Tveit Alvestrand > wrote: > > > From problem-statement-bounces@alvestrand.no Wed Jul 16 05:07:15 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22083 for ; Wed, 16 Jul 2003 05:07:14 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 903EB61BAB; Wed, 16 Jul 2003 11:06:46 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by eikenes.alvestrand.no (Postfix) with ESMTP id 98AA961B9F for ; Wed, 16 Jul 2003 11:06:44 +0200 (CEST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id CAA24809 for ; Wed, 16 Jul 2003 02:06:43 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6G96gF18764 for ; Wed, 16 Jul 2003 02:06:42 -0700 X-mProtect: <200307160906> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (10.241.48.119, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdN4nSza; Wed, 16 Jul 2003 02:06:37 PDT Message-ID: <3F1515A3.5040608@iprg.nokia.com> Date: Wed, 16 Jul 2003 02:06:43 -0700 From: Charlie Perkins Organization: Nokia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: problem-statement@alvestrand.no References: <3F15125B.2090501@pobox.org.sg> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Another possible problem? X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Hello folks, I'd like to suggest the possible problem for inclusion in the problem statement draft. I'm obviously not suggesting a complete solution. If this is already present in the draft, then please excuse my inadvertent duplication. Problem: There often seem to be adversarial relationships within the IETF that are not necessary, and which substantially interfere with accomplishing timely work. These adversarial relationships exist, at times, between: - IESG members and document editors, and - IESG members and working group chairs - possibly other cases I am not aware of. Partial solution(s): Making all process steps and expectations evident as early as possible. Arrange things so that each party expects the best, instead of the worst, from the other party. Clarify or modify IETF processes to eliminate sources of differing expectations. Avoid all situations where one party knowingly allows the other party to harbor false expectations. Regards, Charlie P. From problem-statement-bounces@alvestrand.no Wed Jul 16 06:32:29 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24542 for ; Wed, 16 Jul 2003 06:32:28 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B7A2F61B9B; Wed, 16 Jul 2003 12:32:00 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from HALVESTR-W2K1.cisco.com (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 886B061A93; Wed, 16 Jul 2003 12:31:58 +0200 (CEST) Date: Wed, 16 Jul 2003 12:29:11 +0200 From: Harald Tveit Alvestrand To: James Seng , problem-statement@alvestrand.no Message-ID: <174460250.1058358551@localhost> In-Reply-To: <3F15125B.2090501@pobox.org.sg> References: <3F15125B.2090501@pobox.org.sg> X-Mailer: Mulberry/3.0.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [Fwd: Re: rough consensus (was Re: "trouble maker")] X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit the RFC 2418 definition is as follows (section 3.3): Working groups make decisions through a "rough consensus" process. IETF consensus does not require that all participants agree although this is, of course, preferred. In general, the dominant view of the working group shall prevail. (However, it must be noted that "dominance" is not to be determined on the basis of volume or persistence, but rather a more general sense of agreement.) Consensus can be determined by a show of hands, humming, or any other means on which the WG agrees (by rough consensus, of course). Note that 51% of the working group does not qualify as "rough consensus" and 99% is better than rough. It is up to the Chair to determine if rough consensus has been reached. how could this definition be modified to be more useful? From problem-statement-bounces@alvestrand.no Wed Jul 16 07:08:15 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25395 for ; Wed, 16 Jul 2003 07:08:15 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6E24461BAB; Wed, 16 Jul 2003 13:07:45 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from d12lmsgate-4.de.ibm.com (d12lmsgate-4.de.ibm.com [194.196.100.237]) by eikenes.alvestrand.no (Postfix) with ESMTP id DD42961A93; Wed, 16 Jul 2003 13:07:43 +0200 (CEST) Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by d12lmsgate-4.de.ibm.com (8.12.9/8.12.8) with ESMTP id h6GB7Vnx031070; Wed, 16 Jul 2003 13:07:36 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h6GB7Urd281768; Wed, 16 Jul 2003 13:07:30 +0200 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA49952; Wed, 16 Jul 2003 13:07:27 +0200 Message-ID: <3F152EC8.1AE7534B@hursley.ibm.com> Date: Wed, 16 Jul 2003 12:54:00 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Harald Tveit Alvestrand References: <3F15125B.2090501@pobox.org.sg> <174460250.1058358551@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: James Seng , problem-statement@alvestrand.no Subject: Re: [Fwd: Re: rough consensus (was Re: "trouble maker")] X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Harald Tveit Alvestrand wrote: > > the RFC 2418 definition is as follows (section 3.3): > > Working groups make decisions through a "rough consensus" process. > IETF consensus does not require that all participants agree although > this is, of course, preferred. In general, the dominant view of the > working group shall prevail. (However, it must be noted that > "dominance" is not to be determined on the basis of volume or > persistence, but rather a more general sense of agreement.) Consensus > can be determined by a show of hands, humming, or any other means on > which the WG agrees (by rough consensus, of course). Note that 51% > of the working group does not qualify as "rough consensus" and 99% is > better than rough. It is up to the Chair to determine if rough > consensus has been reached. > > > how could this definition be modified to be more useful? I doubt if it can, unless we radically change our open door policy. Brian > From problem-statement-bounces@alvestrand.no Wed Jul 16 07:19:52 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25682 for ; Wed, 16 Jul 2003 07:19:51 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3E35C61BB1; Wed, 16 Jul 2003 13:19:22 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from sentosa.post1.com (sentosa.post1.com [202.27.17.100]) by eikenes.alvestrand.no (Postfix) with SMTP id B913D61BB1 for ; Wed, 16 Jul 2003 13:19:18 +0200 (CEST) Received: (qmail 87396 invoked from network); 16 Jul 2003 11:24:35 -0000 Received: from james-fujitsu.ietf57.telekom.at (HELO pobox.org.sg) (81.160.159.172) by sentosa.post1.com with SMTP; 16 Jul 2003 11:24:35 -0000 Message-ID: <3F1534A9.9070307@pobox.org.sg> Date: Wed, 16 Jul 2003 19:19:05 +0800 From: James Seng User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en, zh-cn, zh-tw, ja, ko MIME-Version: 1.0 To: Brian E Carpenter References: <3F15125B.2090501@pobox.org.sg> <174460250.1058358551@localhost> <3F152EC8.1AE7534B@hursley.ibm.com> In-Reply-To: <3F152EC8.1AE7534B@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Harald Tveit Alvestrand , problem-statement@alvestrand.no Subject: Re: [Fwd: Re: rough consensus (was Re: "trouble maker")] X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit There are two parts here : Rough consensus process and rough consensus itself. RFC 2418 defines the process but leave the definition of rough consensus vague, leaving it to the chair. I am not saying the process have problem. I am saying we need to clarify the latter so everyone at least have some baseline understanding of what "rough consensus" is. -James Seng Brian E Carpenter wrote: > Harald Tveit Alvestrand wrote: > >>the RFC 2418 definition is as follows (section 3.3): >> >> Working groups make decisions through a "rough consensus" process. >> IETF consensus does not require that all participants agree although >> this is, of course, preferred. In general, the dominant view of the >> working group shall prevail. (However, it must be noted that >> "dominance" is not to be determined on the basis of volume or >> persistence, but rather a more general sense of agreement.) Consensus >> can be determined by a show of hands, humming, or any other means on >> which the WG agrees (by rough consensus, of course). Note that 51% >> of the working group does not qualify as "rough consensus" and 99% is >> better than rough. It is up to the Chair to determine if rough >> consensus has been reached. >> >> >>how could this definition be modified to be more useful? > > > I doubt if it can, unless we radically change our open door > policy. > > Brian > > >> > > > > > From problem-statement-bounces@alvestrand.no Wed Jul 16 07:30:21 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26038 for ; Wed, 16 Jul 2003 07:30:21 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1687C61BB4; Wed, 16 Jul 2003 13:29:51 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by eikenes.alvestrand.no (Postfix) with ESMTP id 80E4961BAC; Wed, 16 Jul 2003 13:29:49 +0200 (CEST) Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h6GBTkZf001213; Wed, 16 Jul 2003 04:29:46 -0700 (PDT) Received: from [81.160.226.51] (vpn-10-50-0-44.qualcomm.com [10.50.0.44]) by crowley.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h6GBTfix004813; Wed, 16 Jul 2003 04:29:42 -0700 (PDT) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: <3F1534A9.9070307@pobox.org.sg> References: <3F15125B.2090501@pobox.org.sg> <174460250.1058358551@localhost> <3F152EC8.1AE7534B@hursley.ibm.com> <3F1534A9.9070307@pobox.org.sg> Date: Wed, 16 Jul 2003 13:29:42 +0200 To: James Seng , Brian E Carpenter From: hardie@qualcomm.com Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable Cc: Harald Tveit Alvestrand , problem-statement@alvestrand.no Subject: Re: [Fwd: Re: rough consensus (was Re: "trouble maker")] X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: quoted-printable When I was writing a recent draft on alternative consensus mechanisms, I fel= t like the IETF process needed a little more context than 2418. The text is below, and improvements on it would be welcome=20 (from draft-hardie-alt-consensus-00.txt) =2E Introduction. Dave Clark's much-quoted credo for the IETF cites "rough consensus and running code" as the key criteria for decision making in the IETF. Aside from a pleasing alliteration, these two touchstones provide a concise summary of the ideals which guide the IETF's decision making. The first implies an open process in which any technical opinion will be heard and any participant's concerns addressed; the second implies a recognition that any decision must be grounded in solid engineering and the known characteristics of the network and its uses. The aim of the IETF is to make the best possible engineering choices and protocol standards for the Internet as a whole, and these two statements guide it in making its choices and standards. 2. Rough Consensus as a baseline approach. The Conflict Research Consortium at the University of Colorado outlines the pros and cons of consensus as: The advantage of consensus processes is that the resulting decision is one that meets the interests of all the parties and that everyone can support.=CA The disadvantage is that developing such a decision can be a very slow process, involving many people over a long period of time.=CA There is also a relatively high probability of failure. If a quick decision is needed, the consensus approach may not work.=CA Consensus rule processes also tend to favor those that oppose change and want to preserve the status quo. All these people have to do is refuse to support any consensus compromises and they will win (at least as long as they can delay change). (CONFLICT) Using "rough consensus" as a guideline limits some of disadvantages of consensus processes by ensuring that individuals or small factions cannot easily block a decision which has otherwise general support. The second touchstone of "running code" can also limit the disadvantages of consensus processes by requiring that statements opposing particular proposals be technically grounded. These limitations do not change the core mechanisms of consensus-building, however, and the IETF process continues to require individual participants both to use their best engineering judgment to select among proposals and to balance their own interests with those of the Internet as a whole. Active participation and a willingness to compromise, possibly on key points, are needed. Historically, this has worked because a large majority of participants have recognized that the Internet's growth and enhancement are more important overall than any specific short-term advantage. In other words, the use of "rough consensus" is sufficient in most cases in the IETF to ensure that individuals or small groups are heard when they raise technical objections, but that they cannot block progress when a general agreement has been reached. This document does not suggest changing the usual mechanisms for achieving forward progress; it proposes mechanisms for use when a working group has consensus that it must make a decision, but it cannot make that decision by the usual rules. At 7:19 PM +0800 7/16/03, James Seng wrote: >There are two parts here : Rough consensus process and rough consensus itse= lf. > >RFC 2418 defines the process but leave the=20 >definition of rough consensus vague, leaving it=20 >to the chair. > >I am not saying the process have problem. I am=20 >saying we need to clarify the latter so everyone=20 >at least have some baseline understanding of=20 >what "rough consensus" is. > >-James Seng > >Brian E Carpenter wrote: > >>Harald Tveit Alvestrand wrote: >> >>>the RFC 2418 definition is as follows (section 3.3): >>> >>> Working groups make decisions through a "rough consensus" process. >>> IETF consensus does not require that all participants agree although >>> this is, of course, preferred. In general, the dominant view of the >>> working group shall prevail. (However, it must be noted that >>> "dominance" is not to be determined on the basis of volume or >>> persistence, but rather a more general sense of agreement.) Consensus >>> can be determined by a show of hands, humming, or any other means on >>> which the WG agrees (by rough consensus, of course). Note that 51% >>> of the working group does not qualify as "rough consensus" and 99% is >>> better than rough. It is up to the Chair to determine if rough >>> consensus has been reached. >>> >>> >>>how could this definition be modified to be more useful? >> >> >>I doubt if it can, unless we radically change our open door >>policy. Brian >> >>> From problem-statement-bounces@alvestrand.no Wed Jul 16 07:30:30 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26054 for ; Wed, 16 Jul 2003 07:30:30 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D846261BE6; Wed, 16 Jul 2003 13:30:01 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [194.196.100.236]) by eikenes.alvestrand.no (Postfix) with ESMTP id A912C61BDE; Wed, 16 Jul 2003 13:29:56 +0200 (CEST) Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by d12lmsgate-3.de.ibm.com (8.12.9/8.12.8) with ESMTP id h6GBToZG020600; Wed, 16 Jul 2003 13:29:55 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h6GBTknb283784; Wed, 16 Jul 2003 13:29:47 +0200 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA50174; Wed, 16 Jul 2003 13:29:41 +0200 Message-ID: <3F15372A.950CDECD@hursley.ibm.com> Date: Wed, 16 Jul 2003 13:29:46 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: James Seng References: <3F15125B.2090501@pobox.org.sg> <174460250.1058358551@localhost> <3F152EC8.1AE7534B@hursley.ibm.com> <3F1534A9.9070307@pobox.org.sg> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Harald Tveit Alvestrand , problem-statement@alvestrand.no Subject: Re: [Fwd: Re: rough consensus (was Re: "trouble maker")] X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit "In general, the dominant view of the working group shall prevail. " Doesn't that define rough consensus? Brian James Seng wrote: > > There are two parts here : Rough consensus process and rough consensus > itself. > > RFC 2418 defines the process but leave the definition of rough consensus > vague, leaving it to the chair. > > I am not saying the process have problem. I am saying we need to clarify > the latter so everyone at least have some baseline understanding of what > "rough consensus" is. > > -James Seng > > Brian E Carpenter wrote: > > > Harald Tveit Alvestrand wrote: > > > >>the RFC 2418 definition is as follows (section 3.3): > >> > >> Working groups make decisions through a "rough consensus" process. > >> IETF consensus does not require that all participants agree although > >> this is, of course, preferred. In general, the dominant view of the > >> working group shall prevail. (However, it must be noted that > >> "dominance" is not to be determined on the basis of volume or > >> persistence, but rather a more general sense of agreement.) Consensus > >> can be determined by a show of hands, humming, or any other means on > >> which the WG agrees (by rough consensus, of course). Note that 51% > >> of the working group does not qualify as "rough consensus" and 99% is > >> better than rough. It is up to the Chair to determine if rough > >> consensus has been reached. > >> > >> > >>how could this definition be modified to be more useful? > > > > > > I doubt if it can, unless we radically change our open door > > policy. > > > > Brian > > > > > >> > > > > > > > > > > -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland From problem-statement-bounces@alvestrand.no Wed Jul 16 07:33:50 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26204 for ; Wed, 16 Jul 2003 07:33:49 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C3B7861BE7; Wed, 16 Jul 2003 13:33:18 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by eikenes.alvestrand.no (Postfix) with ESMTP id 46AD461BD5 for ; Wed, 16 Jul 2003 13:33:15 +0200 (CEST) Received: from employees.org (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 16 Jul 2003 04:37:38 -0700 Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h6GBXC89009957 for ; Wed, 16 Jul 2003 04:33:13 -0700 (PDT) Received: from cisco.com (sjc-vpn2-129.cisco.com [10.21.112.129]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id AIA89839; Wed, 16 Jul 2003 04:28:40 -0700 (PDT) Received: by cisco.com (sSMTP sendmail emulation); Wed, 16 Jul 2003 13:33:10 +0200 Date: Wed, 16 Jul 2003 13:33:10 +0200 From: Scott W Brim To: problem-statement@alvestrand.no Message-ID: <20030716133310.E1940@sbrim-w2k01> Mail-Followup-To: Scott W Brim , problem-statement@alvestrand.no References: <3F15125B.2090501@pobox.org.sg> <174460250.1058358551@localhost> <3F152EC8.1AE7534B@hursley.ibm.com> <3F1534A9.9070307@pobox.org.sg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3F1534A9.9070307@pobox.org.sg>; from jseng@pobox.org.sg on Wed, Jul 16, 2003 at 07:19:05PM +0800 Subject: Re: [Fwd: Re: rough consensus (was Re: "trouble maker")] X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no On Wed, Jul 16, 2003 07:19:05PM +0800, James Seng allegedly wrote: > There are two parts here : Rough consensus process and rough consensus > itself. > > RFC 2418 defines the process but leave the definition of rough consensus > vague, leaving it to the chair. > > I am not saying the process have problem. I am saying we need to clarify > the latter so everyone at least have some baseline understanding of what > "rough consensus" is. I don't know if that's preferable. The situations encountered are so different, even within a single working group. I think that trying to define rough consensus better than we have already will disregard the innate, and rather excellent, understanding of groups and group consensus which we have been developing for many millions of years. From problem-statement-bounces@alvestrand.no Wed Jul 16 07:57:40 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26815 for ; Wed, 16 Jul 2003 07:57:39 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9040161BAD; Wed, 16 Jul 2003 13:57:09 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from sentosa.post1.com (sentosa.post1.com [202.27.17.100]) by eikenes.alvestrand.no (Postfix) with SMTP id 83AEC61BA0 for ; Wed, 16 Jul 2003 13:57:05 +0200 (CEST) Received: (qmail 87674 invoked from network); 16 Jul 2003 12:02:21 -0000 Received: from james-fujitsu.ietf57.telekom.at (HELO pobox.org.sg) (81.160.159.172) by sentosa.post1.com with SMTP; 16 Jul 2003 12:02:21 -0000 Message-ID: <3F153D82.7030409@pobox.org.sg> Date: Wed, 16 Jul 2003 19:56:50 +0800 From: James Seng User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en, zh-cn, zh-tw, ja, ko MIME-Version: 1.0 To: Brian E Carpenter References: <3F15125B.2090501@pobox.org.sg> <174460250.1058358551@localhost> <3F152EC8.1AE7534B@hursley.ibm.com> <3F1534A9.9070307@pobox.org.sg> <3F15372A.950CDECD@hursley.ibm.com> In-Reply-To: <3F15372A.950CDECD@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Harald Tveit Alvestrand , problem-statement@alvestrand.no Subject: Re: [Fwd: Re: rough consensus (was Re: "trouble maker")] X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit In some cases, it is easy to differential. But in most cases, it is a fuzzy line. For example, a proposal which have most people supportive but a couple of objections, do we move forward? In general, the answer is "yes". But what if the couple of objections involves all the major vendors for that protocol. Do we still move forward a proposal we know which will not be deploy at all? Another example, a proposal have only a handful of people supporting it passionly but the rest of the group is in the class 'don't care but no object', 'dont like it but wont bother to object', 'finds the whole excerise waste of time'. So when you call for a hum, you get some very loud hum but still weak. You call for objections, silent. Do you move forward? So basically, there are a lot of factors influencing whether the Chairs will declare rough consensus or not. While I feel the Chairs should still have pregorative to decide when to move forward, the consideration should be captured and make clearer to the participants so that people wont scream so much when the Chairs decided to move (or decided not to move). -James Seng Brian E Carpenter wrote: > "In general, the dominant view of the working group shall prevail. " > > Doesn't that define rough consensus? > > Brian > > James Seng wrote: > >>There are two parts here : Rough consensus process and rough consensus >>itself. >> >>RFC 2418 defines the process but leave the definition of rough consensus >>vague, leaving it to the chair. >> >>I am not saying the process have problem. I am saying we need to clarify >>the latter so everyone at least have some baseline understanding of what >>"rough consensus" is. >> >>-James Seng >> >>Brian E Carpenter wrote: >> >> >>>Harald Tveit Alvestrand wrote: >>> >>> >>>>the RFC 2418 definition is as follows (section 3.3): >>>> >>>> Working groups make decisions through a "rough consensus" process. >>>> IETF consensus does not require that all participants agree although >>>> this is, of course, preferred. In general, the dominant view of the >>>> working group shall prevail. (However, it must be noted that >>>> "dominance" is not to be determined on the basis of volume or >>>> persistence, but rather a more general sense of agreement.) Consensus >>>> can be determined by a show of hands, humming, or any other means on >>>> which the WG agrees (by rough consensus, of course). Note that 51% >>>> of the working group does not qualify as "rough consensus" and 99% is >>>> better than rough. It is up to the Chair to determine if rough >>>> consensus has been reached. >>>> >>>> >>>>how could this definition be modified to be more useful? >>> >>> >>>I doubt if it can, unless we radically change our open door >>>policy. >>> >>> Brian >>> >>> >>> >>>> >>> >>> >>> >>> >>> > From problem-statement-bounces@alvestrand.no Wed Jul 16 08:06:49 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26992 for ; Wed, 16 Jul 2003 08:06:48 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9F41561BB8; Wed, 16 Jul 2003 14:06:18 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0EE2761BAD; Wed, 16 Jul 2003 14:06:17 +0200 (CEST) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h6GC6GiR003873; Wed, 16 Jul 2003 06:06:16 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6GC6FtK003100; Wed, 16 Jul 2003 08:06:15 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h6GC6F8Q006662; Wed, 16 Jul 2003 08:06:15 -0400 (EDT) Message-Id: <200307161206.h6GC6F8Q006662@thunk.east.sun.com> From: Bill Sommerfeld To: James Seng In-Reply-To: Your message of "Wed, 16 Jul 2003 19:56:50 +0800." <3F153D82.7030409@pobox.org.sg> Date: Wed, 16 Jul 2003 08:06:15 -0400 Cc: Harald Tveit Alvestrand , Brian E Carpenter , problem-statement@alvestrand.no Subject: Re: [Fwd: Re: rough consensus (was Re: "trouble maker")] X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list Reply-To: sommerfeld@sun.com List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no > Another example, a proposal have only a handful of people supporting it > passionly but the rest of the group is in the class 'don't care but no > object', 'dont like it but wont bother to object', 'finds the whole > excerise waste of time'. > > So when you call for a hum, you get some very loud hum but still weak. > You call for objections, silent. Do you move forward? well, if the silent majority is truly silent, the trick is to distinguish the case you cited from "small number of enthusiastic prospective users and implementors, many apathetic don't minds" meaning that there's a small community of interest in a feature which does no appreciable harm to the larger community as whole. In most working groups I frequent, there are plenty of people who are not shy about announcing that they dislike a proposal.. - Bill From problem-statement-bounces@alvestrand.no Wed Jul 16 08:22:38 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27354 for ; Wed, 16 Jul 2003 08:22:37 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8321361BAD; Wed, 16 Jul 2003 14:22:08 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from sentosa.post1.com (sentosa.post1.com [202.27.17.100]) by eikenes.alvestrand.no (Postfix) with SMTP id 8563561BAB for ; Wed, 16 Jul 2003 14:22:05 +0200 (CEST) Received: (qmail 87902 invoked from network); 16 Jul 2003 12:27:21 -0000 Received: from james-fujitsu.ietf57.telekom.at (HELO pobox.org.sg) (81.160.159.172) by sentosa.post1.com with SMTP; 16 Jul 2003 12:27:21 -0000 Message-ID: <3F15435E.8020205@pobox.org.sg> Date: Wed, 16 Jul 2003 20:21:50 +0800 From: James Seng User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en, zh-cn, zh-tw, ja, ko MIME-Version: 1.0 To: Scott W Brim References: <3F15125B.2090501@pobox.org.sg> <174460250.1058358551@localhost> <3F152EC8.1AE7534B@hursley.ibm.com> <3F1534A9.9070307@pobox.org.sg> <20030716133310.E1940@sbrim-w2k01> In-Reply-To: <20030716133310.E1940@sbrim-w2k01> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: [Fwd: Re: rough consensus (was Re: "trouble maker")] X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Ignore the solutionism portion. I am trying to point out that informal definition of rough consensus has been stretched too far. A Chair handwaving and say 'rough consenus, you know, is..well, you know, consensus which is rough so not everyone may agree' may works when we are much smaller. But it dont build confidences in the Chairs. Chairs ultimately suffer the bulk of the attack from the people who disagree. Personally, I seen lots of people angry & upset over the rough consensus. I have people telling me 'I spend 3 years of my time, travelling to every IETF and I am disillusioned now and will not attend anymore'. And they dont. Now, you may say that is their problem...Part of it yes. But could part of it be our problem? -James Seng > I don't know if that's preferable. The situations encountered are so > different, even within a single working group. I think that trying to > define rough consensus better than we have already will disregard the > innate, and rather excellent, understanding of groups and group > consensus which we have been developing for many millions of years. > > From problem-statement-bounces@alvestrand.no Wed Jul 16 08:28:39 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27582 for ; Wed, 16 Jul 2003 08:28:38 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 34A7861BAF; Wed, 16 Jul 2003 14:28:09 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by eikenes.alvestrand.no (Postfix) with ESMTP id BA07761BAD for ; Wed, 16 Jul 2003 14:28:06 +0200 (CEST) Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h6GCS3uD022873 for ; Wed, 16 Jul 2003 05:28:04 -0700 (PDT) Received: from cisco.com (sjc-vpn2-129.cisco.com [10.21.112.129]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id AIA91666; Wed, 16 Jul 2003 05:23:29 -0700 (PDT) Received: by cisco.com (sSMTP sendmail emulation); Wed, 16 Jul 2003 14:27:58 +0200 Date: Wed, 16 Jul 2003 14:27:58 +0200 From: Scott W Brim To: problem-statement@alvestrand.no Message-ID: <20030716142758.H1940@sbrim-w2k01> Mail-Followup-To: Scott W Brim , problem-statement@alvestrand.no References: <3F15125B.2090501@pobox.org.sg> <174460250.1058358551@localhost> <3F152EC8.1AE7534B@hursley.ibm.com> <3F1534A9.9070307@pobox.org.sg> <20030716133310.E1940@sbrim-w2k01> <3F15435E.8020205@pobox.org.sg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3F15435E.8020205@pobox.org.sg>; from jseng@pobox.org.sg on Wed, Jul 16, 2003 at 08:21:50PM +0800 Subject: Re: [Fwd: Re: rough consensus (was Re: "trouble maker")] X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no I like the idea that Chairs should document why they declared consensus (or the lack of it). From problem-statement-bounces@alvestrand.no Wed Jul 16 08:40:31 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27892 for ; Wed, 16 Jul 2003 08:40:30 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DA3FE61BD8; Wed, 16 Jul 2003 14:40:01 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by eikenes.alvestrand.no (Postfix) with ESMTP id 687A561BAF for ; Wed, 16 Jul 2003 14:39:59 +0200 (CEST) Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h6GCdu89006305 for ; Wed, 16 Jul 2003 05:39:57 -0700 (PDT) Received: from cisco.com (sjc-vpn2-129.cisco.com [10.21.112.129]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id AIA92069; Wed, 16 Jul 2003 05:35:21 -0700 (PDT) Received: by cisco.com (sSMTP sendmail emulation); Wed, 16 Jul 2003 14:39:49 +0200 Date: Wed, 16 Jul 2003 14:39:49 +0200 From: Scott W Brim To: problem-statement@alvestrand.no Message-ID: <20030716143949.I1940@sbrim-w2k01> Mail-Followup-To: Scott W Brim , problem-statement@alvestrand.no References: <3F15125B.2090501@pobox.org.sg> <174460250.1058358551@localhost> <3F152EC8.1AE7534B@hursley.ibm.com> <3F1534A9.9070307@pobox.org.sg> <3F15372A.950CDECD@hursley.ibm.com> <3F153D82.7030409@pobox.org.sg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3F153D82.7030409@pobox.org.sg>; from jseng@pobox.org.sg on Wed, Jul 16, 2003 at 07:56:50PM +0800 Subject: Re: [Fwd: Re: rough consensus (was Re: "trouble maker")] X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no So, in problem-issue-statement-02, somewhere around this text: Participants are frequently allowed to re-open previously closed issues just to replay parts of the previous discussion without introducing new material. This may be either because the decision has not been clearly documented or it may be a maneuver to try to get a decision changed because the participant did not concur with the consensus originally. .. add that participants might abandon the IETF altogether. Stress that lack of clarity and justification for the Chair declaring consensus (or the lack of it) aggravates this problem. From problem-statement-bounces@alvestrand.no Wed Jul 16 09:01:46 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28547 for ; Wed, 16 Jul 2003 09:01:45 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8C7F461BDE; Wed, 16 Jul 2003 15:01:16 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [194.196.100.235]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2B16061BB8 for ; Wed, 16 Jul 2003 15:01:15 +0200 (CEST) Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by d12lmsgate-2.de.ibm.com (8.12.9/8.12.8) with ESMTP id h6GD179d011928; Wed, 16 Jul 2003 15:01:08 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h6GD15rd265030; Wed, 16 Jul 2003 15:01:05 +0200 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA33442; Wed, 16 Jul 2003 15:01:03 +0200 Message-ID: <3F154C95.93EFAD0E@hursley.ibm.com> Date: Wed, 16 Jul 2003 15:01:09 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Scott W Brim References: <3F15125B.2090501@pobox.org.sg> <174460250.1058358551@localhost> <3F152EC8.1AE7534B@hursley.ibm.com> <3F1534A9.9070307@pobox.org.sg> <20030716133310.E1940@sbrim-w2k01> <3F15435E.8020205@pobox.org.sg> <20030716142758.H1940@sbrim-w2k01> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: [Fwd: Re: rough consensus (was Re: "trouble maker")] X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Scott W Brim wrote: > > I like the idea that Chairs should document why they declared consensus > (or the lack of it). Agreed. But another thing that may be going on is Chairs making consensus calls too late. If you ask a WG to accept a draft that's been in development for a year and the WG says no, you asked the question too late. It's not a problem with the consensus process, but with the decision tree. Brian From problem-statement-bounces@alvestrand.no Wed Jul 16 09:23:57 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29099 for ; Wed, 16 Jul 2003 09:23:57 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8D05F61BDE; Wed, 16 Jul 2003 15:23:25 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by eikenes.alvestrand.no (Postfix) with ESMTP id 872DD61BB8 for ; Wed, 16 Jul 2003 15:23:23 +0200 (CEST) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6GDNKtI026063; Wed, 16 Jul 2003 06:23:21 -0700 (PDT) Received: from sun.com (vpn-129-159-0-117.EMEA.Sun.COM [129.159.0.117]) by hs-ehdb03-01.Germany.Sun.COM (8.11.7+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id h6GDNHw29542; Wed, 16 Jul 2003 15:23:18 +0200 (MEST) Message-ID: <3F15516A.9070309@sun.com> Date: Wed, 16 Jul 2003 15:21:46 +0200 From: Erik Guttman User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, de, fr MIME-Version: 1.0 To: Brian E Carpenter References: <3F15125B.2090501@pobox.org.sg> <174460250.1058358551@localhost> <3F152EC8.1AE7534B@hursley.ibm.com> <3F1534A9.9070307@pobox.org.sg> <20030716133310.E1940@sbrim-w2k01> <3F15435E.8020205@pobox.org.sg> <20030716142758.H1940@sbrim-w2k01> <3F154C95.93EFAD0E@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no, Scott W Brim Subject: Re: [Fwd: Re: rough consensus (was Re: "trouble maker")] X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Brian E Carpenter wrote: > Scott W Brim wrote: >>I like the idea that Chairs should document why they declared consensus >>(or the lack of it). > > > Agreed. But another thing that may be going on is Chairs making consensus > calls too late. The hardest part of calling consensus is its subtlety. After 100s of emails have been exchanged and a rough consensus has emerged it doesn't really exist (have any reality) until the consensus has been put into words by the chair. Without a coherent statement posted to the list describing a consensus it is hard to know - what actions it implies - whether all dissenting views have been considered - what compromises were made among those forming the consensus (what were their positions originally and what did they agree to?) Defending or questioning a consensus call requires mailing list archeology, which is a tedious and inexact discipline. We should do better and we can. ============================ Solution discussion: I have found that by documenting the - final decision and action to take - summary of the dominant consensus position taken, including where they aren't in accord - well worked out dissenting views - notes from the WG chair (if needed), to clarify how a difficult decisions was made and why it is reasonable. This sounds like a lot of writing. It usually comes down to a page or two, even for very complex decisions. Advantages of putting this in the record are a) You can point at it when someone wants to bring the topic up again. b) If the chair overlooks something, it is easy to reopen the consensus call *for a very specific reason* without reopening the whole debate. (Note: Sometimes WG chairs do not fully understand the issues they are making a consensus call on. By writing this consensus document, it is easy to determine whether the argument has been correctly heard and evaluated.) c) It is a extremely useful to have definitive instructions *what to do* with a consensus decision. d) Once a consensus statement is accepted by the working group we have something much more concrete than a record in WG minutes that such and such was decided upon, etc. Erik From problem-statement-bounces@alvestrand.no Wed Jul 16 09:24:16 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29138 for ; Wed, 16 Jul 2003 09:24:13 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3C7BF61BE9; Wed, 16 Jul 2003 15:23:45 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from smtp.ietf57.telekom.at (smtp.ietf57.telekom.at [81.160.16.8]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6FA9061BE7 for ; Wed, 16 Jul 2003 15:23:42 +0200 (CEST) Received: from [81.160.175.139] (Warabi.ietf57.telekom.at [81.160.175.139]) by smtp.ietf57.telekom.at (8.11.7+Sun/8.10.2) with ESMTP id h6GDNdk26855 for ; Wed, 16 Jul 2003 15:23:39 +0200 (MEST) Date: Wed, 16 Jul 2003 09:23:39 -0400 From: Cyrus Shaoul To: problem-statement@alvestrand.no In-Reply-To: References: Message-Id: <20030716084824.58F3.CYRUS@ntt-at.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.05.06 Subject: Hearing and Speaking Problems for Non-Native English speaking participants. X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Hi All, I have been lurking on the list for a while, but I wanted to contribute my thoughts on the problem of difficulties in participation by non-native English speakers. In draft-ietf-problem-issue-statement-02, it seems that the only place where a related problem is discussed in section 2.6.6 (Concentration of Influence in Too Few Hands). I support this section, as I feel that the second paragraph describes a real problem. I work with a team of Japanese IETF participants and they agree that this problem exists for them. There was also some discussion in a list thread called "Accomodating ESL speakers" recently about how non-native speakers have problems understanding other native and non-native speakers at the IETF meetings. I think it would good to add a little section about this problem to the problem-statement, unless it is already too late to do so. (I have ideas on how to solve these problems, but I will save them until it is time to provide solutions.) Hearing and Speaking Problems for Non-Native English speaking participants. At IETF meetings, many participants are non-native English speakers. Many of these participants currently have trouble understanding and following along with WG discussions when the person at the microphones, speaks very quickly, with a strong accent, or in a very animated way that can make it hard for non-native English speakers to understand what they are saying. Another problem is when speakers use excessive amounts of colloquial or idiomatic phrases. The meaning of these phrases, such as "water under the bridge" and "whatcha talking about" and unclear and can confuse non-native english speakers. A further problem for non-native english speakers is that the effort to simultaneously read slides with small letters on a screen and hear and understand the content of a speech can be too much to handle. Evidence of this is in the number of non-native English speakers taking photographs of the projection screen and making private recordings of WG meetings for later study (making it harder for them to interactively participate during the WG meeting.) This problem is amplified when speakers do not speak into the microphone, or use the microphone improperly. When the microphone is not used, the sound may be too soft to be comprhensible to non-native speakers even though it is marginally comprehensible to native english speakers. When a microphone is not used properly, for example clipping it to a necktie and then letting it drop, it can add small amounts of feedback to the sound, making it very hard to understand for non-native English speakers. There is also a problem with using the Jabber chat system with an official scribe as a support tool for non-native English speakers. The benefit of being able to read a summary of the WG meeting in text in realtime is undeniable, but haveing to constantly look down at a lap-top (if you have one) while listening to a presentation is difficult and distracting. Also, very few work groups use the Jabber system, and even fewer have good scribes. Another problem is the delay in getting the meeting minutes and presentation slides published electronically. This process is uneven and for some WGs, may take more than one month to complete, leaving some non-native English speakers in the dark on what was said, and what consensus was reached during the meeting. ------------------ Does this make sense? I hope this point can get added in some form to the problem statement. Thanks, Cyrus Cyrus Shaoul NTT Advanced Technology Corp. cyrus@ntt-at.com From problem-statement-bounces@alvestrand.no Wed Jul 16 09:25:10 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29180 for ; Wed, 16 Jul 2003 09:25:08 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DA70161BED; Wed, 16 Jul 2003 15:24:39 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from mtiwmhc13.worldnet.att.net (mtiwmhc13.worldnet.att.net [204.127.131.117]) by eikenes.alvestrand.no (Postfix) with ESMTP id A7AF361BDE; Wed, 16 Jul 2003 15:24:37 +0200 (CEST) Received: from tsg1 (28.sanjose-13-14rs16rt.ca.dial-access.att.net[12.81.5.28]) by mtiwmhc13.worldnet.att.net (mtiwmhc13) with SMTP id <2003071613243411300nuffje>; Wed, 16 Jul 2003 13:24:35 +0000 Message-ID: <021c01c34b9d$75694dd0$020aff0a@tsg1> From: "todd glassey" To: "Harald Tveit Alvestrand" , "James Seng" , References: <3F15125B.2090501@pobox.org.sg> <174460250.1058358551@localhost> Date: Wed, 16 Jul 2003 06:22:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: Re: [Fwd: Re: rough consensus (was Re: "trouble maker")] X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Harald Tveit Alvestrand" To: "James Seng" ; Sent: Wednesday, July 16, 2003 3:29 AM Subject: Re: [Fwd: Re: rough consensus (was Re: "trouble maker")] > the RFC 2418 definition is as follows (section 3.3): > > Working groups make decisions through a "rough consensus" process. > IETF consensus does not require that all participants agree although > this is, of course, preferred. So OK then Harald - who decides what constitutes a concensus then? The WG Chair? and then what is the minimum number of members that need to vote, or how is a quorum created? becuase without some form of voting, I see that there is no real way to measure anything... let alone a concensus. > In general, the dominant view of the > working group shall prevail. (However, it must be noted that > "dominance" is not to be determined on the basis of volume or > persistence, but rather a more general sense of agreement.) OK So all the parties on whoever's payroll all vote the same. > Consensus > can be determined by a show of hands, humming, or any other means on > which the WG agrees (by rough consensus, of course). So then the WG, can select its own type of concensus, making NONE of the efforts of achieving concensus comparable to each other. This is a glaring flaw in the process since it essentially says that each WG can do whatever then hell it wants with no regard for consistancy. > Note that 51% > of the working group does not qualify as "rough consensus" and 99% is > better than rough. It is up to the Chair to determine if rough > consensus has been reached. So here again - we have some basic number stating that more than 52% is considered a concensus. But that above 52%, and its the WG Chair's responsibility to declare the concensus reached. So let me paint a picture hypothetically... So I come up with a new backbone protocol so revolutionary that it threatens to rock the world, and I expose it to the IETF under terms not totally inline with the full releases in RFC2026's SS10. Cisco or other large IETF participant notices that I have something that potentiallty could kick their ass in the marketspace, and so they flood the WG that I got the IETF to allow me to start on this with bodies. These bodies do two things, they create chaos in the process and effectively STOP me from advancing the protocol... The question is how the IETF's processes can prevent the scenario that I just painted, and my apologies to Big John and the Tasman Avenue crowd, no offense was intended here, but the fact is that any large player in the IETF has a clear, everpresent, and very unfair advantage here, and the IETF's processes are setup to allow this to happen and that's the issue. > > > how could this definition be modified to be more useful? 1) Define the formal vetting process and the steps involved - this will take a revision to RFC2026 and the standards process. 2) Define the minimum number of participants needed to constitute a vetting process, and allow for any number of standards initiatives in the same WG. It is not the WG's choir to pick the dominent player in the marketplace. Its their responsibilty to "create interoperable standards" not lock others out of the marketplace. 3) Put in place a real oversight process instead of the loosely defined methods now woven through RFC2026 and the other Operating Documents herein. This includes Management Oversignt as well and having some formal mechanism for the members of a WG to oust the WG Chair and how many members it takes to do that. > From problem-statement-bounces@alvestrand.no Wed Jul 16 09:25:18 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29213 for ; Wed, 16 Jul 2003 09:25:15 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id EF49A61BE6; Wed, 16 Jul 2003 15:24:47 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from mtiwmhc13.worldnet.att.net (mtiwmhc13.worldnet.att.net [204.127.131.117]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4A8AC61BE9 for ; Wed, 16 Jul 2003 15:24:39 +0200 (CEST) Received: from tsg1 (28.sanjose-13-14rs16rt.ca.dial-access.att.net[12.81.5.28]) by mtiwmhc13.worldnet.att.net (mtiwmhc13) with SMTP id <2003071613243611300nuffke>; Wed, 16 Jul 2003 13:24:37 +0000 Message-ID: <021d01c34b9d$76de1380$020aff0a@tsg1> From: "todd glassey" To: "Brian E Carpenter" , "Scott W Brim" References: <3F15125B.2090501@pobox.org.sg> <174460250.1058358551@localhost><3F152EC8.1AE7534B@hursley.ibm.com> <3F1534A9.9070307@pobox.org.sg><20030716133310.E1940@sbrim-w2k01> <3F15435E.8020205@pobox.org.sg><20030716142758.H1940@sbrim-w2k01> <3F154C95.93EFAD0E@hursley.ibm.com> Date: Wed, 16 Jul 2003 06:23:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Cc: problem-statement@alvestrand.no Subject: Re: [Fwd: Re: rough consensus (was Re: "trouble maker")] X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit You mean that they should be accountable for their decisions? Todd ----- Original Message ----- From: "Brian E Carpenter" To: "Scott W Brim" Cc: Sent: Wednesday, July 16, 2003 6:01 AM Subject: Re: [Fwd: Re: rough consensus (was Re: "trouble maker")] > Scott W Brim wrote: > > > > I like the idea that Chairs should document why they declared consensus > > (or the lack of it). > > Agreed. But another thing that may be going on is Chairs making consensus > calls too late. > > If you ask a WG to accept a draft that's been in development for a year > and the WG says no, you asked the question too late. It's not a > problem with the consensus process, but with the decision tree. > > Brian > From problem-statement-bounces@alvestrand.no Wed Jul 16 09:32:25 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29444 for ; Wed, 16 Jul 2003 09:32:24 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id ACA5161BEE; Wed, 16 Jul 2003 15:31:55 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from mtiwmhc11.worldnet.att.net (mtiwmhc11.worldnet.att.net [204.127.131.115]) by eikenes.alvestrand.no (Postfix) with ESMTP id AA99F61BE9; Wed, 16 Jul 2003 15:31:52 +0200 (CEST) Received: from tsg1 (28.sanjose-13-14rs16rt.ca.dial-access.att.net[12.81.5.28]) by mtiwmhc11.worldnet.att.net (mtiwmhc11) with SMTP id <2003071613314911100lj0a1e>; Wed, 16 Jul 2003 13:31:50 +0000 Message-ID: <024a01c34b9e$78c2bc90$020aff0a@tsg1> From: "todd glassey" To: "todd glassey" , "Harald Tveit Alvestrand" , "James Seng" , References: <3F15125B.2090501@pobox.org.sg> <174460250.1058358551@localhost> <021c01c34b9d$75694dd0$020aff0a@tsg1> Date: Wed, 16 Jul 2003 06:30:18 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: Re: [Fwd: Re: rough consensus (was Re: "trouble maker")] X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "todd glassey" To: "Harald Tveit Alvestrand" ; "James Seng" ; Sent: Wednesday, July 16, 2003 6:22 AM Subject: Re: [Fwd: Re: rough consensus (was Re: "trouble maker")] > > ----- Original Message ----- > From: "Harald Tveit Alvestrand" > To: "James Seng" ; > Sent: Wednesday, July 16, 2003 3:29 AM > Subject: Re: [Fwd: Re: rough consensus (was Re: "trouble maker")] > > > > the RFC 2418 definition is as follows (section 3.3): > > > > Working groups make decisions through a "rough consensus" process. > > IETF consensus does not require that all participants agree although > > this is, of course, preferred. > > So OK then Harald - who decides what constitutes a concensus then? The WG > Chair? and then what is the minimum number of members that need to vote, or > how is a quorum created? becuase without some form of voting, I see that > there is no real way to measure anything... let alone a concensus. > > > In general, the dominant view of the > > working group shall prevail. (However, it must be noted that > > "dominance" is not to be determined on the basis of volume or > > persistence, but rather a more general sense of agreement.) > > OK So all the parties on whoever's payroll all vote the same. > > > Consensus > > can be determined by a show of hands, humming, or any other means on > > which the WG agrees (by rough consensus, of course). > > So then the WG, can select its own type of concensus, making NONE of the > efforts of achieving concensus comparable to each other. This is a glaring > flaw in the process since it essentially says that each WG can do whatever > then hell it wants with no regard for consistancy. > > > > Note that 51% > > of the working group does not qualify as "rough consensus" and 99% is > > better than rough. It is up to the Chair to determine if rough > > consensus has been reached. > > So here again - we have some basic number stating that more than 52% is > considered a concensus. But that above 52%, and its the WG Chair's > responsibility to declare the concensus reached. So let me paint a picture > hypothetically... > > So I come up with a new backbone protocol so revolutionary that it threatens > to rock the world, and I expose it to the IETF under terms not totally > inline with the full releases in RFC2026's SS10. Cisco or other large IETF > participant notices that I have something that potentiallty could kick their > ass in the marketspace, and so they flood the WG that I got the IETF to > allow me to start on this with bodies. These bodies do two things, they > create chaos in the process and effectively STOP me from advancing the > protocol... > > The question is how the IETF's processes can prevent the scenario that I > just painted, and my apologies to Big John and the Tasman Avenue crowd, no > offense was intended here, but the fact is that any large player in the IETF > has a clear, everpresent, and very unfair advantage here, and the IETF's > processes are setup to allow this to happen and that's the issue. > > > > > > > how could this definition be modified to be more useful? > > 1) Define the formal vetting process and the steps involved - this > will take a revision to RFC2026 and the standards process. > > 2) Define the minimum number of participants needed to constitute a > vetting process, and allow for any number of standards initiatives in the > same WG. It is not the WG's choir Chore... (sorry what meant to say is that its not the WG's chore to...) > to pick the dominent player in the > marketplace. Its their responsibilty to "create interoperable standards" not > lock others out of the marketplace. > > 3) Put in place a real oversight process instead of the loosely > defined methods now woven through RFC2026 and the other Operating Documents > herein. This includes Management Oversignt as well and having some formal > mechanism for the members of a WG to oust the WG Chair and how many members > it takes to do that. > > > > > > From problem-statement-bounces@alvestrand.no Wed Jul 16 10:45:13 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04501 for ; Wed, 16 Jul 2003 10:45:13 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C4E1261B9B; Wed, 16 Jul 2003 16:44:44 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by eikenes.alvestrand.no (Postfix) with ESMTP id B163761A93 for ; Wed, 16 Jul 2003 16:44:42 +0200 (CEST) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6GEidtI010646; Wed, 16 Jul 2003 07:44:40 -0700 (PDT) Received: from sun.com (vpn-129-159-0-117.EMEA.Sun.COM [129.159.0.117]) by hs-ehdb03-01.Germany.Sun.COM (8.11.7+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id h6GEiaw04402; Wed, 16 Jul 2003 16:44:36 +0200 (MEST) Message-ID: <3F156478.60704@sun.com> Date: Wed, 16 Jul 2003 16:43:04 +0200 From: Erik Guttman User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, de, fr MIME-Version: 1.0 To: Ted Lemon References: <3F15125B.2090501@pobox.org.sg> <3F154C95.93EFAD0E@hursley.ibm.com> <3F15516A.9070309@sun.com> <200307161621.28713.mellon@fugue.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no, Scott W Brim , Brian E Carpenter Subject: Re: [Fwd: Re: rough consensus (was Re: "trouble maker")] X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Ted Lemon wrote: > On Wednesday 16 July 2003 15:21, Erik Guttman wrote: > >>d) Once a consensus statement is accepted by the working group >> we have something much more concrete than a record in WG >> minutes that such and such was decided upon, etc. > > > I think it's important to note here that silence does not indicate consent. > There are cases where a discussion in a working group becomes so voluminous > that people stop reading the mailing list, or even if they don't stop, they > may miss the consensus call, or may not have time to respond to it because > they are so behind in their day job because of keeping up with the mailing > list. Or they may just be so discouraged from what has happened that they > don't say anything because it seems futile to do so. Or they may be > reluctant to say anything because they feel that opening up the debate again > will just drive more working group members away. When that happens, you > can't really say the failure of those parties to protest means that the > working group agrees with your sense of what the consensus is. Ted, I agree. However, I think one can improve the current situation. It is much easier to read and consider a 'consensus statement' than the full-on fire hose of a working group mailing list discussing a divisive topic. The consensus statement I am describing summarizes all arguments for and against and makes a definitive call as well as its implications. Voicing effective criticism often requires full engagement with WG discussion to participate *at all*. We often lack time to do that. I believe that this is largely due to a failure on the part of WG chairs to document decisions and what led up to them. Given such a document, we (as lurkers/outsiders) can take issue or agree *with the document* without needing to master the huge volume of correspondence which preceded it. Erik From problem-statement-bounces@alvestrand.no Wed Jul 16 11:02:06 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05181 for ; Wed, 16 Jul 2003 11:02:06 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8F21861B98; Wed, 16 Jul 2003 17:01:37 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9CC2661BB0 for ; Sat, 12 Jul 2003 02:56:08 +0200 (CEST) Received: from localhost (astro.cs.utk.edu [160.36.58.43]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h6C0sNN29962; Fri, 11 Jul 2003 20:54:30 -0400 (EDT) Date: Fri, 11 Jul 2003 20:54:30 -0400 (EDT) Message-Id: <200307120054.h6C0sNN29962@astro.cs.utk.edu> From: Keith Moore NR-To: "Hallam-Baker, Phillip" NR-CC: moore@cs.utk.edu, problem-statement@alvestrand.no Subject-Was: RE: Plenary decision? To: undisclosed-recipients: ; X-Mailman-Approved-At: Wed, 16 Jul 2003 17:01:37 +0200 Subject: RFCs in HTML strawman X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no this discussion doesn't belong here. I've written a brief summaries of the barriers to using HTML for RFCs and placed it at http://www.cs.utk.edu/~moore/opinions/whether-rfcs-in-html.html It also explains what I believe would be necessary to make HTML be an acceptable format for IETF. It might be that the problems are solvable by someone with enough expertise in HTML and knowledge of the available tools. I'll update the page as people send me corrections and additions. Also, for several years there's been a list for discussing RFCs in HTML. A pointer to that list is in the above document. Now can we please drop this subject from the problem-statement list? Keith ] > As I said, I can't remember a time when the people ] > present who went up to mike to defend ASCII numbered less than at ] > least 3 times number of people who wanted to use some propietary ] > (i.e., MS Word) or non-editable (i.e., Postscript) formats. ] ] This is a straw man. HTML is a completely open format. ] ] If you use XHTML and define the schema appropriately you can ] easily verify that no proprietary extensions have been used. ] ] Alternatively there are plenty of tools to verify against a DTD. ] ] ] Phill From problem-statement-bounces@alvestrand.no Wed Jul 16 11:23:33 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05907 for ; Wed, 16 Jul 2003 11:23:32 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 61F7661B9B; Wed, 16 Jul 2003 17:23:04 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by eikenes.alvestrand.no (Postfix) with ESMTP id CA9B461B98 for ; Wed, 16 Jul 2003 17:23:01 +0200 (CEST) Received: from depa.dmes.org (unknown [81.160.214.60]) by toccata.fugue.com (Postfix) with ESMTP id 886611B20C2; Wed, 16 Jul 2003 10:16:57 -0500 (CDT) From: Ted Lemon To: Erik Guttman Date: Wed, 16 Jul 2003 17:22:46 +0200 User-Agent: KMail/1.5 References: <3F15125B.2090501@pobox.org.sg> <200307161621.28713.mellon@fugue.com> <3F156478.60704@sun.com> In-Reply-To: <3F156478.60704@sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200307161722.46460.mellon@nominum.com> Cc: problem-statement@alvestrand.no Subject: Re: [Fwd: Re: rough consensus (was Re: "trouble maker")] X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit On Wednesday 16 July 2003 16:43, Erik Guttman wrote: > Voicing effective criticism often requires full engagement with WG > discussion to participate *at all*. We often lack time to do that. > I believe that this is largely due to a failure on the part of WG > chairs to document decisions and what led up to them. Given such a > document, we (as lurkers/outsiders) can take issue or agree *with the > document* without needing to master the huge volume of correspondence > which preceded it. I am concerned that those who participate in this way may not get a helpful summary from the wg chair, since the arguments are necessarily filtered through the chair's understanding of the situation, and will tend to be colored by the chair's leanings on the matter. This seems like it's proposed as a solution to the problem of a too-loud objector on the wg mailing list, but I don't think that it solves the problem. My personal experience from having seen this solution implemented is that I do not think it successfully captures a consensus. When I saw this implemented in zeroconf, my impression was that it degenerated into a simple majority vote, which is not the same thing as rough consensus. From problem-statement-bounces@alvestrand.no Wed Jul 16 12:01:13 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06946 for ; Wed, 16 Jul 2003 12:01:04 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8452161B9B; Wed, 16 Jul 2003 18:00:30 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from vmmr8.verisignmail.com (vmmrnat.verisignmail.com [216.168.230.187]) by eikenes.alvestrand.no (Postfix) with ESMTP id C67FC61B98 for ; Wed, 16 Jul 2003 18:00:28 +0200 (CEST) Received: from ms3.verisignmail.com (ms3.verisignmail.com [216.168.230.176] (may be forged)) by vmmr8.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id ANX72196; Wed, 16 Jul 2003 12:00:26 -0400 (EDT) Received: from BOBDEV (pool-162-83-238-146.ny5030.east.verizon.net [162.83.238.146]) by ms3.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id AKW17067; Wed, 16 Jul 2003 12:00:25 -0400 (EDT) From: "Bob Wyman" To: "'Cyrus Shaoul'" , Date: Wed, 16 Jul 2003 12:00:27 -0400 Message-ID: <000d01c34bb3$600d2810$640aa8c0@BOBDEV> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: <20030716084824.58F3.CYRUS@ntt-at.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: RE: Hearing and Speaking Problems for Non-Native English speakingparticipants. X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list Reply-To: bob@wyman.us List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Cyrus Shaoul wrote: > very few work groups use the Jabber system, > and even fewer have good scribes. It seems that scribes and notetakers are often recruited at the last minute -- just as the WG session is starting. Often, there are either no volunteers or the chair is left accepting the assistance of the first who volunteers. This process is not one that is likely to result in quality results. I suggest that a WG Chair should be expected to arrange for proper and competent notetaking and Jabber scribes well before the WG session begins. bob wyman From problem-statement-bounces@alvestrand.no Wed Jul 16 13:59:50 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10528 for ; Wed, 16 Jul 2003 13:59:49 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5364C61BA0; Wed, 16 Jul 2003 19:59:20 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [194.196.100.235]) by eikenes.alvestrand.no (Postfix) with ESMTP id E2AE261A93 for ; Wed, 16 Jul 2003 19:59:18 +0200 (CEST) Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by d12lmsgate-2.de.ibm.com (8.12.9/8.12.8) with ESMTP id h6GHxD9d018516; Wed, 16 Jul 2003 19:59:13 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h6GHxCrd239260; Wed, 16 Jul 2003 19:59:12 +0200 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id TAA51180; Wed, 16 Jul 2003 19:59:10 +0200 Message-ID: <3F159274.F2D298FC@hursley.ibm.com> Date: Wed, 16 Jul 2003 19:59:16 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: bob@wyman.us References: <000d01c34bb3$600d2810$640aa8c0@BOBDEV> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no, "'Cyrus Shaoul'" Subject: Re: Hearing and Speaking Problems for Non-Native Englishspeakingparticipants. X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Jabber isn't a formal requirement, but meeting minutes are. So I would say a chair has an obligation to find a note taker, but a jabber scribe is an as-available extra. Brian Bob Wyman wrote: > > Cyrus Shaoul wrote: > > very few work groups use the Jabber system, > > and even fewer have good scribes. > It seems that scribes and notetakers are often recruited at the > last minute -- just as the WG session is starting. Often, there are > either no volunteers or the chair is left accepting the assistance of > the first who volunteers. This process is not one that is likely to > result in quality results. > I suggest that a WG Chair should be expected to arrange for > proper and competent notetaking and Jabber scribes well before the WG > session begins. > > bob wyman From problem-statement-bounces@alvestrand.no Wed Jul 16 14:20:14 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11211 for ; Wed, 16 Jul 2003 14:20:13 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id ECD6761B98; Wed, 16 Jul 2003 20:19:44 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0D70361A93 for ; Wed, 16 Jul 2003 20:19:43 +0200 (CEST) Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h6GIJduD025516 for ; Wed, 16 Jul 2003 11:19:40 -0700 (PDT) Received: from cisco.com (sjc-vpn3-327.cisco.com [10.21.65.71]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id AIB22894; Wed, 16 Jul 2003 11:15:03 -0700 (PDT) Received: by cisco.com (sSMTP sendmail emulation); Wed, 16 Jul 2003 20:19:37 +0200 Date: Wed, 16 Jul 2003 20:19:37 +0200 From: Scott W Brim To: problem-statement@alvestrand.no Message-ID: <20030716201937.I2136@sbrim-w2k01> Mail-Followup-To: Scott W Brim , problem-statement@alvestrand.no References: <20030716084824.58F3.CYRUS@ntt-at.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20030716084824.58F3.CYRUS@ntt-at.com>; from cyrus@ntt-at.com on Wed, Jul 16, 2003 at 09:23:39AM -0400 Subject: Re: Hearing and Speaking Problems for Non-Native English speaking participants. X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no On Wed, Jul 16, 2003 09:23:39AM -0400, Cyrus Shaoul allegedly wrote: > Does this make sense? I hope this point can get added in some form to > the problem statement. Thank you. From problem-statement-bounces@alvestrand.no Wed Jul 16 14:49:10 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12329 for ; Wed, 16 Jul 2003 14:49:08 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D21F761B98; Wed, 16 Jul 2003 20:48:39 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from drakken.dbc.mtview.ca.us (adsl-64-168-10-254.dsl.scrm01.pacbell.net [64.168.10.254]) by eikenes.alvestrand.no (Postfix) with ESMTP id D02E661B9B for ; Wed, 16 Jul 2003 18:37:08 +0200 (CEST) Received: from drakken.dbc.mtview.ca.us (localhost [127.0.0.1]) by drakken.dbc.mtview.ca.us (8.12.9/8.12.9) with SMTP id h6GGb7Uv000163; Wed, 16 Jul 2003 09:37:07 -0700 (PDT) Date: Wed, 16 Jul 2003 09:37:06 -0700 From: Marshall Rose To: bob@wyman.us Message-Id: <20030716093706.10ea6e55.mrose+mtr.ietf@dbc.mtview.ca.us> In-Reply-To: <000d01c34bb3$600d2810$640aa8c0@BOBDEV> References: <20030716084824.58F3.CYRUS@ntt-at.com> <000d01c34bb3$600d2810$640aa8c0@BOBDEV> Organization: Dover Beach Consulting, Inc. X-Mailer: Sylpheed version 0.8.11claws (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 16 Jul 2003 20:48:38 +0200 Cc: problem-statement@alvestrand.no, "'Cyrus Shaoul'" Subject: Re: Hearing and Speaking Problems for Non-Native English speakingparticipants. X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit > It seems that scribes and notetakers are often recruited at the > last minute -- just as the WG session is starting. Often, there are > either no volunteers or the chair is left accepting the assistance of > the first who volunteers. This process is not one that is likely to > result in quality results. yeah, i should have started earlier on arranging all this for vienna. my current thinking is to set-up a permanent server that hosts conference rooms for all wgs, along with a better set of instructions... /mtr From problem-statement-bounces@alvestrand.no Wed Jul 16 15:10:47 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13785 for ; Wed, 16 Jul 2003 15:10:46 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id EC0BB61B98; Wed, 16 Jul 2003 21:10:17 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by eikenes.alvestrand.no (Postfix) with ESMTP id C7ED761A93 for ; Wed, 16 Jul 2003 21:10:15 +0200 (CEST) Received: from BBFUJIP.brandenburg.com (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h6GJE1F11824 for ; Wed, 16 Jul 2003 12:14:02 -0700 Date: Wed, 16 Jul 2003 21:10:59 +0200 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/11) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <19941893770.20030716211059@brandenburg.com> To: problem-statement@alvestrand.no In-Reply-To: <20030716093706.10ea6e55.mrose+mtr.ietf@dbc.mtview.ca.us> References: <20030716084824.58F3.CYRUS@ntt-at.com> <000d01c34bb3$600d2810$640aa8c0@BOBDEV> <20030716093706.10ea6e55.mrose+mtr.ietf@dbc.mtview.ca.us> MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-15 Content-transfer-encoding: 8bit Subject: Re: Hearing and Speaking Problems for Non-Native English speakingparticipants. X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 8bit general question: >> It seems that scribes and notetakers are often recruited at the >> last minute -- just as the WG session is starting. Often, there are >> either no volunteers or the chair is left accepting the assistance of is there some reason that wg official scribe and jabber scribe cannot be exactly the same typing actions? in other words, is there any reason that typing notes to jabber cannot serve as the notes given to the chair? One advantage is that the chair then gets comments included from others. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Wed Jul 16 15:31:09 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14798 for ; Wed, 16 Jul 2003 15:31:08 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9272961B9F; Wed, 16 Jul 2003 21:30:39 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from relay1.softcomca.com (relay1.softcomca.com [168.144.1.67]) by eikenes.alvestrand.no (Postfix) with ESMTP id B36F761B98 for ; Wed, 16 Jul 2003 21:30:37 +0200 (CEST) Received: from M2W060.mail2web.com ([168.144.251.168]) by relay1.softcomca.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 16 Jul 2003 15:30:37 -0400 Message-ID: <265000-220037316193037308@M2W060.mail2web.com> X-Priority: 3 X-Originating-IP: 81.160.230.37 X-URL: http://mail2web.com/ From: "spencer@mcsr-labs.org" To: problem-statement@alvestrand.no Date: Wed, 16 Jul 2003 15:30:37 -0400 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 16 Jul 2003 19:30:37.0363 (UTC) FILETIME=[BBDD5030:01C34BD0] Subject: Re: Hearing and Speaking Problems for Non-Native Englishspeakingparticipants. X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list Reply-To: spencer@mcsr-labs.org List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: quoted-printable Dear Dave, I've chaired two Jabbered BoF meetings, and had "mixed results" - one meeting where we had excellent Jabber logs, and one where we had almost none=2E=2E=2E When we had Jabber logs, they were extremely helpful=2E The thing I would = be slightly concerned about is, I really like merging multiple scribe streams= to figure out what REALLY happened, modulo side conversations, potty breaks, and jet-lag-induced naps, and I'm not sure we'd get multiple Jabbe= r streams=2E So it would be good to have multiple scribes, one of whom could= be using Jabber=2E This does point up the difference between scribe notes and WG minutes=2E I= n most cases I've been involved with, we've had the choice of "he said/she said" notes with all the details, or summaries without all the details=2E = We have the possibility of publishing BOTH, and I think Jabber would help us make this happen=2E And what do others think? Spencer Original Message: ----------------- From: Dave Crocker dcrocker@brandenburg=2Ecom Date: Wed, 16 Jul 2003 21:10:59 +0200 To: problem-statement@alvestrand=2Eno Subject: Re: Hearing and Speaking Problems for Non-Native Englishspeakingparticipants=2E general question: >> =09It seems that scribes and notetakers are often recruited at the >> last minute -- just as the WG session is starting=2E Often, there are >> either no volunteers or the chair is left accepting the assistance of is there some reason that wg official scribe and jabber scribe cannot be exactly the same typing actions? in other words, is there any reason that typing notes to jabber cannot serve as the notes given to the chair? One advantage is that the chair then gets comments included from others=2E d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , -------------------------------------------------------------------- mail2web - Check your email from the web at http://mail2web=2Ecom/ =2E From problem-statement-bounces@alvestrand.no Wed Jul 16 16:49:37 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16912 for ; Wed, 16 Jul 2003 16:49:36 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C175861BAC; Wed, 16 Jul 2003 22:49:07 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from mr10.verisignmail.com (vmmrnat.verisignmail.com [216.168.230.187]) by eikenes.alvestrand.no (Postfix) with ESMTP id B460E61BAB for ; Wed, 16 Jul 2003 22:49:05 +0200 (CEST) Received: from ms3.verisignmail.com (ms3.verisignmail.com [216.168.230.176] (may be forged)) by mr10.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id ACU09982; Wed, 16 Jul 2003 16:47:41 -0400 (EDT) Received: from BOBDEV (pool-162-83-238-146.ny5030.east.verizon.net [162.83.238.146]) by ms3.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id AKW76792; Wed, 16 Jul 2003 16:47:40 -0400 (EDT) From: "Bob Wyman" To: "'Dave Crocker'" , Date: Wed, 16 Jul 2003 16:47:43 -0400 Message-ID: <002d01c34bdb$813ceac0$640aa8c0@BOBDEV> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: <19941893770.20030716211059@brandenburg.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: RE: Hearing and Speaking Problems for Non-Native Englishspeakingparticipants. X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list Reply-To: bob@wyman.us List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: quoted-printable Dave Crocker wrote: > any reason that typing notes to jabber cannot serve as=20 > the notes given to the chair? One advantage is that=20 > the chair then gets comments included from others. Using such a method of collecting notes would have the odd effect of giving an "advantage" to those who monitored the meeting via Jabber since they would be able to ensure that their comments were included in the notes while those who are physically at the meeting are often limited in their ability to comment due to limits on simultaneous speakers, access to the microphone, the chair's willingness to recognize them, etc. If this advantage comes to be recognized as significant, we might find even those who are physically at the meeting focusing more on the Jabber session than on the meeting itself. It should also be recognized that meeting transcriptions are often not "complete" as they are written. A good note taker will revise, amend, and reformat the notes prior to submitting them. For instance, in an effort to compress the text, a comment by Dave Crocker might be recorded as being from "crock" in the raw notes but expanded out to "Dave Crocker" in post-meeting editing. I think we should not expect that raw jabber logs will suffice as meeting minutes. bob wyman From problem-statement-bounces@alvestrand.no Wed Jul 16 17:17:11 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18009 for ; Wed, 16 Jul 2003 17:17:10 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7ECFC61BAC; Wed, 16 Jul 2003 23:16:42 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from vmmr7.verisignmail.com (vmmrnat.verisignmail.com [216.168.230.187]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6F94461BAC for ; Wed, 16 Jul 2003 23:16:40 +0200 (CEST) Received: from ms3.verisignmail.com (ms3.verisignmail.com [216.168.230.176] (may be forged)) by vmmr7.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id OYJ08827; Wed, 16 Jul 2003 17:16:37 -0400 (EDT) Received: from BOBDEV (pool-162-83-238-146.ny5030.east.verizon.net [162.83.238.146]) by ms3.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id AKW82426; Wed, 16 Jul 2003 17:16:36 -0400 (EDT) From: "Bob Wyman" To: "'Cyrus Shaoul'" , Date: Wed, 16 Jul 2003 17:16:39 -0400 Message-ID: <003001c34bdf$8c00aab0$640aa8c0@BOBDEV> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: <20030716084824.58F3.CYRUS@ntt-at.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: RE: Hearing and Speaking Problems for Non-Native English speakingparticipants. X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list Reply-To: bob@wyman.us List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: quoted-printable Cyrus Shaoul wrote: > Another problem is the delay in getting the meeting=20 > minutes and presentation slides published electronically.=20 > This process is uneven and for some WGs, may take more=20 > than one month to complete, leaving some non-native=20 > English speakers in the dark on what was said, and what=20 > consensus was reached during the meeting.=20 It seems that slides could be published more rapidly if WG Chairs simply required that slides, if in some "common" format, be loaded onto a common machine (the chair's laptop?) for display during sessions. This would centralize the things and thus relieve the chair of the problem of having to hunt down the slides after the meeting. All might benefit from this process since it would tend to eliminate the time-wasting delays as successive speakers go through the process of trying to get their laptops hooked up to the slide projectors. bob wyman From problem-statement-bounces@alvestrand.no Wed Jul 16 17:29:22 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18376 for ; Wed, 16 Jul 2003 17:29:22 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 68A9F61BAC; Wed, 16 Jul 2003 23:28:54 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by eikenes.alvestrand.no (Postfix) with ESMTP id 052F761BAB for ; Wed, 16 Jul 2003 23:28:52 +0200 (CEST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h6GLSMN28145; Wed, 16 Jul 2003 17:28:23 -0400 (EDT) Date: Wed, 16 Jul 2003 17:28:21 -0400 From: Keith Moore To: bob@wyman.us Message-Id: <20030716172821.132ead38.moore@cs.utk.edu> In-Reply-To: <003001c34bdf$8c00aab0$640aa8c0@BOBDEV> References: <20030716084824.58F3.CYRUS@ntt-at.com> <003001c34bdf$8c00aab0$640aa8c0@BOBDEV> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no, moore@cs.utk.edu, cyrus@ntt-at.com Subject: Re: Hearing and Speaking Problems for Non-Native English speakingparticipants. X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit > It seems that slides could be published more rapidly if WG > Chairs simply required that slides, if in some "common" format, be > loaded onto a common machine (the chair's laptop?) for display during > sessions. unfortunately there is no common format. yes, most presentation tools speak powerpoint, but even small font changes can break a presentation. of course, we're not trying to solve problems in this group, we're just trying to list them. and I agree that this problem is a serious enough one that it should be on the list. Keith From problem-statement-bounces@alvestrand.no Wed Jul 16 23:23:53 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28874 for ; Wed, 16 Jul 2003 23:23:53 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A6ACA61BAC; Thu, 17 Jul 2003 05:23:25 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5A6D361BA0 for ; Thu, 17 Jul 2003 05:23:23 +0200 (CEST) Received: from localhost (heard@localhost) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id h6H3NLZ26526 for ; Wed, 16 Jul 2003 20:23:22 -0700 X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Wed, 16 Jul 2003 20:23:20 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: problem-statement@alvestrand.no In-Reply-To: <20030716142758.H1940@sbrim-w2k01> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: [Fwd: Re: rough consensus (was Re: "trouble maker")] X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no On Wed, 16 Jul 2003, Scott W Brim wrote: > I like the idea that Chairs should document why they declared > consensus (or the lack of it). I agree. //cmh From problem-statement-bounces@alvestrand.no Thu Jul 17 03:35:50 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20372 for ; Thu, 17 Jul 2003 03:35:49 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DCA9361BAC; Thu, 17 Jul 2003 09:35:20 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9CDB361BA0 for ; Thu, 17 Jul 2003 09:35:18 +0200 (CEST) Received: from cisco.com (171.68.223.137) by sj-iport-2.cisco.com with ESMTP; 17 Jul 2003 00:34:53 -0700 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h6H7ZFuG000369; Thu, 17 Jul 2003 00:35:15 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJR04402; Thu, 17 Jul 2003 00:35:14 -0700 (PDT) Message-Id: <200307170735.AJR04402@mira-sjc5-c.cisco.com> To: Dave Crocker From: Melinda Shore In-Reply-To: Message from dcrocker@brandenburg.com of "Wed, 16 Jul 2003 21:10:59 +0200." <19941893770.20030716211059@brandenburg.com> Date: Thu, 17 Jul 2003 03:35:14 -0400 Cc: problem-statement@alvestrand.no Subject: Re: Hearing and Speaking Problems for Non-Native English speakingparticipants. X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no I've used jabber logs to help get meeting minutes together, but they can be pretty spotty (although sometimes they're extraordinarily great). This time I made an audio recording of the problem-statement meeting, just in case. Melinda From problem-statement-bounces@alvestrand.no Thu Jul 17 03:51:41 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21270 for ; Thu, 17 Jul 2003 03:51:38 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 03E7E61BAC; Thu, 17 Jul 2003 09:51:09 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by eikenes.alvestrand.no (Postfix) with ESMTP id D989661BA0 for ; Thu, 17 Jul 2003 09:51:07 +0200 (CEST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6H7p7B16775 for ; Thu, 17 Jul 2003 10:51:07 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 17 Jul 2003 10:51:07 +0300 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 17 Jul 2003 10:51:06 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 17 Jul 2003 10:51:06 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 17 Jul 2003 10:51:05 +0300 Message-ID: Thread-Topic: [Fwd: Re: rough consensus (was Re: "trouble maker")] Thread-Index: AcNLnXQ0eFqR/oPzTE+737DsaCGasgAmnyTQ From: To: , X-OriginalArrivalTime: 17 Jul 2003 07:51:06.0450 (UTC) FILETIME=[2DA9FB20:01C34C38] Cc: problem-statement@alvestrand.no, swb@employees.org Subject: RE: [Fwd: Re: rough consensus (was Re: "trouble maker")] X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: quoted-printable Hi Erik, This sounds like the best statement that I have heard on 'rough consensus' - one additional benefit about this is that if someone feels that the 'rough consensus' statement is in error, there are processes in the IETF for filing appeals. thanks, John > -----Original Message----- > From: ext Erik Guttman [mailto:erik.guttman@sun.com] > Sent: 16 July, 2003 16:22 > To: Brian E Carpenter > Cc: problem-statement@alvestrand.no; Scott W Brim > Subject: Re: [Fwd: Re: rough consensus (was Re: "trouble maker")] >=20 >=20 > Brian E Carpenter wrote: > > Scott W Brim wrote: > >>I like the idea that Chairs should document why they=20 > declared consensus > >>(or the lack of it). > >=20 > >=20 > > Agreed. But another thing that may be going on is Chairs=20 > making consensus=20 > > calls too late. >=20 > The hardest part of calling consensus is its subtlety. After 100s of > emails have been exchanged and a rough consensus has emerged=20 > it doesn't > really exist (have any reality) until the consensus has been put into > words by the chair. Without a coherent statement posted to the list > describing a consensus it is hard to know > - what actions it implies > - whether all dissenting views have been considered > - what compromises were made among those forming the consensus > (what were their positions originally and what did they agree to?) >=20 > Defending or questioning a consensus call requires mailing list > archeology, which is a tedious and inexact discipline. We should > do better and we can. >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > Solution discussion: >=20 > I have found that by documenting the >=20 > - final decision and action to take > - summary of the dominant consensus position taken, including > where they aren't in accord > - well worked out dissenting views > - notes from the WG chair (if needed), to clarify how a difficult > decisions was made and why it is reasonable. >=20 > This sounds like a lot of writing. It usually comes down to a page > or two, even for very complex decisions. Advantages of putting this > in the record are >=20 > a) You can point at it when someone wants to bring the topic up > again. >=20 > b) If the chair overlooks something, it is easy to reopen the > consensus call *for a very specific reason* without reopening > the whole debate. (Note: Sometimes WG chairs do not fully > understand the issues they are making a consensus call on. > By writing this consensus document, it is easy to determine > whether the argument has been correctly heard and evaluated.) >=20 > c) It is a extremely useful to have definitive instructions *what > to do* with a consensus decision. >=20 > d) Once a consensus statement is accepted by the working group > we have something much more concrete than a record in WG > minutes that such and such was decided upon, etc. >=20 > Erik >=20 >=20 From problem-statement-bounces@alvestrand.no Thu Jul 17 04:42:42 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23316 for ; Thu, 17 Jul 2003 04:42:41 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C351361BAC; Thu, 17 Jul 2003 10:42:12 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from smtp.ietf57.telekom.at (smtp.ietf57.telekom.at [81.160.16.8]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5A2CA61BAC for ; Thu, 17 Jul 2003 10:42:11 +0200 (CEST) Received: from [81.160.209.74] ([81.160.209.74]) by smtp.ietf57.telekom.at (8.11.7+Sun/8.10.2) with ESMTP id h6H8g3k20041; Thu, 17 Jul 2003 10:42:03 +0200 (MEST) Date: Thu, 17 Jul 2003 10:42:03 +0200 From: Martin Stiemerling To: Cyrus Shaoul , problem-statement@alvestrand.no Message-ID: <29650000.1058431323@localhost> In-Reply-To: <20030716084824.58F3.CYRUS@ntt-at.com> References: <20030716084824.58F3.CYRUS@ntt-at.com> X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: Hearing and Speaking Problems for Non-Native English speaking participants. X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Hi all, I just wanna give my view on this: I agree fully with the problem, since often non-native english speaker are somehow lost during IETF meetings (even me, mother-tongue is german). Native english speaker can go often very fast with their speech, sometimes without microphone and perhaps a very strong accent. So others might not understand about the ongoing discussions are. Even the newcomers introduction is hard to understand for non-native speaker (those introduction I have attended). Martin --On Wednesday, July 16, 2003 09:23:39 -0400 Cyrus Shaoul wrote: | Hi All, | | I have been lurking on the list for a while, but I wanted to contribute | my thoughts on the problem of difficulties in participation by non-native | English speakers. | | In draft-ietf-problem-issue-statement-02, it seems that the only place | where a related problem is discussed in section 2.6.6 (Concentration of | Influence in Too Few Hands). I support this section, as I feel that the | second paragraph describes a real problem. I work with a team of | Japanese IETF participants and they agree that this problem exists for | them. | | There was also some discussion in a list thread called "Accomodating ESL | speakers" recently about how non-native speakers have problems | understanding other native and non-native speakers at the IETF meetings. | | I think it would good to add a little section about this problem to the | problem-statement, unless it is already too late to do so. (I have ideas | on how to solve these problems, but I will save them until it is time to | provide solutions.) | | | | Hearing and Speaking Problems for Non-Native English speaking | participants. | | | At IETF meetings, many participants are non-native English speakers. | Many of these participants currently have trouble understanding and | following along with WG discussions when the person at the microphones, | speaks very quickly, with a strong accent, or in a very animated way | that can make it hard for non-native English speakers to understand what | they are saying. Another problem is when speakers use excessive amounts | of colloquial or idiomatic phrases. The meaning of these phrases, such | as "water under the bridge" and "whatcha talking about" and unclear and | can confuse non-native english speakers. A further problem for | non-native english speakers is that the effort to simultaneously read | slides with small letters on a screen and hear and understand the | content of a speech can be too much to handle. Evidence of this is in | the number of non-native English speakers taking photographs of the | projection screen and making private recordings of WG meetings for later | study (making it harder for them to interactively participate during the | WG meeting.) | | This problem is amplified when speakers do not speak into the microphone, | or use the microphone improperly. When the microphone is not used, the | sound may be too soft to be comprhensible to non-native speakers even | though it is marginally comprehensible to native english speakers. When | a microphone is not used properly, for example clipping it to a necktie | and then letting it drop, it can add small amounts of feedback to the | sound, making it very hard to understand for non-native English speakers. | | There is also a problem with using the Jabber chat system with an | official scribe as a support tool for non-native English speakers. The | benefit of being able to read a summary of the WG meeting in text in | realtime is undeniable, but haveing to constantly look down at a lap-top | (if you have one) while listening to a presentation is difficult and | distracting. Also, very few work groups use the Jabber system, and even | fewer have good scribes. | | Another problem is the delay in getting the meeting minutes and | presentation slides published electronically. This process is uneven and | for some WGs, may take more than one month to complete, leaving some | non-native English speakers in the dark on what was said, and what | consensus was reached during the meeting. | | ------------------ | | Does this make sense? I hope this point can get added in some form to | the problem statement. | | Thanks, | | Cyrus | | | Cyrus Shaoul | NTT Advanced Technology Corp. | cyrus@ntt-at.com | | Martin Stiemerling NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de From problem-statement-bounces@alvestrand.no Thu Jul 17 04:50:26 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23758 for ; Thu, 17 Jul 2003 04:50:25 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9B78961BAD; Thu, 17 Jul 2003 10:49:47 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from smtp.ietf57.telekom.at (smtp.ietf57.telekom.at [81.160.16.8]) by eikenes.alvestrand.no (Postfix) with ESMTP id C808561BA0 for ; Thu, 17 Jul 2003 10:49:45 +0200 (CEST) Received: from [81.160.209.74] ([81.160.209.74]) by smtp.ietf57.telekom.at (8.11.7+Sun/8.10.2) with ESMTP id h6H8lik20049; Thu, 17 Jul 2003 10:47:44 +0200 (MEST) Date: Thu, 17 Jul 2003 10:47:44 +0200 From: Martin Stiemerling To: john.loughney@nokia.com, erik.guttman@sun.com, brian@hursley.ibm.com Message-ID: <34720000.1058431664@localhost> In-Reply-To: References: X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: problem-statement@alvestrand.no, swb@employees.org Subject: RE: [Fwd: Re: rough consensus (was Re: "trouble maker")] X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Hi, the proposal of Erik sounds good so far, but what I'm missing is that the list of choices for rough consensus is missing. It should be documented what are the choices have been for voting on. Sometimes there is not only a yes/no decision, but a choice a,b, or c decision. So writing these choices down (nailing them down on paper) would be good as well. Martin --On Thursday, July 17, 2003 10:51:05 +0300 john.loughney@nokia.com wrote: | Hi Erik, | | This sounds like the best statement that I have heard on 'rough | consensus' - one additional benefit about this is that if someone | feels that the 'rough consensus' statement is in error, there | are processes in the IETF for filing appeals. | | thanks, | John | |> -----Original Message----- |> From: ext Erik Guttman [mailto:erik.guttman@sun.com] |> Sent: 16 July, 2003 16:22 |> To: Brian E Carpenter |> Cc: problem-statement@alvestrand.no; Scott W Brim |> Subject: Re: [Fwd: Re: rough consensus (was Re: "trouble maker")] |> |> |> Brian E Carpenter wrote: |> > Scott W Brim wrote: |> >> I like the idea that Chairs should document why they |> declared consensus |> >> (or the lack of it). |> > |> > |> > Agreed. But another thing that may be going on is Chairs |> making consensus |> > calls too late. |> |> The hardest part of calling consensus is its subtlety. After 100s of |> emails have been exchanged and a rough consensus has emerged |> it doesn't |> really exist (have any reality) until the consensus has been put into |> words by the chair. Without a coherent statement posted to the list |> describing a consensus it is hard to know |> - what actions it implies |> - whether all dissenting views have been considered |> - what compromises were made among those forming the consensus |> (what were their positions originally and what did they agree to?) |> |> Defending or questioning a consensus call requires mailing list |> archeology, which is a tedious and inexact discipline. We should |> do better and we can. |> |> ============================ |> Solution discussion: |> |> I have found that by documenting the |> |> - final decision and action to take |> - summary of the dominant consensus position taken, including |> where they aren't in accord |> - well worked out dissenting views |> - notes from the WG chair (if needed), to clarify how a difficult |> decisions was made and why it is reasonable. |> |> This sounds like a lot of writing. It usually comes down to a page |> or two, even for very complex decisions. Advantages of putting this |> in the record are |> |> a) You can point at it when someone wants to bring the topic up |> again. |> |> b) If the chair overlooks something, it is easy to reopen the |> consensus call *for a very specific reason* without reopening |> the whole debate. (Note: Sometimes WG chairs do not fully |> understand the issues they are making a consensus call on. |> By writing this consensus document, it is easy to determine |> whether the argument has been correctly heard and evaluated.) |> |> c) It is a extremely useful to have definitive instructions *what |> to do* with a consensus decision. |> |> d) Once a consensus statement is accepted by the working group |> we have something much more concrete than a record in WG |> minutes that such and such was decided upon, etc. |> |> Erik |> |> Martin Stiemerling NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de From problem-statement-bounces@alvestrand.no Thu Jul 17 05:30:33 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26235 for ; Thu, 17 Jul 2003 05:30:32 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 95A6F61BAF; Thu, 17 Jul 2003 11:30:03 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by eikenes.alvestrand.no (Postfix) with ESMTP id BFA7461BAE for ; Thu, 17 Jul 2003 11:30:00 +0200 (CEST) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h6H9Tvv5013210; Thu, 17 Jul 2003 03:29:58 -0600 (MDT) Received: from sun.com (vpn-129-159-0-92.EMEA.Sun.COM [129.159.0.92]) by hs-ehdb03-01.Germany.Sun.COM (8.11.7+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id h6H9Tsw19782; Thu, 17 Jul 2003 11:29:54 +0200 (MEST) Message-ID: <3F166C39.9020206@sun.com> Date: Thu, 17 Jul 2003 11:28:25 +0200 From: Erik Guttman User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, de, fr MIME-Version: 1.0 To: Martin Stiemerling References: <34720000.1058431664@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: john.loughney@nokia.com, problem-statement@alvestrand.no, swb@employees.org, brian@hursley.ibm.com Subject: Re: [Fwd: Re: rough consensus (was Re: "trouble maker")] X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Martin Stiemerling wrote: > Hi, > > the proposal of Erik sounds good so far, but what I'm missing is that > the list of choices for rough consensus is missing. Martin, When I have written consensus statements, I always list the conflicting positions which were taken and the contours and result of the debate. The summary reduces complex matters to a synopsis, sufficient for someone who is interested (but not involved) to follow up on. Debate participants can tell immediately whether the synopsis is fair or slanted and can insist on proper representation in the statement. > It should be documented what are the choices have been for voting on. Presenting things as 'Joe, John, Jim and Jazz argued blah, while Kevin and Karl maintained bleh. The WG went with blah because...' makes the decision resemble a vote; we list people by name, give numbers of participants and so on, to justify the decision. By writing down the grounds for decision, we have a concrete statement which can be criticized and evaluated. But this is not a vote. It is a judgment call based on the generally acknowledged technical strength of the arguments presented. We trust in the integrity and insight of the WG chairs and IESG members to be fair and correct. A written record improves accountability. > Sometimes there > is not only a yes/no decision, but a choice a,b, or c decision. I agree that a consensus decision may involve a merging of different positions. This is subtle stuff. The output of a decision is in many cases specific instructions to the document editor. Erik From problem-statement-bounces@alvestrand.no Thu Jul 17 05:31:54 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26410 for ; Thu, 17 Jul 2003 05:31:54 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6198661BAC; Thu, 17 Jul 2003 11:31:27 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by eikenes.alvestrand.no (Postfix) with ESMTP id 156C961BA0 for ; Thu, 17 Jul 2003 11:31:26 +0200 (CEST) Received: from depa.dmes.org (unknown [81.160.214.60]) by toccata.fugue.com (Postfix) with ESMTP id 07E771B214C; Thu, 17 Jul 2003 04:25:14 -0500 (CDT) From: Ted Lemon To: spencer@mcsr-labs.org, "spencer@mcsr-labs.org" , problem-statement@alvestrand.no Date: Thu, 17 Jul 2003 11:30:15 +0200 User-Agent: KMail/1.5 References: <265000-220037316193037308@M2W060.mail2web.com> In-Reply-To: <265000-220037316193037308@M2W060.mail2web.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200307171130.15885.mellon@nominum.com> Subject: Re: Hearing and Speaking Problems for Non-Native Englishspeakingparticipants. X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit On Wednesday 16 July 2003 21:30, spencer@mcsr-labs.org wrote: > This does point up the difference between scribe notes and WG minutes. In > most cases I've been involved with, we've had the choice of "he said/she > said" notes with all the details, or summaries without all the details. We > have the possibility of publishing BOTH, and I think Jabber would help us > make this happen. > > And what do others think? I'm a bit puzzled as to why we don't just record the entire meeting from the sound board, and do the minutes off of a complete transcript. This would provide a nice incentive for non-mike-talkers, and it's a lot more reliable than relying on random scribes, particularly since the scribes in question are usually active participants in the wg whose comments are lost when they go up to the microphone. From problem-statement-bounces@alvestrand.no Thu Jul 17 05:35:45 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26682 for ; Thu, 17 Jul 2003 05:35:44 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 23C4E61BAF; Thu, 17 Jul 2003 11:35:16 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from HALVESTR-W2K1.cisco.com (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E77C661BA0; Thu, 17 Jul 2003 11:35:13 +0200 (CEST) Date: Thu, 17 Jul 2003 10:56:09 +0200 From: Harald Tveit Alvestrand To: Brian E Carpenter , Scott W Brim Message-ID: <255277349.1058439369@localhost> In-Reply-To: <3F154C95.93EFAD0E@hursley.ibm.com> References: <3F15125B.2090501@pobox.org.sg> <174460250.1058358551@localhost> <3F152EC8.1AE7534B@hursley.ibm.com> <3F1534A9.9070307@pobox.org.sg> <20030716133310.E1940@sbrim-w2k01> <3F15435E.8020205@pobox.org.sg> <20030716142758.H1940@sbrim-w2k01> <3F154C95.93EFAD0E@hursley.ibm.com> X-Mailer: Mulberry/3.0.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: problem-statement@alvestrand.no Subject: Re: [Fwd: Re: rough consensus (was Re: "trouble maker")] X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit --On 16. juli 2003 15:01 +0200 Brian E Carpenter wrote: > Scott W Brim wrote: >> >> I like the idea that Chairs should document why they declared consensus >> (or the lack of it). > > Agreed. But another thing that may be going on is Chairs making consensus > calls too late. I think the problem WG meeting's discussion of the problem document on Tuesday actually was a fairly telling example of some of the subtleties of the rough consensus process. We had a number of "issues thought to be open". On every issue, we had a large number of speakers, trying to improve the WG's understanding that the issue was indeed real, and exploring subtle ramifications of the issue. People just observing the people at the mike, and not having read the drafts, would have a hard time detecting what the consensus of the room was. But when the WG chair called for consensus on *whether the document text was a good enough description of the issue*, the consensus of the room was pretty clear - on some issues, near-unanimous consent that it was good enough; on other issues, a clearly divided opinion that means that the issue has to be rehashed on the list. Calling consensus after just listening to the discussion is very hard. Calling consensus after asking a specific question and seeing the response is a lot easier - and a LOT easier to record. My 2 cents.... Harald From problem-statement-bounces@alvestrand.no Thu Jul 17 06:08:43 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28114 for ; Thu, 17 Jul 2003 06:08:43 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1A61B61BAC; Thu, 17 Jul 2003 12:08:15 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by eikenes.alvestrand.no (Postfix) with ESMTP id BB37E61BA0 for ; Thu, 17 Jul 2003 12:08:13 +0200 (CEST) Received: from employees.org (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 17 Jul 2003 03:12:55 -0700 Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h6HA88uJ002302 for ; Thu, 17 Jul 2003 03:08:09 -0700 (PDT) Received: from cisco.com (sjc-vpn4-91.cisco.com [10.21.80.91]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id AIB93511; Thu, 17 Jul 2003 03:03:22 -0700 (PDT) Received: by cisco.com (sSMTP sendmail emulation); Thu, 17 Jul 2003 12:08:06 +0200 Date: Thu, 17 Jul 2003 12:08:06 +0200 From: Scott W Brim To: problem-statement@alvestrand.no Message-ID: <20030717120806.C1976@sbrim-w2k01> Mail-Followup-To: Scott W Brim , problem-statement@alvestrand.no References: <34720000.1058431664@localhost> <3F166C39.9020206@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3F166C39.9020206@sun.com>; from erik.guttman@sun.com on Thu, Jul 17, 2003 at 11:28:25AM +0200 Subject: Re: [Fwd: Re: rough consensus (was Re: "trouble maker")] X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no On Thu, Jul 17, 2003 11:28:25AM +0200, Erik Guttman allegedly wrote: > Martin Stiemerling wrote: > > It should be documented what are the choices have been for voting on. > > Presenting things as 'Joe, John, Jim and Jazz argued blah, while > Kevin and Karl maintained bleh. The WG went with blah because...' > makes the decision resemble a vote; we list people by name, give > numbers of participants and so on, to justify the decision. By > writing down the grounds for decision, we have a concrete statement > which can be criticized and evaluated. But this is not a vote. It > is a judgment call based on the generally acknowledged technical > strength of the arguments presented. Saying who said what is for the meeting notes (so those participating only by mail can have a deep understanding of what went on there). Consensus documentation can stick to the issues. From problem-statement-bounces@alvestrand.no Thu Jul 17 06:12:14 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28229 for ; Thu, 17 Jul 2003 06:12:13 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9020B61BAC; Thu, 17 Jul 2003 12:11:45 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by eikenes.alvestrand.no (Postfix) with ESMTP id 15F1A61BA0 for ; Thu, 17 Jul 2003 12:11:44 +0200 (CEST) Received: from employees.org (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 17 Jul 2003 03:11:22 -0700 Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h6HABfuD008729 for ; Thu, 17 Jul 2003 03:11:41 -0700 (PDT) Received: from cisco.com (sjc-vpn4-91.cisco.com [10.21.80.91]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id AIB93624; Thu, 17 Jul 2003 03:06:55 -0700 (PDT) Received: by cisco.com (sSMTP sendmail emulation); Thu, 17 Jul 2003 12:11:38 +0200 Date: Thu, 17 Jul 2003 12:11:38 +0200 From: Scott W Brim To: problem-statement@alvestrand.no Message-ID: <20030717121138.D1976@sbrim-w2k01> Mail-Followup-To: Scott W Brim , problem-statement@alvestrand.no References: <265000-220037316193037308@M2W060.mail2web.com> <200307171130.15885.mellon@nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200307171130.15885.mellon@nominum.com>; from mellon@nominum.com on Thu, Jul 17, 2003 at 11:30:15AM +0200 Subject: Re: Hearing and Speaking Problems for Non-Native Englishspeakingparticipants. X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no We're in solution space, but I think there should be a separate big screen and projector for the jabber scribe (or detailed notetaker -- it's not clear whether the jabber thing has a future) so that people can see what the speaker says written down. From problem-statement-bounces@alvestrand.no Thu Jul 17 06:16:46 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28346 for ; Thu, 17 Jul 2003 06:16:46 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4F92E61BAD; Thu, 17 Jul 2003 12:16:18 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by eikenes.alvestrand.no (Postfix) with ESMTP id EADE161BA0 for ; Thu, 17 Jul 2003 12:16:16 +0200 (CEST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6HAGGB28584 for ; Thu, 17 Jul 2003 13:16:16 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 17 Jul 2003 13:16:16 +0300 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 17 Jul 2003 13:16:15 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 17 Jul 2003 13:16:14 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 17 Jul 2003 13:16:13 +0300 Message-ID: Thread-Topic: Hearing and Speaking Problems for Non-NativeEnglishspeakingparticipants. Thread-Index: AcNMTAXKHyBZmzTmQrWDtvS/3s5ZyQAAAeKQ From: To: , X-OriginalArrivalTime: 17 Jul 2003 10:16:14.0264 (UTC) FILETIME=[73ECF380:01C34C4C] Subject: RE: Hearing and Speaking Problems for Non-NativeEnglishspeakingparticipants. X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: quoted-printable Scott, I don't have an opinion on the discussion, but if I were to propose an problem, it would probably be along the lines that: The mechanics of face-to-face meeting times are often not managed effectively. John > -----Original Message----- > From: ext Scott W Brim [mailto:swb@employees.org] > Sent: 17 July, 2003 13:12 > To: problem-statement@alvestrand.no > Subject: Re: Hearing and Speaking Problems for > Non-NativeEnglishspeakingparticipants. >=20 >=20 > We're in solution space, but I think there should be a separate big > screen and projector for the jabber scribe (or detailed notetaker -- > it's not clear whether the jabber thing has a future) so that=20 > people can > see what the speaker says written down. >=20 From problem-statement-bounces@alvestrand.no Thu Jul 17 06:22:29 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28434 for ; Thu, 17 Jul 2003 06:22:28 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1A92F61BAE; Thu, 17 Jul 2003 12:22:01 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by eikenes.alvestrand.no (Postfix) with ESMTP id 229EA61BA0 for ; Thu, 17 Jul 2003 12:21:59 +0200 (CEST) Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h6HALuuG002949 for ; Thu, 17 Jul 2003 03:21:56 -0700 (PDT) Received: from cisco.com (sjc-vpn4-91.cisco.com [10.21.80.91]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id AIB93934; Thu, 17 Jul 2003 03:17:10 -0700 (PDT) Received: by cisco.com (sSMTP sendmail emulation); Thu, 17 Jul 2003 12:21:54 +0200 Date: Thu, 17 Jul 2003 12:21:54 +0200 From: Scott W Brim To: problem-statement@alvestrand.no Message-ID: <20030717122154.F1976@sbrim-w2k01> Mail-Followup-To: Scott W Brim , problem-statement@alvestrand.no References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from john.loughney@nokia.com on Thu, Jul 17, 2003 at 01:16:13PM +0300 Subject: Re: Hearing and Speaking Problems for Non-NativeEnglishspeakingparticipants. X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no On Thu, Jul 17, 2003 01:16:13PM +0300, john.loughney@nokia.com allegedly wrote: > Scott, > > I don't have an opinion on the discussion, but if I were to propose > an problem, it would probably be along the lines that: > > The mechanics of face-to-face meeting times are often not managed > effectively. I liked Cyrus's original, large explication of the problem. From problem-statement-bounces@alvestrand.no Thu Jul 17 06:52:23 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29279 for ; Thu, 17 Jul 2003 06:52:22 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id F21E561BAD; Thu, 17 Jul 2003 12:51:54 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from smtp.ietf57.telekom.at (smtp.ietf57.telekom.at [81.160.16.8]) by eikenes.alvestrand.no (Postfix) with ESMTP id C170161BAC for ; Thu, 17 Jul 2003 12:51:52 +0200 (CEST) Received: from [81.160.135.215] (Warabi.ietf57.telekom.at [81.160.135.215]) by smtp.ietf57.telekom.at (8.11.7+Sun/8.10.2) with ESMTP id h6HApqk20325 for ; Thu, 17 Jul 2003 12:51:52 +0200 (MEST) Date: Thu, 17 Jul 2003 06:51:51 -0400 From: Cyrus Shaoul To: problem-statement@alvestrand.no In-Reply-To: <20030717122154.F1976@sbrim-w2k01> References: <20030717122154.F1976@sbrim-w2k01> Message-Id: <20030717064517.4B6C.CYRUS@tomigaia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.05.06 Subject: Re[2]: Hearing and Speaking Problems for Non-NativeEnglishspeakingparticipants. X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit John, Perhaps the face-to-face meeting time mechanics problem has overlap with the non-native English speaker problem, but also covers native English speakers as well. (Jabber, Scribes, lack of audio recordings of all meetings, Presentation file format inconsistencies, etc) Are there any other problems like this, and is this worth adding? Cyrus On Thu, 17 Jul 2003 12:21:54 +0200 Scott W Brim wrote: swb> On Thu, Jul 17, 2003 01:16:13PM +0300, john.loughney@nokia.com allegedly wrote: swb> > Scott, swb> > swb> > I don't have an opinion on the discussion, but if I were to propose swb> > an problem, it would probably be along the lines that: swb> > swb> > The mechanics of face-to-face meeting times are often not managed swb> > effectively. swb> swb> I liked Cyrus's original, large explication of the problem. Cyrus Shaoul CEO Tomigaia Inc. http://www.tomigaia.com/ cyrus@tomigaia.com 646-645-6881 From problem-statement-bounces@alvestrand.no Thu Jul 17 08:52:58 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04322 for ; Thu, 17 Jul 2003 08:52:57 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 59BB761BAD; Thu, 17 Jul 2003 14:52:28 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from relay1.softcomca.com (relay1.softcomca.com [168.144.1.67]) by eikenes.alvestrand.no (Postfix) with ESMTP id E027961BAC for ; Thu, 17 Jul 2003 14:52:26 +0200 (CEST) Received: from M2W073.mail2web.com ([168.144.251.183]) by relay1.softcomca.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 17 Jul 2003 08:52:26 -0400 Message-ID: <184670-220037417125226270@M2W073.mail2web.com> X-Priority: 3 X-Originating-IP: 81.160.181.122 X-URL: http://mail2web.com/ From: "spencer@mcsr-labs.org" To: problem-statement@alvestrand.no Date: Thu, 17 Jul 2003 08:52:26 -0400 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 17 Jul 2003 12:52:26.0276 (UTC) FILETIME=[46147E40:01C34C62] Subject: Re: Hearing and Speaking Problems for Non-Native Englishspeakingparticipants. X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list Reply-To: spencer@mcsr-labs.org List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: quoted-printable Dear Ted, Of COURSE WG chairs ask the most contentious mike speakers to take minutes= during the meeting=2E=2E=2E=20 Expect to see more helpful hints like this as we continue to develop WG chair training! :} Spencer Original Message: ----------------- From: Ted Lemon mellon@nominum=2Ecom Date: Thu, 17 Jul 2003 11:30:15 +0200 To: spencer@mcsr-labs=2Eorg, spencer@mcsr-labs=2Eorg, problem-statement@alvestrand=2Eno Subject: Re: Hearing and Speaking Problems for Non-Native Englishspeakingparticipants=2E On Wednesday 16 July 2003 21:30, spencer@mcsr-labs=2Eorg wrote: > This does point up the difference between scribe notes and WG minutes=2E= In > most cases I've been involved with, we've had the choice of "he said/she= > said" notes with all the details, or summaries without all the details=2E= We > have the possibility of publishing BOTH, and I think Jabber would help u= s > make this happen=2E > > And what do others think? I'm a bit puzzled as to why we don't just record the entire meeting from the=20 sound board, and do the minutes off of a complete transcript=2E This wou= ld=20 provide a nice incentive for non-mike-talkers, and it's a lot more reliabl= e=20 than relying on random scribes, particularly since the scribes in question= =20 are usually active participants in the wg whose comments are lost when the= y=20 go up to the microphone=2E -------------------------------------------------------------------- mail2web - Check your email from the web at http://mail2web=2Ecom/ =2E From problem-statement-bounces@alvestrand.no Thu Jul 17 10:13:37 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08244 for ; Thu, 17 Jul 2003 10:13:37 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2073D61BAD; Thu, 17 Jul 2003 16:13:08 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by eikenes.alvestrand.no (Postfix) with ESMTP id 42D3461B9A; Thu, 17 Jul 2003 16:13:06 +0200 (CEST) Received: from tsg1 (183.sanjose-03-04rs16rt.ca.dial-access.att.net[12.81.1.183]) by mtiwmhc12.worldnet.att.net (mtiwmhc12) with SMTP id <20030717141303112000ohp7e>; Thu, 17 Jul 2003 14:13:04 +0000 Message-ID: <042c01c34c6d$8709d2a0$020aff0a@tsg1> From: "todd glassey" To: "Harald Tveit Alvestrand" , "Brian E Carpenter" , "Scott W Brim" References: <3F15125B.2090501@pobox.org.sg><174460250.1058358551@localhost> <3F152EC8.1AE7534B@hursley.ibm.com><3F1534A9.9070307@pobox.org.sg> <20030716133310.E1940@sbrim-w2k01><3F15435E.8020205@pobox.org.sg> <20030716142758.H1940@sbrim-w2k01><3F154C95.93EFAD0E@hursley.ibm.com> <255277349.1058439369@localhost> Date: Thu, 17 Jul 2003 07:12:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Cc: problem-statement@alvestrand.no Subject: Re: [Fwd: Re: rough consensus (was Re: "trouble maker")] X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Harald's right. Consensus needs to be obtained on specific items and not generalizations. The reasoning for this is that Consensus is something that MUST be demonstrable in retrospect if its to be of any value at all in demonstrating fair-play... Otherwise, there is an issue... Todd ----- Original Message ----- From: "Harald Tveit Alvestrand" To: "Brian E Carpenter" ; "Scott W Brim" Cc: Sent: Thursday, July 17, 2003 1:56 AM Subject: Re: [Fwd: Re: rough consensus (was Re: "trouble maker")] > > > --On 16. juli 2003 15:01 +0200 Brian E Carpenter > wrote: > > > Scott W Brim wrote: > >> > >> I like the idea that Chairs should document why they declared consensus > >> (or the lack of it). > > > > Agreed. But another thing that may be going on is Chairs making consensus > > calls too late. > > I think the problem WG meeting's discussion of the problem document on > Tuesday actually was a fairly telling example of some of the subtleties of > the rough consensus process. > > We had a number of "issues thought to be open". > On every issue, we had a large number of speakers, trying to improve the > WG's understanding that the issue was indeed real, and exploring subtle > ramifications of the issue. People just observing the people at the mike, > and not having read the drafts, would have a hard time detecting what the > consensus of the room was. > > But when the WG chair called for consensus on *whether the document text > was a good enough description of the issue*, the consensus of the room was > pretty clear - on some issues, near-unanimous consent that it was good > enough; on other issues, a clearly divided opinion that means that the > issue has to be rehashed on the list. > > Calling consensus after just listening to the discussion is very hard. > Calling consensus after asking a specific question and seeing the response > is a lot easier - and a LOT easier to record. > > My 2 cents.... > > Harald > From problem-statement-bounces@alvestrand.no Thu Jul 17 10:51:48 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09910 for ; Thu, 17 Jul 2003 10:51:47 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D678961BAC; Thu, 17 Jul 2003 16:51:18 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by eikenes.alvestrand.no (Postfix) with ESMTP id 40B6361B9A for ; Thu, 17 Jul 2003 16:51:17 +0200 (CEST) Received: from tsg1 (183.sanjose-03-04rs16rt.ca.dial-access.att.net[12.81.1.183]) by mtiwmhc12.worldnet.att.net (mtiwmhc12) with SMTP id <20030717145115112002sud8e>; Thu, 17 Jul 2003 14:51:15 +0000 Message-ID: <048101c34c72$dcc31120$020aff0a@tsg1> From: "todd glassey" To: "Scott W Brim" , References: <265000-220037316193037308@M2W060.mail2web.com><200307171130.15885.mellon@nominum.com> <20030717121138.D1976@sbrim-w2k01> Date: Thu, 17 Jul 2003 07:33:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: PROBLEM: We may need a Jabber Services BCP done as part of the Governance Model X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Scott and All, In bringing up the legal issues about not having some process for people with vocal problems to participate, it seems to me that what's missing is a Jabber Services BCP to define this. What it should contain is Jabber Support protocol (set of operational methods) as we are noting here for allowing someone to participate fully through Jabber. Also for archiving and reducing the Jabber Sessions to the formal archive of the WG and the IETF as a whole. Just my 2 cents Todd ----- Original Message ----- From: "Scott W Brim" To: Sent: Thursday, July 17, 2003 3:11 AM Subject: Re: Hearing and Speaking Problems for Non-NativeEnglishspeakingparticipants. > We're in solution space, but I think there should be a separate big > screen and projector for the jabber scribe (or detailed notetaker -- > it's not clear whether the jabber thing has a future) so that people can > see what the speaker says written down. From problem-statement-bounces@alvestrand.no Thu Jul 17 10:51:55 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09942 for ; Thu, 17 Jul 2003 10:51:54 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 843A861BB0; Thu, 17 Jul 2003 16:51:27 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3E61061BAE for ; Thu, 17 Jul 2003 16:51:19 +0200 (CEST) Received: from tsg1 (183.sanjose-03-04rs16rt.ca.dial-access.att.net[12.81.1.183]) by mtiwmhc12.worldnet.att.net (mtiwmhc12) with SMTP id <20030717145117112002sud9e>; Thu, 17 Jul 2003 14:51:18 +0000 Message-ID: <048201c34c72$de273500$020aff0a@tsg1> From: "todd glassey" To: "Scott W Brim" , References: <265000-220037316193037308@M2W060.mail2web.com><200307171130.15885.mellon@nominum.com> <20030717121138.D1976@sbrim-w2k01> Date: Thu, 17 Jul 2003 07:35:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Cc: "Contreras, Jorge" Subject: Jabber and Handicapped access - its not a choice but a necessity - Was: Hearing and Speaking Problems for... X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Scott Jabber style (chat) access is not a choice but probably rather a legal necessity to maintain the IETF's being open to all. The other issue is how the people in a meeting are supposed to relate/Inter-relate to the Jabber based speaker??? I suggest we ask Jorge on this regarding the ADA and other issues that the IETF's processes may not meet yet. As to the jabber concepts themselves, my feeling is that this is not just a Jabber issue for people remotely accessing the meetings, but rather its about 'Handicapped Access' to the Standards Process, and there are any number of legal reasons for insisting on/mandating this ... So maybe the real question here is to answer this then - how would we allow someone who was mute (handicapped) from some vocal-chord trauma or throat cancer, etc. to participate and to participate equally whether they are there or online. Todd ----- Original Message ----- From: "Scott W Brim" To: Sent: Thursday, July 17, 2003 3:11 AM Subject: Re: Hearing and Speaking Problems for Non-NativeEnglishspeakingparticipants. > We're in solution space, but I think there should be a separate big > screen and projector for the jabber scribe (or detailed notetaker -- > it's not clear whether the jabber thing has a future) so that people can > see what the speaker says written down. From problem-statement-bounces@alvestrand.no Thu Jul 17 10:52:06 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09971 for ; Thu, 17 Jul 2003 10:52:05 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4BFD661BAE; Thu, 17 Jul 2003 16:51:38 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by eikenes.alvestrand.no (Postfix) with ESMTP id 633D661BAE for ; Thu, 17 Jul 2003 16:51:26 +0200 (CEST) Received: from tsg1 (183.sanjose-03-04rs16rt.ca.dial-access.att.net[12.81.1.183]) by mtiwmhc12.worldnet.att.net (mtiwmhc12) with SMTP id <20030717145123112002sudce>; Thu, 17 Jul 2003 14:51:24 +0000 Message-ID: <048901c34c72$e2131530$020aff0a@tsg1> From: "todd glassey" To: "Martin Stiemerling" , "Cyrus Shaoul" , References: <20030716084824.58F3.CYRUS@ntt-at.com> <29650000.1058431323@localhost> Date: Thu, 17 Jul 2003 07:41:17 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: Re: Hearing and Speaking Problems for Non-Native English speaking participants. X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit To play the Devil's Advocate here - One thing that we MUST take note of is that any multi-lingual services add cost and overhead to the IETF's already financially taxed processes. How would anyone propose we pay for these expanded services? Also this brings up an issue of perhaps it is OK for a WG to have a mother-language as it were and to conduct its operations in that language. Todd ----- Original Message ----- From: "Martin Stiemerling" To: "Cyrus Shaoul" ; Sent: Thursday, July 17, 2003 1:42 AM Subject: Re: Hearing and Speaking Problems for Non-Native English speaking participants. > Hi all, > > I just wanna give my view on this: > I agree fully with the problem, since often non-native english speaker are > somehow lost during IETF meetings (even me, mother-tongue is german). > Native english speaker can go often very fast with their speech, sometimes > without microphone and perhaps a very strong accent. So others might not > understand about the ongoing discussions are. > > Even the newcomers introduction is hard to understand for non-native > speaker (those introduction I have attended). > > Martin > > --On Wednesday, July 16, 2003 09:23:39 -0400 Cyrus Shaoul > wrote: > > | Hi All, > | > | I have been lurking on the list for a while, but I wanted to contribute > | my thoughts on the problem of difficulties in participation by non-native > | English speakers. > | > | In draft-ietf-problem-issue-statement-02, it seems that the only place > | where a related problem is discussed in section 2.6.6 (Concentration of > | Influence in Too Few Hands). I support this section, as I feel that the > | second paragraph describes a real problem. I work with a team of > | Japanese IETF participants and they agree that this problem exists for > | them. > | > | There was also some discussion in a list thread called "Accomodating ESL > | speakers" recently about how non-native speakers have problems > | understanding other native and non-native speakers at the IETF meetings. > | > | I think it would good to add a little section about this problem to the > | problem-statement, unless it is already too late to do so. (I have ideas > | on how to solve these problems, but I will save them until it is time to > | provide solutions.) > | > | > | > | Hearing and Speaking Problems for Non-Native English speaking > | participants. > | > | > | At IETF meetings, many participants are non-native English speakers. > | Many of these participants currently have trouble understanding and > | following along with WG discussions when the person at the microphones, > | speaks very quickly, with a strong accent, or in a very animated way > | that can make it hard for non-native English speakers to understand what > | they are saying. Another problem is when speakers use excessive amounts > | of colloquial or idiomatic phrases. The meaning of these phrases, such > | as "water under the bridge" and "whatcha talking about" and unclear and > | can confuse non-native english speakers. A further problem for > | non-native english speakers is that the effort to simultaneously read > | slides with small letters on a screen and hear and understand the > | content of a speech can be too much to handle. Evidence of this is in > | the number of non-native English speakers taking photographs of the > | projection screen and making private recordings of WG meetings for later > | study (making it harder for them to interactively participate during the > | WG meeting.) > | > | This problem is amplified when speakers do not speak into the microphone, > | or use the microphone improperly. When the microphone is not used, the > | sound may be too soft to be comprhensible to non-native speakers even > | though it is marginally comprehensible to native english speakers. When > | a microphone is not used properly, for example clipping it to a necktie > | and then letting it drop, it can add small amounts of feedback to the > | sound, making it very hard to understand for non-native English speakers. > | > | There is also a problem with using the Jabber chat system with an > | official scribe as a support tool for non-native English speakers. The > | benefit of being able to read a summary of the WG meeting in text in > | realtime is undeniable, but haveing to constantly look down at a lap-top > | (if you have one) while listening to a presentation is difficult and > | distracting. Also, very few work groups use the Jabber system, and even > | fewer have good scribes. > | > | Another problem is the delay in getting the meeting minutes and > | presentation slides published electronically. This process is uneven and > | for some WGs, may take more than one month to complete, leaving some > | non-native English speakers in the dark on what was said, and what > | consensus was reached during the meeting. > | > | ------------------ > | > | Does this make sense? I hope this point can get added in some form to > | the problem statement. > | > | Thanks, > | > | Cyrus > | > | > | Cyrus Shaoul > | NTT Advanced Technology Corp. > | cyrus@ntt-at.com > | > | > > > > Martin Stiemerling > > NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de > IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de From problem-statement-bounces@alvestrand.no Thu Jul 17 10:52:07 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09972 for ; Thu, 17 Jul 2003 10:52:06 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3FEF361BD5; Thu, 17 Jul 2003 16:51:39 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by eikenes.alvestrand.no (Postfix) with ESMTP id F31DD61BB8; Thu, 17 Jul 2003 16:51:28 +0200 (CEST) Received: from tsg1 (183.sanjose-03-04rs16rt.ca.dial-access.att.net[12.81.1.183]) by mtiwmhc12.worldnet.att.net (mtiwmhc12) with SMTP id <20030717145126112002sudde>; Thu, 17 Jul 2003 14:51:27 +0000 Message-ID: <048a01c34c72$e3d44d30$020aff0a@tsg1> From: "todd glassey" To: , , , "Contreras, Jorge" , "Harald Tveit Alvestrand" References: Date: Thu, 17 Jul 2003 07:48:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: Re: Hearing and Speaking Problems X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit John I would list the problems as: 1) There is a legal requirement to provide equal levels of access to the processes in whatever language(s) that we choose, and that is part of the Americans with Disabilities Act and nothing else. The IETF is a US Corporate Structure (an arm of ISOC which is a US Corporation) and so the IETF MUST meet the ADA's requirements whatever that means I am willing to bet (lets ask our counsel - "Jorge do you concur here?") 2) There is an organizational mandate to provide capture of any solutions to meet #1 above as part of the global and interactive records of the IETF. And this is true for both forensic purposes but also to promote equal access. 3) Now and only now, does the ESL issue pop up, but it is the third issue on this list not the first. Also realize that for each language supported the IETF will be mandated to address #1's and #2's issues and requirements for meeting them making processing ESL type disclosures VERY costly with the current setups IMHO. Any comments? Todd ----- Original Message ----- From: To: ; Sent: Thursday, July 17, 2003 3:16 AM Subject: RE: Hearing and Speaking Problems forNon-NativeEnglishspeakingparticipants. Scott, I don't have an opinion on the discussion, but if I were to propose an problem, it would probably be along the lines that: The mechanics of face-to-face meeting times are often not managed effectively. John > -----Original Message----- > From: ext Scott W Brim [mailto:swb@employees.org] > Sent: 17 July, 2003 13:12 > To: problem-statement@alvestrand.no > Subject: Re: Hearing and Speaking Problems for > Non-NativeEnglishspeakingparticipants. > > > We're in solution space, but I think there should be a separate big > screen and projector for the jabber scribe (or detailed notetaker -- > it's not clear whether the jabber thing has a future) so that > people can > see what the speaker says written down. > From problem-statement-bounces@alvestrand.no Thu Jul 17 14:02:48 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15694 for ; Thu, 17 Jul 2003 14:02:46 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 08F6E61BAC; Thu, 17 Jul 2003 20:01:41 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from smtp.ietf57.telekom.at (smtp.ietf57.telekom.at [81.160.16.8]) by eikenes.alvestrand.no (Postfix) with ESMTP id BE54761B9A for ; Thu, 17 Jul 2003 20:01:39 +0200 (CEST) Received: from [81.160.209.74] ([81.160.209.74]) by smtp.ietf57.telekom.at (8.11.7+Sun/8.10.2) with ESMTP id h6HI1Qk21139; Thu, 17 Jul 2003 20:01:26 +0200 (MEST) Date: Thu, 17 Jul 2003 20:01:26 +0200 From: Martin Stiemerling To: todd glassey , Cyrus Shaoul , problem-statement@alvestrand.no Message-ID: <17450000.1058464885@localhost> In-Reply-To: <048901c34c72$e2131530$020aff0a@tsg1> References: <20030716084824.58F3.CYRUS@ntt-at.com> <29650000.1058431323@localhost> <048901c34c72$e2131530$020aff0a@tsg1> X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: Hearing and Speaking Problems for Non-Native English speaking participants. X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit --On Thursday, July 17, 2003 07:41:17 -0700 todd glassey wrote: | To play the Devil's Advocate here - Good to have it :-) | | One thing that we MUST take note of is that any multi-lingual services add | cost and overhead to the IETF's already financially taxed processes. How | would anyone propose we pay for these expanded services? I feel that is too much, adding a multi-lingual services (as the UN does, and producing tons of paper each year). The point as raised is, that everybody should be aware of the lingual capabilities of each other pariticipants. That just an issue of respect. | | Also this brings up an issue of perhaps it is OK for a WG to have a | mother-language as it were and to conduct its operations in that language. | | Todd | ----- Original Message ----- | From: "Martin Stiemerling" | To: "Cyrus Shaoul" ; | Sent: Thursday, July 17, 2003 1:42 AM | Subject: Re: Hearing and Speaking Problems for Non-Native English speaking | participants. | | |> Hi all, |> |> I just wanna give my view on this: |> I agree fully with the problem, since often non-native english speaker |> are somehow lost during IETF meetings (even me, mother-tongue is german). |> Native english speaker can go often very fast with their speech, |> sometimes without microphone and perhaps a very strong accent. So others |> might not understand about the ongoing discussions are. |> |> Even the newcomers introduction is hard to understand for non-native |> speaker (those introduction I have attended). |> |> Martin |> |> --On Wednesday, July 16, 2003 09:23:39 -0400 Cyrus Shaoul |> wrote: |> |> | Hi All, |> | |> | I have been lurking on the list for a while, but I wanted to contribute |> | my thoughts on the problem of difficulties in participation by | non-native |> | English speakers. |> | |> | In draft-ietf-problem-issue-statement-02, it seems that the only place |> | where a related problem is discussed in section 2.6.6 (Concentration of |> | Influence in Too Few Hands). I support this section, as I feel that the |> | second paragraph describes a real problem. I work with a team of |> | Japanese IETF participants and they agree that this problem exists for |> | them. |> | |> | There was also some discussion in a list thread called "Accomodating |> | ESL speakers" recently about how non-native speakers have problems |> | understanding other native and non-native speakers at the IETF |> | meetings. |> | |> | I think it would good to add a little section about this problem to the |> | problem-statement, unless it is already too late to do so. (I have |> | ideas on how to solve these problems, but I will save them until it is |> | time to provide solutions.) |> | |> | |> | |> | Hearing and Speaking Problems for Non-Native English speaking |> | participants. |> | |> | |> | At IETF meetings, many participants are non-native English speakers. |> | Many of these participants currently have trouble understanding and |> | following along with WG discussions when the person at the microphones, |> | speaks very quickly, with a strong accent, or in a very animated way |> | that can make it hard for non-native English speakers to understand |> | what they are saying. Another problem is when speakers use excessive |> | amounts of colloquial or idiomatic phrases. The meaning of these |> | phrases, such as "water under the bridge" and "whatcha talking about" |> | and unclear and can confuse non-native english speakers. A further |> | problem for non-native english speakers is that the effort to |> | simultaneously read slides with small letters on a screen and hear and |> | understand the content of a speech can be too much to handle. Evidence |> | of this is in the number of non-native English speakers taking |> | photographs of the projection screen and making private recordings of |> | WG meetings for later study (making it harder for them to |> | interactively participate during the WG meeting.) |> | |> | This problem is amplified when speakers do not speak into the | microphone, |> | or use the microphone improperly. When the microphone is not used, the |> | sound may be too soft to be comprhensible to non-native speakers even |> | though it is marginally comprehensible to native english speakers. When |> | a microphone is not used properly, for example clipping it to a necktie |> | and then letting it drop, it can add small amounts of feedback to the |> | sound, making it very hard to understand for non-native English | speakers. |> | |> | There is also a problem with using the Jabber chat system with an |> | official scribe as a support tool for non-native English speakers. The |> | benefit of being able to read a summary of the WG meeting in text in |> | realtime is undeniable, but haveing to constantly look down at a |> | lap-top (if you have one) while listening to a presentation is |> | difficult and distracting. Also, very few work groups use the Jabber |> | system, and even fewer have good scribes. |> | |> | Another problem is the delay in getting the meeting minutes and |> | presentation slides published electronically. This process is uneven |> | and for some WGs, may take more than one month to complete, leaving |> | some non-native English speakers in the dark on what was said, and what |> | consensus was reached during the meeting. |> | |> | ------------------ |> | |> | Does this make sense? I hope this point can get added in some form to |> | the problem statement. |> | |> | Thanks, |> | |> | Cyrus |> | |> | |> | Cyrus Shaoul |> | NTT Advanced Technology Corp. |> | cyrus@ntt-at.com |> | |> | |> |> |> |> Martin Stiemerling |> |> NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de |> IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de | Martin Stiemerling NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de From problem-statement-bounces@alvestrand.no Thu Jul 17 15:48:24 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20250 for ; Thu, 17 Jul 2003 15:48:23 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A7F3D61BAC; Thu, 17 Jul 2003 21:47:54 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from relay0.netfirms.com (m0.netfirms.com [209.171.43.51]) by eikenes.alvestrand.no (Postfix) with SMTP id 5FF4C61B9A for ; Thu, 17 Jul 2003 21:47:52 +0200 (CEST) Received: (qmail 87016 invoked from network); 17 Jul 2003 19:47:49 -0000 Received: from puppy.ietf57.telekom.at (HELO Puppy) (81.160.194.120) by 0 with SMTP; 17 Jul 2003 19:47:49 -0000 Message-ID: <008601c34c9c$4e3fa970$78c2a051@Puppy> From: "Adrian Farrel" To: Date: Thu, 17 Jul 2003 20:47:43 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0083_01C34CA4.ABD36010" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: Liaison with other SDOs X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list Reply-To: Adrian Farrel List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no This is a multi-part message in MIME format. ------=_NextPart_000_0083_01C34CA4.ABD36010 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Thank you for the drafts to date. I have been unable to follow the list consistently, so apologies if this = has been covered. Section 2.1 of draft-ietf-problem-issue-statement-02.txt alludes to = problems communicating with other SDOs. "This can lead to the IETF being misunderstood by other SDOs which can make communications between SDOs less effective, harming the IETF's ability to achieve its mission." There is, however, no coverage of the explicit issue of communications = with other SDOs. You will be aware of the considerable friction between = the ccamp WG and the ITU-T. These frictions are not conducive to the = development of standards in a timely manner. The issue in ccamp has been = recognized and the co-chairs are striving to resolve the issues, but = there is a long way to go. It seems that 'the process' for working with other SDOs is not perfect. Thanks, Adrian=20 ------=_NextPart_000_0083_01C34CA4.ABD36010 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
Thank you for the drafts to = date.
 
I have been unable to follow the list = consistently,=20 so apologies if this has been covered.
 
Section 2.1 of=20 draft-ietf-problem-issue-statement-02.txt alludes to problems = communicating with=20 other SDOs.
 "This can = lead to the IETF=20 being
  misunderstood by other SDOs which can make = communications=20 between
  SDOs less effective, harming the IETF's ability to = achieve=20 its
  mission."
There is, however, no coverage of the = explicit=20 issue of communications with other SDOs. You will be aware of the = considerable=20 friction between the ccamp WG and the ITU-T. These frictions are not = conducive=20 to the development of standards in a timely manner. The issue in ccamp = has been=20 recognized and the co-chairs are striving to resolve the issues, but = there is a=20 long way to go.
 
It seems that 'the process' for working = with other=20 SDOs is not perfect.
 
Thanks,
Adrian


------=_NextPart_000_0083_01C34CA4.ABD36010-- From problem-statement-bounces@alvestrand.no Thu Jul 17 16:14:41 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20931 for ; Thu, 17 Jul 2003 16:14:41 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 76E2161BAD; Thu, 17 Jul 2003 22:14:12 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3017361B9A for ; Thu, 17 Jul 2003 22:14:10 +0200 (CEST) Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h6HKE6MK000401; Thu, 17 Jul 2003 16:14:07 -0400 (EDT) Message-Id: <200307172014.h6HKE6MK000401@rtp-core-1.cisco.com> To: Adrian Farrel In-reply-to: Your message of Thu, 17 Jul 2003 20:47:43 +0100. <008601c34c9c$4e3fa970$78c2a051@Puppy> User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Thu, 17 Jul 2003 16:14:06 -0400 From: Eric Rosen Cc: problem-statement@alvestrand.no Subject: Re: Liaison with other SDOs X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list Reply-To: erosen@cisco.com List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Adrian> There is, however, no coverage of the explicit issue of Adrian> communications with other SDOs. You will be aware of the Adrian> considerable friction between the ccamp WG and the ITU-T. Frankly, I don't think the friction with the ITU-T is really a process issue. The friction occurs because the ITU-T thinks it should be dictating the charter of various WGs (in particular, dictating that the WGs be required to follow various ITU-T architecture and requirements documents). The fact that the ITU-T has no way to make this happen is not a process problem, it's a feature. From problem-statement-bounces@alvestrand.no Thu Jul 17 17:03:35 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22720 for ; Thu, 17 Jul 2003 17:03:33 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7D09561BAC; Thu, 17 Jul 2003 23:03:04 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from znsgs01r.nortelnetworks.com (h33s128a211n47.user.nortelnetworks.com [47.211.128.33]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6F74D61B99 for ; Thu, 17 Jul 2003 23:03:02 +0200 (CEST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.160.46.124]) by znsgs01r.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h6HL2xH02653 for ; Thu, 17 Jul 2003 22:02:59 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 17 Jul 2003 22:02:59 +0100 Message-ID: <4103264BC8D3D51180B7002048400C4501623576@zhard0jd.europe.nortel.com> From: "Elwyn Davies" To: "IETF problem (E-mail)" Date: Thu, 17 Jul 2003 22:02:59 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C34CA6.CD51F66E" Subject: Straw process outline for dealing with structural and practices p roblems X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C34CA6.CD51F66E Content-Type: text/plain; charset="iso-8859-1" A number of people involved in the problem WG have been thinking about an alternative to using a WG to work through the structural and practices problems that we believe we have identified with the IETF, and come up with a proposal for revisions (if any) to the way the IETF operates. This proposal is offered as an alternative to the proposals discussed at tonight's plenary... In outline the plan requires: o Selection of a 'Synthesis and Answer Panel' (SAP) which will moderate the process and own the final proposal for change under the general oversight of the IESG. o Generation of a list of issues that appear to require attention, initially in this document, but subject to additions by agreement of the SAP. o Solicitation of contributions from individuals or groups of IETF stakeholders which will address solutions to any part of the problem space. o Synthesis and moderation of interactions between the various contributions by the SAP in order to create a proposal which appears to result in an organization which will, so far as is possible, no longer suffer from the issues identified, and a minimally disruptive changeover process. o Acceptance of the proposal initially by as large a part of the IETF community as possible through open discussion by email and at plenary session(s), and finally by the existing IESG at the time of completion. The plan will be subject to a tight timetable, enforced by the SAP with the backing of the I* and intended to deliver an accepted proposal at the second IETF meeting after the inception of the SAP. Constitution and Selection of the SAP The SAP will comprise a number of members that is sufficiently low so that the group is able to take decisions rapidly and effectively. The members of the SAP (SAPs) will be selected to represent the interests of as wide a range of the stakeholders in the IETF as is possible. To this end one group of the SAPs will be nominated by the existing management structures of the IETF (IESG, IAB and ISOC) whilst the remainder will be selected through an extension of the standard nomcom process. There will be eleven members of the SAP as follows: o Two members of the current IESG nominated by the IESG. o Two members of the current IAB nominated by the IAB. o One member of the current ISOC Board nominated by the ISOC Board. o Six members selected by the same process as is used by the to select the Nomcom with the variation that the qualification would be attendance at least 5 IETFs with the first attendance must be during 2000 or before. The SAP would elect its chair from amongst its members (as with the IAB). Decisions would be by a voting process determined by the SAP as per nomcom. The SAP would also be able to encourage members of the community to address problem areas that appeared to be underrepresented in the solutions presented. The whole process should run to a tight timetable - 2 IETFs from initiation to submission of completed proposal might be good! Regards, Elwyn Davies on behalf of Jeanette Hofmann and myself who fleshed out this proposal from ideas by various members of the Problem WG editorial team. ------_=_NextPart_001_01C34CA6.CD51F66E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Straw process outline for dealing with structural and practices = problems

A number of people involved in the problem WG have = been thinking about an alternative to using a WG to work through the = structural and practices problems that we believe we have identified = with the IETF, and come up with a proposal for revisions (if any) to = the way the IETF operates.

This proposal is offered as an alternative to the = proposals discussed at tonight's plenary...


In outline the plan requires:

    o  Selection of a 'Synthesis = and Answer Panel' (SAP) which will
       moderate the = process and own the final proposal for change under
       the general = oversight of the IESG.

    o  Generation of a list of = issues that appear to require attention,
       initially in = this document, but subject to additions by agreement
       of the = SAP.

    o  Solicitation of = contributions from individuals or groups of IETF
       stakeholders = which will address solutions to any part of the
       problem = space.

    o  Synthesis and moderation = of interactions between the various
       contributions = by the SAP in order to create a proposal which
       appears to = result in an organization which will, so far as is
       possible, no = longer suffer from the issues identified, and a
       minimally = disruptive changeover process.

    o  Acceptance of the proposal = initially by as large a part of the
       IETF community = as possible through open discussion by email and at
       plenary = session(s), and finally by the existing IESG at the time
       of = completion.

    The plan will be subject to a = tight timetable, enforced by the SAP
    with the backing of the I* and = intended to deliver an accepted
    proposal at the second IETF = meeting after the inception of the SAP.

Constitution and Selection of the SAP

    The SAP will comprise a number of = members that is sufficiently low so
    that the group is able to take = decisions rapidly and effectively. The
    members of the SAP (SAPs) will be = selected to represent the interests
    of as wide a range of the = stakeholders in the IETF as is possible.
    To this end one group of the SAPs = will be nominated by the existing
    management structures of the IETF = (IESG, IAB and ISOC) whilst the
    remainder will be selected = through an extension of the standard
    nomcom process.

    There will be eleven members of = the SAP as follows:

    o  Two members of the current = IESG nominated by the IESG.

    o  Two members of the current = IAB nominated by the IAB.

    o  One member of the current = ISOC Board nominated by the ISOC Board.

    o  Six members selected by = the same process as is used by the
       to select the = Nomcom with the variation that the qualification
       would be = attendance at least 5 IETFs with the first attendance
       must be during = 2000 or before.

    The SAP would elect its chair from = amongst its members (as with the
    IAB).

    Decisions would be by a voting = process determined by the SAP as per
    nomcom.

    The SAP would also be able to = encourage members of the community to
    address problem areas that = appeared to be underrepresented in the
    solutions presented.

    The whole process should run to a = tight timetable - 2 IETFs from
    initiation to submission of = completed proposal might be good!

Regards,
Elwyn Davies

on behalf of Jeanette Hofmann and myself who fleshed = out this proposal
from ideas by various members of the Problem WG = editorial team.

------_=_NextPart_001_01C34CA6.CD51F66E-- From problem-statement-bounces@alvestrand.no Thu Jul 17 19:33:39 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26946 for ; Thu, 17 Jul 2003 19:33:38 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id EB1AD61B9A; Fri, 18 Jul 2003 01:33:08 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from heimdall.skotos.net (unknown [198.232.133.135]) by eikenes.alvestrand.no (Postfix) with ESMTP id 59F8761B9A for ; Fri, 18 Jul 2003 01:33:07 +0200 (CEST) Received: from artemis (unknown [209.81.19.132]) by heimdall.skotos.net (Postfix) with SMTP id 19253150002 for ; Thu, 17 Jul 2003 16:33:06 -0700 (PDT) Message-ID: <0adf01c34cbb$7ca3c9d0$841351d1@artemis> From: "Christopher Allen" To: "IETF problem (E-mail)" References: <4103264BC8D3D51180B7002048400C4501623576@zhard0jd.europe.nortel.com> Date: Thu, 17 Jul 2003 16:31:02 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: Size of SAP [was: Straw process outline for dealing with structural and practices problems] X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Straw process outline for dealing with structural and practices problemsFrom: Elwyn Davies wrote: > There will be eleven members of the SAP as follows: I've been involved in the meeting facilation consulting industry peripherally for over a decade, and there are some studies that say that this is not a very efficient number of people, unless you expect 3 or 4 no-shows regularly. The optimum size for a committee has been show by numerous studies to be more ideally somewhere around 7. There are a variety of reasons hypothesized for this, but I've found it to be true from experience. One hypothesis is that this allows sufficient time for everyone to be able to have their input into the conversation without becoming distracted or bored waiting for others to finish. My personal experience with groups of 9-15 is that someone always feels left out, that their opinion was not properly considered, or that the meeting is rigged against them by either personality, charisma, or process. Just a slightly bit fewer people and somehow this doesn't happen. I've tried to solve this in the past by breaking up groups of 9-15 into smaller task meetings or sub-groups, but that doesn't really work very well either. Oddly, when you grow the group to 25 or so there are iterative group processes that you can use that are different then what is used in a committee that work very well. The 'dead spot' is 10-20 -- small group processes don't work effectively and medium group processed don't work either. (Just FYI, the iterative group processes that work for 25+ people begin to fail at 70 people or so.) My suggestion is that you either consider making the SAP group a tad smaller, say 8 or 9, or increase the size to 25 or so and use an iterative group process and a facilitator when they meet. -- Christopher Allen ---------------------------------------------------------------------- .. Christopher Allen Alacrity Management .. .. 1563 Solano Ave. #353 .. .. o510/649-4030 f510/649-4034 Berkeley, CA 94707 .. From problem-statement-bounces@alvestrand.no Fri Jul 18 04:10:00 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21800 for ; Fri, 18 Jul 2003 04:09:59 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0C57861BAE; Fri, 18 Jul 2003 10:09:30 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from d12lmsgate-4.de.ibm.com (d12lmsgate-4.de.ibm.com [194.196.100.237]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0216461BAC for ; Fri, 18 Jul 2003 10:09:28 +0200 (CEST) Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by d12lmsgate-4.de.ibm.com (8.12.9/8.12.8) with ESMTP id h6I89Jnx029498; Fri, 18 Jul 2003 10:09:19 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h6I89IT5240826; Fri, 18 Jul 2003 10:09:19 +0200 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA31394; Fri, 18 Jul 2003 10:09:16 +0200 Message-ID: <3F17AB32.72762F52@hursley.ibm.com> Date: Fri, 18 Jul 2003 10:09:22 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Christopher Allen References: <4103264BC8D3D51180B7002048400C4501623576@zhard0jd.europe.nortel.com> <0adf01c34cbb$7ca3c9d0$841351d1@artemis> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "IETF problem (E-mail)" Subject: Re: Size of SAP [was: Straw process outline for dealing with structuraland practices problems] X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Certainly don't grow it. I actually believe that a group of 11 can be cohesive and effective, although it's easier with 7 or 9. Most important is that the 7, 9 or 11 individuals are truly committed to participate and to reach agreement. Brian Christopher Allen wrote: > > Straw process outline for dealing with structural and practices problemsFrom: > Elwyn Davies wrote: > > There will be eleven members of the SAP as follows: > > I've been involved in the meeting facilation consulting industry peripherally > for over a decade, and there are some studies that say that this is not a very > efficient number of people, unless you expect 3 or 4 no-shows regularly. > > The optimum size for a committee has been show by numerous studies to be more > ideally somewhere around 7. There are a variety of reasons hypothesized for > this, but I've found it to be true from experience. One hypothesis is that this > allows sufficient time for everyone to be able to have their input into the > conversation without becoming distracted or bored waiting for others to finish. > > My personal experience with groups of 9-15 is that someone always feels left > out, that their opinion was not properly considered, or that the meeting is > rigged against them by either personality, charisma, or process. Just a slightly > bit fewer people and somehow this doesn't happen. > > I've tried to solve this in the past by breaking up groups of 9-15 into smaller > task meetings or sub-groups, but that doesn't really work very well either. > > Oddly, when you grow the group to 25 or so there are iterative group processes > that you can use that are different then what is used in a committee that work > very well. The 'dead spot' is 10-20 -- small group processes don't work > effectively and medium group processed don't work either. (Just FYI, the > iterative group processes that work for 25+ people begin to fail at 70 people or > so.) > > My suggestion is that you either consider making the SAP group a tad smaller, > say 8 or 9, or increase the size to 25 or so and use an iterative group process > and a facilitator when they meet. > > -- Christopher Allen > > ---------------------------------------------------------------------- > .. Christopher Allen Alacrity Management .. > .. 1563 Solano Ave. #353 .. > .. o510/649-4030 f510/649-4034 Berkeley, CA 94707 .. -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland From problem-statement-bounces@alvestrand.no Fri Jul 18 04:15:58 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22243 for ; Fri, 18 Jul 2003 04:15:56 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A629761BAE; Fri, 18 Jul 2003 10:15:22 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [194.196.100.236]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7B9DC61BAC for ; Fri, 18 Jul 2003 10:15:21 +0200 (CEST) Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by d12lmsgate-3.de.ibm.com (8.12.9/8.12.8) with ESMTP id h6I8FKZG048640 for ; Fri, 18 Jul 2003 10:15:20 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h6I8FKT5276020 for ; Fri, 18 Jul 2003 10:15:20 +0200 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA50050 for ; Fri, 18 Jul 2003 10:15:18 +0200 Message-ID: <3F17AC9B.B58D9BA8@hursley.ibm.com> Date: Fri, 18 Jul 2003 10:15:23 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: "IETF problem (E-mail)" References: <4103264BC8D3D51180B7002048400C4501623576@zhard0jd.europe.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Straw process outline for dealing with structural and practices problems X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit I think this is a possible approach, but given the lack of convergence last night on a model, I don't think the subset of us in this WG have any particular authority to decide. I suggest forwarding this sketch of a solution to the IESG, in the hope and expectation that they will rapidly steer in this (or some other) direction. What we must avoid is a period of indecision about starting the process. If we are going the way you suggest, we need the Nomcom working on it by the end of next week. Brian > Elwyn Davies wrote: > > A number of people involved in the problem WG have been thinking about an alternative to using a WG to work through the > structural and practices problems that we believe we have identified with the IETF, and come up with a proposal for revisions > (if any) to the way the IETF operates. > > This proposal is offered as an alternative to the proposals discussed at tonight's plenary... > > In outline the plan requires: > > o Selection of a 'Synthesis and Answer Panel' (SAP) which will > moderate the process and own the final proposal for change under > the general oversight of the IESG. > > o Generation of a list of issues that appear to require attention, > initially in this document, but subject to additions by agreement > of the SAP. > > o Solicitation of contributions from individuals or groups of IETF > stakeholders which will address solutions to any part of the > problem space. > > o Synthesis and moderation of interactions between the various > contributions by the SAP in order to create a proposal which > appears to result in an organization which will, so far as is > possible, no longer suffer from the issues identified, and a > minimally disruptive changeover process. > > o Acceptance of the proposal initially by as large a part of the > IETF community as possible through open discussion by email and at > plenary session(s), and finally by the existing IESG at the time > of completion. > > The plan will be subject to a tight timetable, enforced by the SAP > with the backing of the I* and intended to deliver an accepted > proposal at the second IETF meeting after the inception of the SAP. > > Constitution and Selection of the SAP > > The SAP will comprise a number of members that is sufficiently low so > that the group is able to take decisions rapidly and effectively. The > members of the SAP (SAPs) will be selected to represent the interests > of as wide a range of the stakeholders in the IETF as is possible. > To this end one group of the SAPs will be nominated by the existing > management structures of the IETF (IESG, IAB and ISOC) whilst the > remainder will be selected through an extension of the standard > nomcom process. > > There will be eleven members of the SAP as follows: > > o Two members of the current IESG nominated by the IESG. > > o Two members of the current IAB nominated by the IAB. > > o One member of the current ISOC Board nominated by the ISOC Board. > > o Six members selected by the same process as is used by the > to select the Nomcom with the variation that the qualification > would be attendance at least 5 IETFs with the first attendance > must be during 2000 or before. > > The SAP would elect its chair from amongst its members (as with the > IAB). > > Decisions would be by a voting process determined by the SAP as per > nomcom. > > The SAP would also be able to encourage members of the community to > address problem areas that appeared to be underrepresented in the > solutions presented. > > The whole process should run to a tight timetable - 2 IETFs from > initiation to submission of completed proposal might be good! > > Regards, > Elwyn Davies > > on behalf of Jeanette Hofmann and myself who fleshed out this proposal > from ideas by various members of the Problem WG editorial team. From problem-statement-bounces@alvestrand.no Fri Jul 18 04:51:36 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23561 for ; Fri, 18 Jul 2003 04:51:35 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8C49961BAE; Fri, 18 Jul 2003 10:51:06 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from sentosa.post1.com (sentosa.post1.com [202.27.17.100]) by eikenes.alvestrand.no (Postfix) with SMTP id 497B361BAC for ; Fri, 18 Jul 2003 10:51:03 +0200 (CEST) Received: (qmail 24422 invoked from network); 18 Jul 2003 08:56:08 -0000 Received: from james-fujitsu.ietf57.telekom.at (HELO pobox.org.sg) (81.160.176.129) by sentosa.post1.com with SMTP; 18 Jul 2003 08:56:08 -0000 Message-ID: <3F17B4E4.5040704@pobox.org.sg> Date: Fri, 18 Jul 2003 16:50:44 +0800 From: James Seng User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en, zh-cn, zh-tw, ja, ko MIME-Version: 1.0 To: Elwyn Davies References: <4103264BC8D3D51180B7002048400C4501623576@zhard0jd.europe.nortel.com> In-Reply-To: <4103264BC8D3D51180B7002048400C4501623576@zhard0jd.europe.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "IETF problem (E-mail)" Subject: Re: Straw process outline for dealing with structural and practices p roblems X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Have you look at draft-hardie-alt-consensus-00.txt. I think some of part of the SAP idea is already captured there, altho you bring more formalization on how SAP (review team in ted's draft) comes about. It is worthwhile to your idea and how Ted's draft combine... ps: Not sure where we could have the discussion tho... -James Seng Elwyn Davies wrote: > A number of people involved in the problem WG have been thinking about > an alternative to using a WG to work through the structural and > practices problems that we believe we have identified with the IETF, and > come up with a proposal for revisions (if any) to the way the IETF operates. > > This proposal is offered as an alternative to the proposals discussed at > tonight's plenary... > > > In outline the plan requires: > > o Selection of a 'Synthesis and Answer Panel' (SAP) which will > moderate the process and own the final proposal for change under > the general oversight of the IESG. > > o Generation of a list of issues that appear to require attention, > initially in this document, but subject to additions by agreement > of the SAP. > > o Solicitation of contributions from individuals or groups of IETF > stakeholders which will address solutions to any part of the > problem space. > > o Synthesis and moderation of interactions between the various > contributions by the SAP in order to create a proposal which > appears to result in an organization which will, so far as is > possible, no longer suffer from the issues identified, and a > minimally disruptive changeover process. > > o Acceptance of the proposal initially by as large a part of the > IETF community as possible through open discussion by email and at > plenary session(s), and finally by the existing IESG at the time > of completion. > > The plan will be subject to a tight timetable, enforced by the SAP > with the backing of the I* and intended to deliver an accepted > proposal at the second IETF meeting after the inception of the SAP. > > Constitution and Selection of the SAP > > The SAP will comprise a number of members that is sufficiently low so > that the group is able to take decisions rapidly and effectively. The > members of the SAP (SAPs) will be selected to represent the interests > of as wide a range of the stakeholders in the IETF as is possible. > To this end one group of the SAPs will be nominated by the existing > management structures of the IETF (IESG, IAB and ISOC) whilst the > remainder will be selected through an extension of the standard > nomcom process. > > There will be eleven members of the SAP as follows: > > o Two members of the current IESG nominated by the IESG. > > o Two members of the current IAB nominated by the IAB. > > o One member of the current ISOC Board nominated by the ISOC Board. > > o Six members selected by the same process as is used by the > to select the Nomcom with the variation that the qualification > would be attendance at least 5 IETFs with the first attendance > must be during 2000 or before. > > The SAP would elect its chair from amongst its members (as with the > IAB). > > Decisions would be by a voting process determined by the SAP as per > nomcom. > > The SAP would also be able to encourage members of the community to > address problem areas that appeared to be underrepresented in the > solutions presented. > > The whole process should run to a tight timetable - 2 IETFs from > initiation to submission of completed proposal might be good! > > Regards, > Elwyn Davies > > on behalf of Jeanette Hofmann and myself who fleshed out this proposal > from ideas by various members of the Problem WG editorial team. > From problem-statement-bounces@alvestrand.no Fri Jul 18 05:06:05 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23933 for ; Fri, 18 Jul 2003 05:06:04 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 369BB61BAE; Fri, 18 Jul 2003 11:05:35 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from smtp.ietf57.telekom.at (smtp.ietf57.telekom.at [81.160.16.8]) by eikenes.alvestrand.no (Postfix) with ESMTP id 889D661BAC for ; Fri, 18 Jul 2003 11:05:33 +0200 (CEST) Received: from apocalypse.org (refuge.ietf57.telekom.at [81.160.131.243]) by smtp.ietf57.telekom.at (8.11.7+Sun/8.10.2) with ESMTP id h6I95Wk13615 for ; Fri, 18 Jul 2003 11:05:32 +0200 (MEST) Date: Fri, 18 Jul 2003 11:05:29 +0200 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: avri To: problem-statement@alvestrand.no Content-Transfer-Encoding: 7bit In-Reply-To: <3F17AC9B.B58D9BA8@hursley.ibm.com> Message-Id: X-Mailer: Apple Mail (2.552) Subject: Re: Straw process outline for dealing with structural and practices problems X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit I think it would need a consensus process for this group to pass this on to the IESG, though of course Elwyn could so, or the IESG which I believe is well represented on this list, could just pick it up and combine it with whatever other processes ideas they were looking at. In the meantime I think it a good idea for this group to keep talking about this and any other process suggestions and see if we can come up with something we can reach consensus on. If the IESG reaches a decision point before we are done, so be it, but we should not presuppose that they will and should keep working on in WG fashion. a. On fredag, jul 18, 2003, at 10:15 Europe/Vienna, Brian E Carpenter wrote: > I think this is a possible approach, but given the lack of convergence > last night on a model, I don't think the subset of us in this WG have > any particular authority to decide. I suggest forwarding this sketch of > a solution to the IESG, in the hope and expectation that they will > rapidly steer in this (or some other) direction. > > What we must avoid is a period of indecision about starting the > process. If we are going the way you suggest, we need the Nomcom > working > on it by the end of next week. > > Brian > >> Elwyn Davies wrote: >> >> A number of people involved in the problem WG have been thinking >> about an alternative to using a WG to work through the >> structural and practices problems that we believe we have identified >> with the IETF, and come up with a proposal for revisions >> (if any) to the way the IETF operates. >> >> This proposal is offered as an alternative to the proposals discussed >> at tonight's plenary... >> >> In outline the plan requires: >> >> o Selection of a 'Synthesis and Answer Panel' (SAP) which will >> moderate the process and own the final proposal for change >> under >> the general oversight of the IESG. >> >> o Generation of a list of issues that appear to require >> attention, >> initially in this document, but subject to additions by >> agreement >> of the SAP. >> >> o Solicitation of contributions from individuals or groups of >> IETF >> stakeholders which will address solutions to any part of the >> problem space. >> >> o Synthesis and moderation of interactions between the various >> contributions by the SAP in order to create a proposal which >> appears to result in an organization which will, so far as is >> possible, no longer suffer from the issues identified, and a >> minimally disruptive changeover process. >> >> o Acceptance of the proposal initially by as large a part of the >> IETF community as possible through open discussion by email >> and at >> plenary session(s), and finally by the existing IESG at the >> time >> of completion. >> >> The plan will be subject to a tight timetable, enforced by the SAP >> with the backing of the I* and intended to deliver an accepted >> proposal at the second IETF meeting after the inception of the >> SAP. >> >> Constitution and Selection of the SAP >> >> The SAP will comprise a number of members that is sufficiently >> low so >> that the group is able to take decisions rapidly and effectively. >> The >> members of the SAP (SAPs) will be selected to represent the >> interests >> of as wide a range of the stakeholders in the IETF as is possible. >> To this end one group of the SAPs will be nominated by the >> existing >> management structures of the IETF (IESG, IAB and ISOC) whilst the >> remainder will be selected through an extension of the standard >> nomcom process. >> >> There will be eleven members of the SAP as follows: >> >> o Two members of the current IESG nominated by the IESG. >> >> o Two members of the current IAB nominated by the IAB. >> >> o One member of the current ISOC Board nominated by the ISOC >> Board. >> >> o Six members selected by the same process as is used by the >> to select the Nomcom with the variation that the qualification >> would be attendance at least 5 IETFs with the first attendance >> must be during 2000 or before. >> >> The SAP would elect its chair from amongst its members (as with >> the >> IAB). >> >> Decisions would be by a voting process determined by the SAP as >> per >> nomcom. >> >> The SAP would also be able to encourage members of the community >> to >> address problem areas that appeared to be underrepresented in the >> solutions presented. >> >> The whole process should run to a tight timetable - 2 IETFs from >> initiation to submission of completed proposal might be good! >> >> Regards, >> Elwyn Davies >> >> on behalf of Jeanette Hofmann and myself who fleshed out this proposal >> from ideas by various members of the Problem WG editorial team. > From problem-statement-bounces@alvestrand.no Fri Jul 18 05:11:23 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24058 for ; Fri, 18 Jul 2003 05:11:22 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DEEDD61BAE; Fri, 18 Jul 2003 11:10:52 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from sequoia.muada.com (sequoia.muada.com [213.156.1.123]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7F34461BAC for ; Fri, 18 Jul 2003 11:10:50 +0200 (CEST) Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h6I9BUxS073982 for ; Fri, 18 Jul 2003 11:11:31 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Fri, 18 Jul 2003 11:10:48 +0200 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed From: Iljitsch van Beijnum To: problem-statement@alvestrand.no Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.552) Subject: The IETF's problems X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit As a relative newcomer (2 years active on a mailinglist for a wg, Atlanta was my first IETF meeting and this is my second) this is what I think are the IETF's main problems. To me, it's not very clear whether the IETF wants to be a top-down standards organization or a bottom-up place where people with good ideas can work together to make those ideas even better. When both the IETF leadership and members of the community feel some work is valuable there isn't much of a problem, but when people bring work to the IETF that the wg chair / area director / IAB infrastructure doesn't recognize as important, this often leads to unhappiness. Now obviously this is somewhat unavoidable because of the open structure of the IETF: "anyone with time on their hands and a keyboard can write a draft". But when even large vendors are unable to get protocols that they feel is important (and have implemented or are implementing) "through" IETF, there is a problem. The other major problem for the IETF is that it doesn't manage its resources very well. The major resource the IETF has is the combined intelligence of a large number of very capable individuals, many of which are under no obligation to spend time on a given subject, but do so because they want to contribute to the community. The only thing the IETF has to offer in return is a little (usually very little) recognition. The part that I don't understand is that there is no real structure for technical review in place. The IETF almost exclusively relies on unsollicited comments from the membership at large, and on the efforts of the IESG. Meetings aren't always effectively chaired. People line up at the microphones and address any subject they want, rather than that all issues are dealt with one at a time. Many other aspects of meetings aren't thought out very well either. The overlap in sessions is very bad, whith no apparent rhyme or reason. It also seems strange to me that there should be fixed breaks for meals. Eg: now wg A and wg B overlap, and then we all eat. If wg A and wg B are scheduled after each other, people who only want to attend one can still eat, but people who really want to attend both can do so if they feel this is important enough to skip a meal. (Due to timezone and cultural differences not everyone wants to eat at the same time anyway.) A non-problem: everyone seems to assume that everyone who shows up for a session is an active member of the wg. That isn't the case. Many people just wander in to see what's happening in a group that seems interesting as they're there anyway. Then there is the fact that the IETF has no collective memory, but only a rewind button. There are posts to mailinglists, comments in meetings that may or may not be recorded for future generations and drafts that are guarantueed to disappear in 6 months, and RFCs. This means any and all results either entirely disappear or are relegated to the obscurity of long forgotten mailinglist archives, or they must be published as RFCs. There is no middle ground. About the RFCs: there are simply too many. Maybe at some point issuing a new RFC number for each update of a document made sense, but constantly having to search through the index to find the new number for an update (titles could be better too, searching can be hard at times) doesn't really increase productivity. From problem-statement-bounces@alvestrand.no Fri Jul 18 05:30:02 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24593 for ; Fri, 18 Jul 2003 05:30:01 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A5E2D61BB0; Fri, 18 Jul 2003 11:29:31 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from znsgs01r.nortelnetworks.com (h33s128a211n47.user.nortelnetworks.com [47.211.128.33]) by eikenes.alvestrand.no (Postfix) with ESMTP id A5A4161BB0 for ; Fri, 18 Jul 2003 11:29:29 +0200 (CEST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.160.46.124]) by znsgs01r.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h6I9TST24735 for ; Fri, 18 Jul 2003 10:29:28 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 18 Jul 2003 10:29:29 +0100 Message-ID: <4103264BC8D3D51180B7002048400C4501623579@zhard0jd.europe.nortel.com> From: "Elwyn Davies" To: "'avri'" , problem-statement@alvestrand.no Date: Fri, 18 Jul 2003 10:29:29 +0100 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: RE: Straw process outline for dealing with structural and practic es problems X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no I agree with Brian's view that speed is of the essence. Whilst there was little convergence on the way forwards with the process, a significant fraction of those present recognised that there were problems to solve and so we need some sort of process to go forwards. I'll take a look at draft-hardie-alt-concensus-00 to see if we can merge the proposals, or make some improved suggestions. In the meantime maybe some members of the IESG could give a view on whether this alternative has any resonance for them. [With my problem statement editor hat on] I will review what was said in the plenary last night and publish some ideas for mods to issue-02 over the weekend. Regards, Elwyn > -----Original Message----- > From: avri [mailto:avri@apocalypse.org] > Sent: 18 July 2003 10:05 > To: problem-statement@alvestrand.no > Subject: Re: Straw process outline for dealing with structural and > practices problems > > > I think it would need a consensus process for this group to pass > this on to the IESG, though of course Elwyn could so, or the IESG > which I believe is well represented on this list, could just > pick it up > and combine it with whatever other processes ideas they were > looking at. > > In the meantime I think it a good idea for this group to keep talking > about this and any other process suggestions and see if we can come > up with something we can reach consensus on. If the IESG reaches a > decision point before we are done, so be it, but we should not > presuppose that they will and should keep working on in WG fashion. > > a. > > > On fredag, jul 18, 2003, at 10:15 Europe/Vienna, Brian E Carpenter > wrote: > > > I think this is a possible approach, but given the lack of > convergence > > last night on a model, I don't think the subset of us in > this WG have > > any particular authority to decide. I suggest forwarding > this sketch of > > a solution to the IESG, in the hope and expectation that they will > > rapidly steer in this (or some other) direction. > > > > What we must avoid is a period of indecision about starting the > > process. If we are going the way you suggest, we need the Nomcom > > working > > on it by the end of next week. > > > > Brian > > > >> Elwyn Davies wrote: > >> > >> A number of people involved in the problem WG have been thinking > >> about an alternative to using a WG to work through the > >> structural and practices problems that we believe we have > identified > >> with the IETF, and come up with a proposal for revisions > >> (if any) to the way the IETF operates. > >> > >> This proposal is offered as an alternative to the > proposals discussed > >> at tonight's plenary... > >> > >> In outline the plan requires: > >> > >> o Selection of a 'Synthesis and Answer Panel' (SAP) which will > >> moderate the process and own the final proposal for change > >> under > >> the general oversight of the IESG. > >> > >> o Generation of a list of issues that appear to require > >> attention, > >> initially in this document, but subject to additions by > >> agreement > >> of the SAP. > >> > >> o Solicitation of contributions from individuals or groups of > >> IETF > >> stakeholders which will address solutions to any part of the > >> problem space. > >> > >> o Synthesis and moderation of interactions between the various > >> contributions by the SAP in order to create a proposal which > >> appears to result in an organization which will, so > far as is > >> possible, no longer suffer from the issues identified, and a > >> minimally disruptive changeover process. > >> > >> o Acceptance of the proposal initially by as large a > part of the > >> IETF community as possible through open discussion by email > >> and at > >> plenary session(s), and finally by the existing IESG at the > >> time > >> of completion. > >> > >> The plan will be subject to a tight timetable, > enforced by the SAP > >> with the backing of the I* and intended to deliver an accepted > >> proposal at the second IETF meeting after the inception of the > >> SAP. > >> > >> Constitution and Selection of the SAP > >> > >> The SAP will comprise a number of members that is sufficiently > >> low so > >> that the group is able to take decisions rapidly and > effectively. > >> The > >> members of the SAP (SAPs) will be selected to represent the > >> interests > >> of as wide a range of the stakeholders in the IETF as > is possible. > >> To this end one group of the SAPs will be nominated by the > >> existing > >> management structures of the IETF (IESG, IAB and ISOC) > whilst the > >> remainder will be selected through an extension of the standard > >> nomcom process. > >> > >> There will be eleven members of the SAP as follows: > >> > >> o Two members of the current IESG nominated by the IESG. > >> > >> o Two members of the current IAB nominated by the IAB. > >> > >> o One member of the current ISOC Board nominated by the ISOC > >> Board. > >> > >> o Six members selected by the same process as is used by the > >> to select the Nomcom with the variation that the > qualification > >> would be attendance at least 5 IETFs with the first > attendance > >> must be during 2000 or before. > >> > >> The SAP would elect its chair from amongst its members > (as with > >> the > >> IAB). > >> > >> Decisions would be by a voting process determined by > the SAP as > >> per > >> nomcom. > >> > >> The SAP would also be able to encourage members of the > community > >> to > >> address problem areas that appeared to be > underrepresented in the > >> solutions presented. > >> > >> The whole process should run to a tight timetable - 2 > IETFs from > >> initiation to submission of completed proposal might be good! > >> > >> Regards, > >> Elwyn Davies > >> > >> on behalf of Jeanette Hofmann and myself who fleshed out > this proposal > >> from ideas by various members of the Problem WG editorial team. > > > > From problem-statement-bounces@alvestrand.no Fri Jul 18 09:50:06 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00223 for ; Fri, 18 Jul 2003 09:50:05 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6350561BB1; Fri, 18 Jul 2003 15:49:35 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from smail.alcatel.fr (colt-na165.alcatel.fr [62.23.212.165]) by eikenes.alvestrand.no (Postfix) with ESMTP id 52B8B61B87 for ; Fri, 18 Jul 2003 15:49:34 +0200 (CEST) Received: from frmail31.netfr.alcatel.fr (frmail31.netfr.alcatel.fr [155.132.251.42]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id h6IDnWPT025170; Fri, 18 Jul 2003 15:49:32 +0200 To: Adrian Farrel X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: Alistair.Urie@alcatel.com Date: Fri, 18 Jul 2003 15:49:31 +0200 X-MIMETrack: Serialize by Router on FRMAIL31/FR/ALCATEL(Release 5.0.11 |July 24, 2002) at 07/18/2003 15:49:32 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-new Cc: problem-statement@alvestrand.no Subject: Re: Liaison with other SDOs X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no As mentioned during the session on Tuesday I think we need a new issue about how IETF deals with its "SDO customers". This should cover communication issues (need to talk and listen to customers) but also time schedules and committments (need to make and keep promises with customers), understanding why an SDO thinks it needs a particular protocol extension (need to sometimes say "NO" to a potential customer) and finally understanding risks of customers going "elsewhere" (or "home brewing) protocol extensions. Might try to put some formal text together next week - Alistair URIE "Adrian Farrel" To: Sent by: cc: problem-statement-bounces@al Subject: Liaison with other SDOs vestrand.no 17/07/2003 21:47 Please respond to Adrian Farrel Hi, Thank you for the drafts to date. I have been unable to follow the list consistently, so apologies if this has been covered. Section 2.1 of draft-ietf-problem-issue-statement-02.txt alludes to problems communicating with other SDOs. "This can lead to the IETF being misunderstood by other SDOs which can make communications between SDOs less effective, harming the IETF's ability to achieve its mission." There is, however, no coverage of the explicit issue of communications with other SDOs. You will be aware of the considerable friction between the ccamp WG and the ITU-T. These frictions are not conducive to the development of standards in a timely manner. The issue in ccamp has been recognized and the co-chairs are striving to resolve the issues, but there is a long way to go. It seems that 'the process' for working with other SDOs is not perfect. Thanks, Adrian From problem-statement-bounces@alvestrand.no Fri Jul 18 10:37:14 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02677 for ; Fri, 18 Jul 2003 10:37:13 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1EA6661BB1; Fri, 18 Jul 2003 16:36:44 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by eikenes.alvestrand.no (Postfix) with ESMTP id A86FA61B87 for ; Fri, 18 Jul 2003 16:36:41 +0200 (CEST) Received: from tsg1 (234.sanjose-01-02rs16rt.ca.dial-access.att.net[12.81.0.234]) by mtiwmhc12.worldnet.att.net (mtiwmhc12) with SMTP id <2003071814363811200ltukee>; Fri, 18 Jul 2003 14:36:39 +0000 Message-ID: <007d01c34d39$fbcd8290$020aff0a@tsg1> From: "todd glassey" To: "Adrian Farrel" , References: Date: Fri, 18 Jul 2003 07:36:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Cc: problem-statement@alvestrand.no Subject: Re: Liaison with other SDOs X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit I would also suggest that the legal issue of copyright reliance in sharing efforts or adopting efforts of other SDO's needs to be included here. Todd ----- Original Message ----- From: To: "Adrian Farrel" Cc: Sent: Friday, July 18, 2003 6:49 AM Subject: Re: Liaison with other SDOs > > As mentioned during the session on Tuesday I think we need a new issue > about how IETF deals with its "SDO customers". This should cover > communication issues (need to talk and listen to customers) but also time > schedules and committments (need to make and keep promises with customers), > understanding why an SDO thinks it needs a particular protocol extension > (need to sometimes say "NO" to a potential customer) and finally > understanding risks of customers going "elsewhere" (or "home brewing) > protocol extensions. > > Might try to put some formal text together next week > > - Alistair URIE > > > > "Adrian Farrel" > To: > Sent by: cc: > problem-statement-bounces@al Subject: Liaison with other SDOs > vestrand.no > > > 17/07/2003 21:47 > Please respond to Adrian > Farrel > > > > > > > Hi, > > Thank you for the drafts to date. > > I have been unable to follow the list consistently, so apologies if this > has been covered. > > Section 2.1 of draft-ietf-problem-issue-statement-02.txt alludes to > problems communicating with other SDOs. > "This can lead to the IETF being > misunderstood by other SDOs which can make communications between > SDOs less effective, harming the IETF's ability to achieve its > mission." > There is, however, no coverage of the explicit issue of communications with > other SDOs. You will be aware of the considerable friction between the > ccamp WG and the ITU-T. These frictions are not conducive to the > development of standards in a timely manner. The issue in ccamp has been > recognized and the co-chairs are striving to resolve the issues, but there > is a long way to go. > > It seems that 'the process' for working with other SDOs is not perfect. > > Thanks, > Adrian > > > > > > > From problem-statement-bounces@alvestrand.no Fri Jul 18 11:19:27 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03721 for ; Fri, 18 Jul 2003 11:19:26 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0432D61BB1; Fri, 18 Jul 2003 17:18:57 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by eikenes.alvestrand.no (Postfix) with ESMTP id 81D0561B87 for ; Fri, 18 Jul 2003 17:18:54 +0200 (CEST) Received: from newdev.harvard.edu (localhost [127.0.0.1]) by newdev.harvard.edu (8.12.9/8.12.2) with ESMTP id h6IFIr9n007827 for ; Fri, 18 Jul 2003 11:18:53 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.9/8.12.2/Submit) id h6IFIr8W007826 for problem-statement@alvestrand.no; Fri, 18 Jul 2003 11:18:53 -0400 (EDT) Date: Fri, 18 Jul 2003 11:18:53 -0400 (EDT) From: Scott Bradner Message-Id: <200307181518.h6IFIr8W007826@newdev.harvard.edu> To: problem-statement@alvestrand.no Subject: Re: Straw process outline for dealing with structural and practic X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no I think this proposal combines many of the suggestions from Harald's slide that did not get consensus - I do not think it is a good idea to do anything so formal at this time lets solicit ideas (as IDs) over the next 60 (or 30) days then discuss them for a fixed time (e.g. 30 days) and see where we are at that point I fully expect that a consensus would have been reached on some of the problem solutions - we could then focus on the others I was one who answered Harald's 'do we have to do something in 3 years' question with a 'yes' but I see no reason to try and reform a 17 year old organization in a few months - unseemly haste at best - lets take the time to do it correctly (that does not mean we should do nothing for the next year) Scott From problem-statement-bounces@alvestrand.no Fri Jul 18 11:41:13 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04091 for ; Fri, 18 Jul 2003 11:41:13 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B24E561BB3; Fri, 18 Jul 2003 17:40:43 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by eikenes.alvestrand.no (Postfix) with ESMTP id 96AFA61B87 for ; Fri, 18 Jul 2003 17:40:41 +0200 (CEST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6IFeeJ14867 for ; Fri, 18 Jul 2003 18:40:40 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 18 Jul 2003 18:40:40 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 18 Jul 2003 18:40:39 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 18 Jul 2003 18:40:39 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 18 Jul 2003 18:40:37 +0300 Message-ID: Thread-Topic: Straw process outline for dealing with structural and practic Thread-Index: AcNNP+sGx6q1XlWHQ7OMj7NT0hRhRAAAja8g From: To: , X-OriginalArrivalTime: 18 Jul 2003 15:40:39.0311 (UTC) FILETIME=[F06929F0:01C34D42] Subject: RE: Straw process outline for dealing with structural and practic X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: quoted-printable Scott, > I was one who answered Harald's 'do we have to do something in 3 = years' > question with a 'yes' but I see no reason to try and reform a 17 year = old > organization in a few months - unseemly haste at best - lets take the = time > to do it correctly (that does not mean we should do nothing for the = next > year) I also answered 'do we have to do something in 3 years' question with a = 'yes' because it is less & less 'fun' doing things in the IETF & it feels like = it takes more & more effort to get less results. =20 Please note, though, there are those among us who have been arguing that 'nothing' has gotten done since Yokohama, and perhaps Harald feels that he wants to make it imperative that we address the problems in the IETF, so I am sympathetic to him. I somehow feel like part of the solution will be distributing the responsibility & accountability further around the IETF - I do believe that the IESG individually & as a whole do care deeply about the IETF. I think that we also need to be working smarter, not harder. You may be asking what my point is, and simply put, I don't have a = solution in my back pocket for this, but I would be really happy to hear what = some smart people have to say about how to fix things. I wouldn't even mind if some current (& past) I* members put forth proposals. br, John From problem-statement-bounces@alvestrand.no Fri Jul 18 14:37:36 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07720 for ; Fri, 18 Jul 2003 14:37:36 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4C93361BB1; Fri, 18 Jul 2003 20:37:05 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by eikenes.alvestrand.no (Postfix) with ESMTP id ED3F061B87 for ; Fri, 18 Jul 2003 20:37:02 +0200 (CEST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h6IIZfJ15701; Fri, 18 Jul 2003 14:35:43 -0400 (EDT) Date: Fri, 18 Jul 2003 14:35:40 -0400 From: Keith Moore To: Iljitsch van Beijnum Message-Id: <20030718143540.324c7ab7.moore@cs.utk.edu> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no, moore@cs.utk.edu Subject: Re: The IETF's problems X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit > But when even large vendors are unable to get protocols that > they feel is important (and have implemented or are implementing) > "through" IETF, there is a problem. Let's get this straight right now. IETF DOES NOT exist to do what large vendors what to do. And large vendors are not reliable indicators of what is good for the Internet. From problem-statement-bounces@alvestrand.no Fri Jul 18 16:10:24 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12038 for ; Fri, 18 Jul 2003 16:10:23 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6E03B61B87; Fri, 18 Jul 2003 22:09:53 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from athene.wz-berlin.de (athene.wz-berlin.de [193.174.6.3]) by eikenes.alvestrand.no (Postfix) with ESMTP id DCC4C61AD5 for ; Fri, 18 Jul 2003 22:09:51 +0200 (CEST) Received: from medea.wz-berlin.de ([193.174.6.5]) by athene.wz-berlin.de with esmtp (Exim 4.20) id 19dbY5-0008Al-OU; Fri, 18 Jul 2003 22:09:49 +0200 Received: from ERDE/SpoolDir by medea.wz-berlin.de (Mercury 1.48); 18 Jul 03 22:09:50 +0200 Received: from SpoolDir by ERDE (Mercury 1.48); 18 Jul 03 22:09:26 +0200 From: "Jeanette Hofmann" Organization: Wissenschaftszentrum Berlin To: problem-statement@alvestrand.no, Scott Bradner Date: Fri, 18 Jul 2003 22:09:17 +0200 MIME-Version: 1.0 Message-ID: <3F187010.20537.1F5A95C@localhost> Priority: normal In-reply-to: <200307181518.h6IFIr8W007826@newdev.harvard.edu> X-mailer: Pegasus Mail for Windows (v4.12a) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body X-Virus-Scanned: by amavisd-new-20030616-p3 (Debian) at wz-berlin.de Subject: Re: Straw process outline for dealing with structural and practic X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7BIT On 18 Jul 2003 at 11:18, Scott Bradner wrote: > > I think this proposal combines many of the suggestions from Harald's > slide Really? I am not aware that anybody proposed such a model yesterday as described in Elwyn's mail. that did not get consensus - I do not think it is a good idea > to do anything so formal at this time Our proposal emerged as a response to the problem working group meeting. While there was support for the issue document and the short term improvements of the process document, we seemed to get stuck in a dead end with regard to those problems that affect the IETF's structure. People clearly didn't like the idea to delegate those structural issues to a working group. Or so we thought. That is why we tried to develop a different model, which would be, perhaps, less cumbersome and also integrate more people than a wg. Equipped with clear deadlines, our model would lead to quicker results. Results that reflect only those issues, which attract contributions from the IETF. With this plan, we thought, we avoid frustration about the fact that not much has changed since Yokohama. Now, some people say they want to see some visible changes soon while others caution about moving too fast. Hmmm, is there a non frustrating path out of this? > lets solicit ideas (as IDs) over the next 60 (or 30) days then discuss > them for a fixed time (e.g. 30 days) and see where we are at that point. Actually, Scott, this is not entirely different from what our model proposes. Is it the Synthesis and Answer Panel, that you find too formal? Jeanette > > I fully expect that a consensus would have been reached on some > of the problem solutions - we could then focus on the others > > I was one who answered Harald's 'do we have to do something in 3 years' > question with a 'yes' but I see no reason to try and reform a 17 year old > organization in a few months - unseemly haste at best - lets take the time > to do it correctly (that does not mean we should do nothing for the next > year) > > Scott From problem-statement-bounces@alvestrand.no Fri Jul 18 16:37:53 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13070 for ; Fri, 18 Jul 2003 16:37:52 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 03C9761B87; Fri, 18 Jul 2003 22:37:23 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0342B61AD5 for ; Fri, 18 Jul 2003 22:37:21 +0200 (CEST) Received: from newdev.harvard.edu (localhost [127.0.0.1]) by newdev.harvard.edu (8.12.9/8.12.2) with ESMTP id h6IKbC9n008725; Fri, 18 Jul 2003 16:37:12 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.9/8.12.2/Submit) id h6IKbCRk008724; Fri, 18 Jul 2003 16:37:12 -0400 (EDT) Date: Fri, 18 Jul 2003 16:37:12 -0400 (EDT) From: Scott Bradner Message-Id: <200307182037.h6IKbCRk008724@newdev.harvard.edu> To: jeanette@wz-berlin.de, problem-statement@alvestrand.no, sob@harvard.edu In-Reply-To: <3F187010.20537.1F5A95C@localhost> Subject: Re: Straw process outline for dealing with structural and practic X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no > Is it the Synthesis and Answer Panel, that you find too formal? I find it premature Scott From problem-statement-bounces@alvestrand.no Fri Jul 18 17:35:10 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14242 for ; Fri, 18 Jul 2003 17:35:09 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E5B4961B87; Fri, 18 Jul 2003 23:34:39 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by eikenes.alvestrand.no (Postfix) with ESMTP id 86CA161AD5 for ; Fri, 18 Jul 2003 23:34:37 +0200 (CEST) Received: from bs.jck.com ([209.187.148.211] helo=localhost.jck.com) by bs.jck.com with esmtp (Exim 4.10) id 19dcs3-0003xF-00; Fri, 18 Jul 2003 16:34:32 -0500 Date: Fri, 18 Jul 2003 09:17:54 -0400 From: John C Klensin To: avri , problem-statement@alvestrand.no Message-ID: <5364132.1058519874@localhost> In-Reply-To: References: X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: Straw process outline for dealing with structural and practices problems X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Avri, Elwyn, Brian, and WG participants, I want to repeat and expand on what I said Thursday evening, in the context of this proposal and a few other things. Before I go on, I want to stress that I think the "problem statement" effort has been very useful. And I would like to personally thank the people who have spent large amounts of effort drawing it together. The question in my mind is how, and when, we translate study, design, and proposals into action. Sooner or later, as the saying goes, push has to come to shove. One of the things I took away from Thursday evening was a lack of community enthusiasm for more WG efforts, special design teams, etc. My personal take on that at this point is that: (i) Elwyn's proposal is an interesting mix of design team and directorate ideas. But the thing those ideas have in common is that they are subject to IESG (or WG Chair) management. Elwyn's proposal, as I read it, is for a group that is really independent of either. That makes it just the right thing if we are really in a meltdown state. But if the percentages Thursday night are representative of the community, then we really aren't: the support for the "we are in serious and urgent need of fundamental structural change" (my paraphrase) questions was definitely underwhelming. (ii) Support for "more WGs", "more design teams", and "appoint someone to decide" was also fairly low. I don't think that makes a strong case for variations on those themes, although I could be wrong. (iii) While the question wasn't asked explicitly, I am convinced from what was, and was not, said on Thursday that, had Harald asked whether the community wanted the entire IESG to resign, effective as soon as replacements be found, that proposition would also have received little support. Add to that the lukewarm (at best) support for the proposition that we need major structural change to survive in the fairly short term, and I don't think we are in the middle of a meltdown. We can cast this situation in terms of "trust", or other language, but the bottom line seems, to me, to be that we are still willing --perhaps anxious-- for the IESG to manage the IETF process and to exercise some leadership about it. So, assuming we consider all of this important, sooner or later a proposal has to be turned over to the IESG, and the IESG needs to take action on it (or not). And these efforts are either are important or they aren't. If they are not important enough to accept some delays in the IETF's technical output, then no proposal, including Elwyn's, is going to work (or be worth the cost... if it involves a fairly large number of people (and even a dozen is fairly large) who could otherwise be doing technical work, reviewing documents, etc., then the decision to do it is a decision to slow our technical output down. If it involves predominantly people who would rather be working on procedures than doing technical work, or even are more qualified to work on procedures than on engineering, it is a recipe for disaster. No free lunches here. And that brings me back to my Thursday evening comment. I think it is time to _do_ something, not design structures for talking about what to do. I think we should go through the issues in the problem statement document, one at a time, and quickly generate and document some possible approaches for each. I don't care if we reach a clear consensus about any given approach, indeed, I think that trying to do that might be harmful. We should then pass the package -- issue and possible approaches together-- off to the IESG with * A statement that the community, or at least some significant fraction of this WG, considers the issue important. * A request that they pick whichever one of the approaches, or one of their own, makes sense given their perspective on this issues. * The clear expectation that they will consider the above and expeditiously make that decision and implement it, even if it delays other work, _or_ that they explain why it really isn't an issue or that they couldn't find an acceptable solution. * We make it clear that IESG members who are uninterested or unwilling to engage on those issues are expected to resign, that the Nomcom is expected to replace, as a priority, any who don't resign, and that any who are problematic who are not up for review this year (or who are especially problematic) will be recalled. The bottom line is that we are either serious about this or we aren't. And "serious", at this stage, implies that we are willing to have other things delayed in order to move forward and that we are willing to fire IESG members who don't want to play. The good news, from my standpoint, is that I know the majority of the IESG fairly well, and they really want to do the right thing, including working to the community's priorities if those are clear and realistic (e.g., "add these additional things to your workload while speeding up the rate at which you do other things" is not plausible). I strongly suspect all of them do. All a more complicated process will accomplish, IMO, is delay and wasted cycles. Regardless of how a proposal originates and how specific it is, the IESG is still obligated to figure out what makes sense and what doesn't and what can be practically implemented and what isn't, regardless of the level of consensus from some group that is, inevitably, not representative of the community. So why spend more time developing procedures to develop procedures, taking people away from technical work or driving everyone who isn't focused on process details as-an-end away, producing a less and less representative "consensus". john p.s. To save generating another note, there will come a time at which the procedures and models we have discussed about WG management should be applied to this WG. Have we reached the point of diminishing returns and how do we figure that out? For obvious reasons, if more energy isn't going to produce enough more in the way of results to justify the investment, it would be better if the WG "voted" itself out of existence than to force Harald to unilateral action. But, while I can't speak for others, I expect him to do his job as AD. And that implies that, if he concludes that the WG has produced about all it is likely to produce relative to the cost of having it, he should shut it down. regards, john --On Friday, 18 July, 2003 11:05 +0200 avri wrote: > I think it would need a consensus process for this group to > pass this on to the IESG, though of course Elwyn could so, > or the IESG which I believe is well represented on this > list, could just pick it up and combine it with whatever > other processes ideas they were looking at. > > In the meantime I think it a good idea for this group to > keep talking about this and any other process suggestions > and see if we can come up with something we can reach > consensus on. If the IESG reaches a decision point before > ... From problem-statement-bounces@alvestrand.no Fri Jul 18 17:55:46 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14553 for ; Fri, 18 Jul 2003 17:55:46 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1BA9F61B87; Fri, 18 Jul 2003 23:55:17 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by eikenes.alvestrand.no (Postfix) with ESMTP id 836C261AD5 for ; Fri, 18 Jul 2003 23:55:14 +0200 (CEST) Received: from ala-mrwtemp.windriver.com ([147.11.233.34]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id OAA24461; Fri, 18 Jul 2003 14:54:23 -0700 (PDT) Message-Id: <5.1.0.14.2.20030718174117.033334f0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 18 Jul 2003 17:47:40 -0400 To: "Jeanette Hofmann" From: Margaret Wasserman In-Reply-To: <3F187010.20537.1F5A95C@localhost> References: <200307181518.h6IFIr8W007826@newdev.harvard.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: problem-statement@alvestrand.no, Scott Bradner Subject: Re: Straw process outline for dealing with structural and practic X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no At 10:09 PM 7/18/2003 +0200, Jeanette Hofmann wrote: >Really? I am not aware that anybody proposed such a model yesterday as >described in Elwyn's mail. My slides included: Blue ribbon panel/design team? - Chosen in some representative fashion - Solicits proposals and input from the community - Develops a recommendation to reform our management model - Recommendation is reviewed and ratified by the community Although this is nowhere near as detailed, it is similar. >Our proposal emerged as a response to the problem working group meeting. >While there was support for the issue document and the short term >improvements of the process document, we seemed to get stuck in a dead >end with regard to those problems that affect the IETF's structure. People >clearly didn't like the idea to delegate those structural issues to a working >group. Or so we thought. That is why we tried to develop a different model, >which would be, perhaps, less cumbersome and also integrate more people >than a wg. This makes sense as a follow-on from the Problem WG. However, at the plenary, people offered much stronger support for the idea that the IESG should propose a solution to these problems than they did for any of the other options... >Now, some people say they want to see some visible changes soon while >others caution about moving too fast. Hmmm, is there a non frustrating path >out of this? We have consensus to start the near-term efforts, and there is also non-formal work underway (as Harald discussed in the plenary) to fix some immediate issues. So, maybe that will satisfy folks who want action now? > > lets solicit ideas (as IDs) over the next 60 (or 30) days then discuss > > them for a fixed time (e.g. 30 days) and see where we are at that point. > >Actually, Scott, this is not entirely different from what our model >proposes. Is >it the Synthesis and Answer Panel, that you find too formal? I believe that Scott doesn't want to determine how we will make a decision until we know what change options are on the table. Margaret From problem-statement-bounces@alvestrand.no Fri Jul 18 18:35:05 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16741 for ; Fri, 18 Jul 2003 18:35:04 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BFE5C61B89; Sat, 19 Jul 2003 00:34:35 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by eikenes.alvestrand.no (Postfix) with ESMTP id 236CA61B87 for ; Sat, 19 Jul 2003 00:34:33 +0200 (CEST) Received: from tsg1 (85.sanjose-15rs16rt.ca.dial-access.att.net[12.81.7.85]) by mtiwmhc12.worldnet.att.net (mtiwmhc12) with SMTP id <2003071822343011200pojo0e>; Fri, 18 Jul 2003 22:34:31 +0000 Message-ID: <019101c34d7c$bf6dbf70$020aff0a@tsg1> From: "todd glassey" To: "Keith Moore" , "Iljitsch van Beijnum" References: <20030718143540.324c7ab7.moore@cs.utk.edu> Date: Fri, 18 Jul 2003 15:34:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Cc: problem-statement@alvestrand.no, Keith Moore Subject: Re: The IETF's problems X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Keith ----- Original Message ----- From: "Keith Moore" To: "Iljitsch van Beijnum" Cc: ; Sent: Friday, July 18, 2003 11:35 AM Subject: Re: The IETF's problems > > But when even large vendors are unable to get protocols that > > they feel is important (and have implemented or are implementing) > > "through" IETF, there is a problem. > > Let's get this straight right now. Oooohhhh - heavy commentary ! > > IETF DOES NOT exist to do what large vendors what to do. yes Keith they are - and in fact the IETF is totally setup to pass the efforts of a few specific vendors and several educational entities into standards status. It may not be what's on paper but its what happens in the real world, and any forensic accountancy that runs an analysis will probably see that the IETF is pretty regularly used by its larger players to inhibit other companies from entering the arena. > > And large vendors are not reliable indicators of what is good for the > Internet. Again - yes they are... they are the Internet. Todd Glassey From problem-statement-bounces@alvestrand.no Sat Jul 19 03:14:01 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07557 for ; Sat, 19 Jul 2003 03:14:01 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 66BF861B87; Sat, 19 Jul 2003 09:13:32 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by eikenes.alvestrand.no (Postfix) with ESMTP id C35B161AD5 for ; Sat, 19 Jul 2003 09:13:29 +0200 (CEST) Received: from [209.187.148.215] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.10) id 19dluA-0006wr-00; Sat, 19 Jul 2003 02:13:18 -0500 Date: Sat, 19 Jul 2003 03:13:18 -0400 From: John C Klensin To: Margaret Wasserman Message-ID: <35192534.1058584398@p3.JCK.COM> In-Reply-To: <5.1.0.14.2.20030718174117.033334f0@mail.windriver.com> References: <200307181518.h6IFIr8W007826@newdev.harvard.edu> <5.1.0.14.2.20030718174117.033334f0@mail.windriver.com> X-Mailer: Mulberry/3.1.0b4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: "problem-statement@alvestrand.no" , Scott Bradner , Jeanette Hofmann Subject: Re: Straw process outline for dealing with structural and practic X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit --On Friday, 18 July, 2003 17:47 -0400 Margaret Wasserman wrote: > At 10:09 PM 7/18/2003 +0200, Jeanette Hofmann wrote: >> Really? I am not aware that anybody proposed such a model >> yesterday as described in Elwyn's mail. > > My slides included: > > Blue ribbon panel/design team? > - Chosen in some representative fashion > - Solicits proposals and input from the community > - Develops a recommendation to reform our management model > - Recommendation is reviewed and ratified by the community > > Although this is nowhere near as detailed, it is similar. It is also a WG, or maybe a design team plus restricted-membership WG, by another name and with a slightly different organizational model. See my earlier note. >> Our proposal emerged as a response to the problem working >> group meeting. While there was support for the issue document >> and the short term improvements of the process document, we >> seemed to get stuck in a dead end with regard to those >> problems that affect the IETF's structure. People clearly >> didn't like the idea to delegate those structural issues to a >> working group. Or so we thought. That is why we tried to >> develop a different model, which would be, perhaps, less >> cumbersome and also integrate more people than a wg. > > This makes sense as a follow-on from the Problem WG. However, > at the plenary, people offered much stronger support for the > idea that the IESG should propose a solution to these problems > than they did for any of the other options... I think it is interesting, and _very_ important, to try to understand why the impression of the sentiment of the Problem WG and the response from the Plenary were so different. I hope it is possible to do that analysis without getting (again) trapped in the philosophical question of how much authority the plenary has. My hypothesis... (1) Regardless of the _authority_ of the plenary, significantly more IETF participants were sitting there, raising hands, and generally expressing opinions than have been participating actively and observably in the Problem WG. Unless there is evidence that the plenary was somehow "packed" --and I saw none-- we (and, more importantly, the AD and the IESG) are obligated to pay very careful attention to the size of that group and its opinions as probably more reflective of a broader IETF community than the WG reflects. (2) A disconnect between a group of active, apparently-informed, IETF participants of that size and a WG about either problem analysis or solution approaches suggests that the WG is out of touch with the community. (3) Given especially the behavior of this WG and its mailing list, the most likely explanation of "out of touch" is that most of the IETF has found the WG, its mailing list traffic flow, and some of its tone, either unpleasant or overwhelming or unimportant enough that they have moved on to other things. This has created a statistical bias between the composition and opinions of the self-selected WG and that of the community. In other words, the WG has become an island, having discussions and reaching conclusions that are out of touch with the IETF universe. Now, what to do about this: (i) It seems to me that the WG membership may need to do less "talking" (and especially repeating of issues and positions) and more outreach and listening to the broader community. (ii) In part because that sort of outreach and listening is hard and we have no real structure for doing so, we should all be aware of the limitations of this WG, and any like it, for determining IETF consensus about policy, changes, and methods. We may, nonetheless, be an effective body for identifying "problems" and "issues" ... just not an effective body for estimating the importance of those issues to the community. (iii) We should note, and add explicitly to the Problem list, something like: Sometimes, because of its composition, a well-intentioned WG will reach conclusions different from those of a reasonably-well-informed IETF Community. This is especially likely when the subject matter of the WG, or its style of working (discussed elsewhere) drives a significant fraction of "the rest of" the IETF away or otherwise prevents their active and effective participation. Because their primary responsibilities lie with the WG itself, it is often impossible for WG leadership to either detect that this is occurring or to control it: the quest, especially on the WG level, for a mythical "silent majority" is more likely to lead to madness or demagoguery than to better understanding and alignment with the community. It is therefore an important IESG responsibility, relying on Last Calls and other input --sometimes including plenary input-- to understand when such disconnects have occurred and to correct them. But this type of IESG action almost inevitably leads to cries of outrage from the WG (because it had consensus internally) and frustration about "late surprises". None of this should be considered a real process problem, and we should be more concerned if the IESG fails to do its job by searching for, identifying, and correcting for such disconnects. But, especially to the extent that it is inevitable in some cases, the community must learn to understand the problem and to be supportive of IESG action to detect and control it (and should insist that the IESG do so). regardsm john From problem-statement-bounces@alvestrand.no Sat Jul 19 08:26:55 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12706 for ; Sat, 19 Jul 2003 08:26:54 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BA54761B87; Sat, 19 Jul 2003 14:26:25 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from sequoia.muada.com (sequoia.muada.com [213.156.1.123]) by eikenes.alvestrand.no (Postfix) with ESMTP id A9B3061AD5 for ; Sat, 19 Jul 2003 14:26:24 +0200 (CEST) Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h6JCR1xS094047; Sat, 19 Jul 2003 14:27:02 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Sat, 19 Jul 2003 13:23:56 +0200 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) To: Keith Moore From: Iljitsch van Beijnum In-Reply-To: <20030718143540.324c7ab7.moore@cs.utk.edu> Message-Id: <7C1FF869-B9DB-11D7-8554-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Cc: problem-statement@alvestrand.no Subject: Re: The IETF's problems X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit On vrijdag, jul 18, 2003, at 20:35 Europe/Amsterdam, Keith Moore wrote: >> But when even large vendors are unable to get protocols that >> they feel is important (and have implemented or are implementing) >> "through" IETF, there is a problem. > Let's get this straight right now. Yes, let's. Because whichever party is suffering from the misconception here, the result is the same: some people are unhappy with what the IETF does because their expectations don't match reality. > IETF DOES NOT exist to do what large vendors what to do. I was talking about working on protocols, which isn't the same as "do what large vendors want to do". If people in general and large vendors in particular come to the IETF wanting to work on something within the IETF, and this work falls within the areas of interest of the IETF, then it would be a very good idea that the IETF indeed work on this. Obviously in some cases the work will be abandoned if the IETF doesn't adopt it, which must be the result "the IETF" is after in these cases. More often, the work will continue but the resulting protocol will be of a lower quality, and if the protocol is even a little successful, the IETF has to do something with it later anyway. Also, if the protocol is subjected to the IETF editor it goes through the IESG anyway, so not working on something often doesn't even save the IESG any work. Whether it saves working groups work is immaterial as just about everything that happens in a working group is done on a voluntary basis. Last but not least, frustrating people that come to the IETF damages the reputation of the IETF and will drive people away in frustration. This is already happening. (Again, this includes large vendors and not just "hobbyist protocol designers".) > And large vendors are not reliable indicators of what is good for the > Internet. Like _anyone_ can predict what is going to be good for the internet anyway. Large vendors are reasonable indicators of what is wanted in the internet and what's going to happen in the internet, though. They're implementing the stuff most boxes connected to the net will be running a couple of years from now. From problem-statement-bounces@alvestrand.no Sat Jul 19 09:39:54 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13704 for ; Sat, 19 Jul 2003 09:39:53 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2757961B8A; Sat, 19 Jul 2003 15:39:25 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from gull.mail.pas.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2558061B87 for ; Sat, 19 Jul 2003 15:39:24 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by gull.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19drvj-0002pX-00; Sat, 19 Jul 2003 06:39:19 -0700 Date: Sat, 19 Jul 2003 09:38:51 -0400 From: Keith Moore To: Iljitsch van Beijnum Message-Id: <20030719093851.37135aa8.moore@cs.utk.edu> In-Reply-To: <7C1FF869-B9DB-11D7-8554-00039388672E@muada.com> References: <20030718143540.324c7ab7.moore@cs.utk.edu> <7C1FF869-B9DB-11D7-8554-00039388672E@muada.com> X-Mailer: Sylpheed version 0.9.1 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no, moore@cs.utk.edu Subject: Re: The IETF's problems X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit ] >> But when even large vendors are unable to get protocols that ] >> they feel is important (and have implemented or are implementing) ] >> "through" IETF, there is a problem. ] ] > Let's get this straight right now. ] ] Yes, let's. Because whichever party is suffering from the misconception ] here, the result is the same: some people are unhappy with what the ] IETF does because their expectations don't match reality. some people are unhappy with the IETF because their expection does not match their perception of IETF's behavior. or even more succinctly "some people are unhappy with the IETF" well, big deal. ] If people in general and large vendors ] in particular come to the IETF wanting to work on something within the ] IETF, and this work falls within the areas of interest of the IETF, ] then it would be a very good idea that the IETF indeed work on this. I strongly disagree with this as a categorial statement. Many kinds of work that people want IETF to do are not "very good ideas". IETF has been pressured by powerful concerns to standardize NATs, means of eavesdropping, bits in IP headers to identify porn, protocols that encourage monopolies or give one vendor a competitive advantage, protocols that harm the Internet architecture and the ability of existing and future applications to use the Internet, and even protocols that don't interoperate (but which allow vendors to claim standards compliance). None of these are good ideas, and IETF should neither invest its resources in, nor lend its imprimatur to, bad ideas. Yes, some people will get frustrated with this. So be it. IETF cannot do its job properly without disappointing people. Unless IETF says "no" to bad ideas, there is no reason for IETF to exist. IETF is useless unless it's endorsement is a reasonably reliable indication of quality. Currently, IETF does not say "no" often enough - and that also has harmed its reputation. ] > And large vendors are not reliable indicators of what is good for the ] > Internet. ] ] Like _anyone_ can predict what is going to be good for the internet ] anyway. Large vendors are reasonable indicators of what is wanted in ] the internet and what's going to happen in the internet, though. I disagree with that also. Large vendors do not represent their customers' interests, and they never have. Quite often the interests of large vendors are diametrically opposite of their customers'. Large vendors want to maximize profit, customers want to maximize value. Large vendors want to lock in their customers, customers want flexibility. etc. Which is part of why IETF rules stipulate that participants must act in the best interests of the Internet as a whole. ] They're implementing the stuff most boxes connected to the net will be ] running a couple of years from now. The stuff may be in those boxes, and people may even try to use it. But that doesn't mean it's deserving of standardization or endorsement. There's a lot of garbage in deployed products. From problem-statement-bounces@alvestrand.no Sat Jul 19 10:25:26 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15438 for ; Sat, 19 Jul 2003 10:25:25 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 267EF61B8B; Sat, 19 Jul 2003 16:24:57 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4F75361B87 for ; Sat, 19 Jul 2003 16:24:55 +0200 (CEST) Received: from tsg1 (8.sanjose-11-12rs16rt.ca.dial-access.att.net[12.81.4.8]) by mtiwmhc12.worldnet.att.net (mtiwmhc12) with SMTP id <2003071914245111200o27uqe>; Sat, 19 Jul 2003 14:24:53 +0000 Message-ID: <034b01c34e01$80ac5fa0$020aff0a@tsg1> From: "todd glassey" To: "Keith Moore" , "Iljitsch van Beijnum" References: <20030718143540.324c7ab7.moore@cs.utk.edu><7C1FF869-B9DB-11D7-8554-00039388672E@muada.com> <20030719093851.37135aa8.moore@cs.utk.edu> Date: Sat, 19 Jul 2003 07:19:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Cc: problem-statement@alvestrand.no, moore@cs.utk.edu Subject: Re: The IETF's problems X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Keith - who are you or the IETF to make any commentary or anything else as to what technologies are made available for use on the Internet. You nor your management are empowered to govern the Internet and as such your actions here constitute an restraint of trade if their are implemented as policy. Todd ----- Original Message ----- From: "Keith Moore" To: "Iljitsch van Beijnum" Cc: ; Sent: Saturday, July 19, 2003 6:38 AM Subject: Re: The IETF's problems > ] >> But when even large vendors are unable to get protocols that > ] >> they feel is important (and have implemented or are implementing) > ] >> "through" IETF, there is a problem. > ] > ] > Let's get this straight right now. > ] > ] Yes, let's. Because whichever party is suffering from the misconception > ] here, the result is the same: some people are unhappy with what the > ] IETF does because their expectations don't match reality. > > some people are unhappy with the IETF because their expection does not > match their perception of IETF's behavior. > > or even more succinctly "some people are unhappy with the IETF" > > well, big deal. > > ] If people in general and large vendors > ] in particular come to the IETF wanting to work on something within the > ] IETF, and this work falls within the areas of interest of the IETF, > ] then it would be a very good idea that the IETF indeed work on this. > > I strongly disagree with this as a categorial statement. Many kinds of work > that people want IETF to do are not "very good ideas". IETF has been > pressured by powerful concerns to standardize NATs, means of eavesdropping, > bits in IP headers to identify porn, protocols that encourage monopolies or > give one vendor a competitive advantage, protocols that harm the Internet > architecture and the ability of existing and future applications to use the > Internet, and even protocols that don't interoperate (but which allow vendors > to claim standards compliance). None of these are good ideas, and IETF should > neither invest its resources in, nor lend its imprimatur to, bad ideas. > > Yes, some people will get frustrated with this. So be it. IETF cannot do its > job properly without disappointing people. Unless IETF says "no" to bad > ideas, there is no reason for IETF to exist. IETF is useless unless it's > endorsement is a reasonably reliable indication of quality. Currently, IETF > does not say "no" often enough - and that also has harmed its reputation. > > ] > And large vendors are not reliable indicators of what is good for the > ] > Internet. > ] > ] Like _anyone_ can predict what is going to be good for the internet > ] anyway. Large vendors are reasonable indicators of what is wanted in > ] the internet and what's going to happen in the internet, though. > > I disagree with that also. Large vendors do not represent their customers' > interests, and they never have. Quite often the interests of large vendors > are diametrically opposite of their customers'. Large vendors want to > maximize profit, customers want to maximize value. Large vendors want to lock > in their customers, customers want flexibility. etc. Which is part of why > IETF rules stipulate that participants must act in the best interests of the > Internet as a whole. > > ] They're implementing the stuff most boxes connected to the net will be > ] running a couple of years from now. > > The stuff may be in those boxes, and people may even try to use it. But that > doesn't mean it's deserving of standardization or endorsement. There's a lot > of garbage in deployed products. > > From problem-statement-bounces@alvestrand.no Sat Jul 19 12:00:41 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17282 for ; Sat, 19 Jul 2003 12:00:40 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3A7FB61B8A; Sat, 19 Jul 2003 17:59:41 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from sentosa.post1.com (sentosa.post1.com [202.27.17.100]) by eikenes.alvestrand.no (Postfix) with SMTP id 172B061B87 for ; Sat, 19 Jul 2003 17:59:39 +0200 (CEST) Received: (qmail 45395 invoked from network); 19 Jul 2003 16:04:37 -0000 Received: from unknown (HELO pobox.org.sg) (193.80.99.103) by sentosa.post1.com with SMTP; 19 Jul 2003 16:04:37 -0000 Message-ID: <3F196AD8.1070107@pobox.org.sg> Date: Sat, 19 Jul 2003 23:59:20 +0800 From: James Seng User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en, zh-cn, zh-tw, ja, ko MIME-Version: 1.0 To: todd glassey References: <20030718143540.324c7ab7.moore@cs.utk.edu><7C1FF869-B9DB-11D7-8554-00039388672E@muada.com> <20030719093851.37135aa8.moore@cs.utk.edu> <034b01c34e01$80ac5fa0$020aff0a@tsg1> In-Reply-To: <034b01c34e01$80ac5fa0$020aff0a@tsg1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no, Keith Moore Subject: Re: The IETF's problems X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit we dont decide what technologies are made available for use on the Internet. but we can choose the work we want to do, and RFC we want to publish. ps: My view is that so long there is sufficient interest (or rough consensus) in any work, whether it comes from a large vendor or not is irrelevant. In fact, if a good idea comes a large vendor and people are interested to work on it, all the more we should. james todd glassey wrote: > Keith - who are you or the IETF to make any commentary or anything else as > to what technologies are made available for use on the Internet. You nor > your management are empowered to govern the Internet and as such your > actions here constitute an restraint of trade if their are implemented as > policy. > > Todd > > ----- Original Message ----- > From: "Keith Moore" > To: "Iljitsch van Beijnum" > Cc: ; > Sent: Saturday, July 19, 2003 6:38 AM > Subject: Re: The IETF's problems > > > >>] >> But when even large vendors are unable to get protocols that >>] >> they feel is important (and have implemented or are implementing) >>] >> "through" IETF, there is a problem. >>] >>] > Let's get this straight right now. >>] >>] Yes, let's. Because whichever party is suffering from the misconception >>] here, the result is the same: some people are unhappy with what the >>] IETF does because their expectations don't match reality. >> >>some people are unhappy with the IETF because their expection does not >>match their perception of IETF's behavior. >> >>or even more succinctly "some people are unhappy with the IETF" >> >>well, big deal. >> >>] If people in general and large vendors >>] in particular come to the IETF wanting to work on something within the >>] IETF, and this work falls within the areas of interest of the IETF, >>] then it would be a very good idea that the IETF indeed work on this. >> >>I strongly disagree with this as a categorial statement. Many kinds of > > work > >>that people want IETF to do are not "very good ideas". IETF has been >>pressured by powerful concerns to standardize NATs, means of > > eavesdropping, > >>bits in IP headers to identify porn, protocols that encourage monopolies > > or > >>give one vendor a competitive advantage, protocols that harm the Internet >>architecture and the ability of existing and future applications to use > > the > >>Internet, and even protocols that don't interoperate (but which allow > > vendors > >>to claim standards compliance). None of these are good ideas, and IETF > > should > >>neither invest its resources in, nor lend its imprimatur to, bad ideas. >> >>Yes, some people will get frustrated with this. So be it. IETF cannot do > > its > >>job properly without disappointing people. Unless IETF says "no" to bad >>ideas, there is no reason for IETF to exist. IETF is useless unless it's >>endorsement is a reasonably reliable indication of quality. Currently, > > IETF > >>does not say "no" often enough - and that also has harmed its reputation. >> >>] > And large vendors are not reliable indicators of what is good for the >>] > Internet. >>] >>] Like _anyone_ can predict what is going to be good for the internet >>] anyway. Large vendors are reasonable indicators of what is wanted in >>] the internet and what's going to happen in the internet, though. >> >>I disagree with that also. Large vendors do not represent their > > customers' > >>interests, and they never have. Quite often the interests of large > > vendors > >>are diametrically opposite of their customers'. Large vendors want to >>maximize profit, customers want to maximize value. Large vendors want to > > lock > >>in their customers, customers want flexibility. etc. Which is part of > > why > >>IETF rules stipulate that participants must act in the best interests of > > the > >>Internet as a whole. >> >>] They're implementing the stuff most boxes connected to the net will be >>] running a couple of years from now. >> >>The stuff may be in those boxes, and people may even try to use it. But > > that > >>doesn't mean it's deserving of standardization or endorsement. There's a > > lot > >>of garbage in deployed products. >> >> > > > > From problem-statement-bounces@alvestrand.no Sat Jul 19 13:25:59 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18338 for ; Sat, 19 Jul 2003 13:25:58 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 033A361B8A; Sat, 19 Jul 2003 19:25:31 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from gull.mail.pas.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by eikenes.alvestrand.no (Postfix) with ESMTP id F06F761B87 for ; Sat, 19 Jul 2003 19:25:29 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by gull.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19dvSW-0006fh-00; Sat, 19 Jul 2003 10:25:24 -0700 Date: Sat, 19 Jul 2003 13:24:55 -0400 From: Keith Moore To: James Seng Message-Id: <20030719132455.11e94fe3.moore@cs.utk.edu> In-Reply-To: <3F196AD8.1070107@pobox.org.sg> References: <20030718143540.324c7ab7.moore@cs.utk.edu> <7C1FF869-B9DB-11D7-8554-00039388672E@muada.com> <20030719093851.37135aa8.moore@cs.utk.edu> <034b01c34e01$80ac5fa0$020aff0a@tsg1> <3F196AD8.1070107@pobox.org.sg> X-Mailer: Sylpheed version 0.9.1 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no, moore@cs.utk.edu Subject: Re: The IETF's problems X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit ] My view is that so long there is sufficient interest (or rough ] consensus) in any work, whether it comes from a large vendor or not is ] irrelevant. In fact, if a good idea comes a large vendor and people are ] interested to work on it, all the more we should. I don't care whether the idea comes from a large vendor or not, as long as it's a good idea. And I agree that the investment of energy by a large vendor can go a long way to help make a good idea successful. However I don't believe that "sufficient interest" is a reliable indicator of which ideas merit IETF investment of energy. I'm not even sure I'd accept "rough consensus" as such an indicator. From problem-statement-bounces@alvestrand.no Sat Jul 19 15:21:42 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21367 for ; Sat, 19 Jul 2003 15:21:41 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5CBAA61B8A; Sat, 19 Jul 2003 21:21:12 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from sequoia.muada.com (sequoia.muada.com [213.156.1.123]) by eikenes.alvestrand.no (Postfix) with ESMTP id 25BAF61B87 for ; Sat, 19 Jul 2003 21:21:11 +0200 (CEST) Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h6JJLoxS098349; Sat, 19 Jul 2003 21:21:51 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Sat, 19 Jul 2003 21:21:13 +0200 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) To: Keith Moore From: Iljitsch van Beijnum In-Reply-To: <20030719093851.37135aa8.moore@cs.utk.edu> Message-Id: <291D7CA5-BA1E-11D7-8554-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Cc: problem-statement@alvestrand.no Subject: Re: The IETF's problems X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit On zaterdag, jul 19, 2003, at 15:38 Europe/Amsterdam, Keith Moore wrote: > some people are unhappy with the IETF because their expection does not > match their perception of IETF's behavior. > or even more succinctly "some people are unhappy with the IETF" > well, big deal. Yes, this is a big deal. The IETF can't be all things to all people, but I think it's a reasonable request for the IETF to clearly state what it will do and what it won't do, who makes this dicision and on what basis. > ] If people in general and large vendors > ] in particular come to the IETF wanting to work on something within > the > ] IETF, and this work falls within the areas of interest of the IETF, > ] then it would be a very good idea that the IETF indeed work on this. > I strongly disagree with this as a categorial statement. Many kinds > of work > that people want IETF to do are not "very good ideas". True. But the IETF still needs to work on it. When writing, they tell you that if someone comments on something in your story, you should always take this seriously. The comment itself is usually not something you can immediately use, as most people aren't good writers so they don't know how to solve writing problems. But most people are decent readers so when they feel compelled to comment you can be pretty sure there is a problem. The same applies here: if people want to create a bad protocol, there is probably some real problem that needs to be solved with a _good_ protocol. > IETF has been pressured by powerful concerns to standardize NATs, > means of eavesdropping, bits in IP headers to identify porn, protocols > that encourage monopolies or give one vendor a competitive advantage, > protocols that harm the Internet architecture and the ability of > existing and future applications to use the Internet, and even > protocols that don't interoperate (but which allow vendors > to claim standards compliance). None of these are good ideas, and > IETF should > neither invest its resources in, nor lend its imprimatur to, bad > ideas. Obviously there are always people who'll try to exploit something for personal gain. I have enough trust in both the leadership and the participants within the IETF to assume these people won't get very far. I'll ignore the architecture stuff here as this could fill a mailinglist of its own. The NAT pressure seems to have been effective: http://www.ietf.org/html.charters/nat-charter.html I'm not familiar with porn bits, but I can see how something like this could be transformed into PICS, which is a perfectly legitimate mechanism that addresses a very valid need. Then there is the lawful interception ("eavesdropping") thing. After a lot of discussion the IETF came up with a very solid position on this: we don't want to put eavesdropping capabilities in our protocols as this leads to weaker protocols. But governments are requiring now network operators to make lawful interception possible in their networks. Now one way to do this would be to simply put in fiber splitters all over the place and more or less build a shadow network that routes copies of all traffic to a place where the required subset can be handed over to the government. A slightly cheaper solution would be to have existing equipment copy the "interesting" traffic and only forward the copies to the handover location. I fully agree that it would be much better if this weren't necessary, because it's a big hassle and it still costs a lot of money. But most of us are living in democracies, and our administrations and parliaments have decided that this is necessary. This takes care of the "if", "when", "why" and "who pays for it" so the only remaining question is the "how". I would argue that the IETF is _the_ place to work this out, because: - the IETF has vast experience with IP in general - and IP security in particular - (nearly?) all IP vendors participate in the IETF - the IETF process is open and transparent - the IETF standards are available to anyone anywhere without limitation If you want to see what can happen if a non-IETF entity does this, go to http://www.opentap.org/documents.php3 and have a look at version 0.1.2 of the TIIT specs. (Version 1.0.0 was created after several vendors had tried to implement 0.1.2.) > Yes, some people will get frustrated with this. So be it. IETF > cannot do its > job properly without disappointing people. Unless IETF says "no" to > bad > ideas, there is no reason for IETF to exist. IETF is useless unless > it's > endorsement is a reasonably reliable indication of quality. > Currently, IETF > does not say "no" often enough - and that also has harmed its > reputation. This depends on what the IETF wants to be. Does it want to be the guardian of the internet protocols? Does it _only_ want to be this? It seems to me that a very important function of the IETF is to get vendors together to work out ideas. Now the IETF can pre-judge ideas and only allow the "good" ones (or rather, it could if there were 48 hours in the day) but I don't think this is a good idea. Let people work on their stuff within the IETF. This allows new ideas to seep into the IETF as well as long-time IETF principles to seep into these new protocols. Then, when the new protocols are as good as they're going to get, the IETF leadership can have some of the resident experts look the whole thing over and decide to lend its approval to the protocol or not. This way, the IETF doesn't need a crystal ball to see what's going to happen to a protocol in the future and even when a protocol isn't approved it has still benefited from the IETF's input. Last but not least, by also applying this methodology to "homegrown" protocols the IETF gets to raise the quality level of the protocols that are approved while at the same time being able to take on projects where success isn't automatically guaranteed. Alternatively, the IETF can go on the way it's doing now and not before long vendors will find other venues to get together for this kind of stuff. > ] Like _anyone_ can predict what is going to be good for the internet > ] anyway. Large vendors are reasonable indicators of what is wanted in > ] the internet and what's going to happen in the internet, though. > I disagree with that also. Large vendors do not represent their > customers' > interests, and they never have. Quite often the interests of large > vendors > are diametrically opposite of their customers'. Large vendors want to > maximize profit, customers want to maximize value. Large vendors want > to lock > in their customers, customers want flexibility. etc. Which is part > of why > IETF rules stipulate that participants must act in the best interests > of the > Internet as a whole. That's all very nice but reality is that the IETF writes protocols, and vendors implement a subset of the body of the IETF's protocols and then add some of their own. Customers then use a subset of what vendors implemented. This makes the IETF's influence over what happens on the internet indirect by two layers. If vendors come to the IETF that means they're at least open to _some_ criticism, so the IETF shouldn't turn them away unless there is a fairly clear intention of abuse of the IETF process. > ] They're implementing the stuff most boxes connected to the net will > be > ] running a couple of years from now. > The stuff may be in those boxes, and people may even try to use it. > But that > doesn't mean it's deserving of standardization or endorsement. > There's a lot > of garbage in deployed products. What's worse than a bad standard? A bad standard with non-interoperable implementations. (Yes, operations work has its downsides.) Having people work inside the IETF and lending endorsement are two very different things. As long as we're listing problems: the whole RFC status thing is lost on pretty much everyone. Stop publishing informational and experimental RFCs. From problem-statement-bounces@alvestrand.no Sat Jul 19 16:26:22 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22044 for ; Sat, 19 Jul 2003 16:26:21 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6A09061B8A; Sat, 19 Jul 2003 22:25:53 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from turkey.mail.pas.earthlink.net (turkey.mail.pas.earthlink.net [207.217.120.126]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6460C61B87 for ; Sat, 19 Jul 2003 22:25:51 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by turkey.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19dyGy-0001yy-00; Sat, 19 Jul 2003 13:25:40 -0700 Date: Sat, 19 Jul 2003 16:25:11 -0400 From: Keith Moore To: Iljitsch van Beijnum Message-Id: <20030719162511.0f6f0da5.moore@cs.utk.edu> In-Reply-To: <291D7CA5-BA1E-11D7-8554-00039388672E@muada.com> References: <20030719093851.37135aa8.moore@cs.utk.edu> <291D7CA5-BA1E-11D7-8554-00039388672E@muada.com> X-Mailer: Sylpheed version 0.9.1 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no, moore@cs.utk.edu Subject: Re: The IETF's problems X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit ] On zaterdag, jul 19, 2003, at 15:38 Europe/Amsterdam, Keith Moore wrote: ] ] > some people are unhappy with the IETF because their expection does not ] > match their perception of IETF's behavior. ] ] > or even more succinctly "some people are unhappy with the IETF" ] ] > well, big deal. ] ] Yes, this is a big deal. The IETF can't be all things to all people, ] but I think it's a reasonable request for the IETF to clearly state ] what it will do and what it won't do, who makes this dicision and on ] what basis. Defining IETF's scope is a good idea - if nothing else it will save energy when we need to explain why IETF is not taking on something it considers outside its scope. As for who makes the decision, that's already clear from existing documents. As for the basis on which these decisions are made, there are several factors - technical merit, evidence of willing and capable volunteers, availability of resources, perceived liklihood of success, and perceived benefit to the community as a whole being foremost among them. And these are inherently subjective. If it helps to write these down, fine, but they should be obvious. ] > ] If people in general and large vendors ] > ] in particular come to the IETF wanting to work on something within ] > the ] > ] IETF, and this work falls within the areas of interest of the IETF, ] > ] then it would be a very good idea that the IETF indeed work on this. ] ] > I strongly disagree with this as a categorial statement. Many kinds ] > of work that people want IETF to do are not "very good ideas". ] ] True. But the IETF still needs to work on it. As a generalization, I strongly disagree. (There may be specific cases where I would agree). But in general, we simply do not have enough resources to work on bad ideas. Even explaining why they're bad ideas sometimes takes too much work. ] The same applies here: if people want to create a ] bad protocol, there is probably some real problem that needs to be ] solved with a _good_ protocol. Sometimes yes, sometimes no. Sometimes there's a real problem to be solved and a real benefit to the community from solving it. If we can harness that interest in solving the problem and use it to produce a good solution, obviously that's a good thing. But quite often, we are pressured to endorse "solutions" that will only do harm. And far too often we form working groups to solve intractable problems, or working groups that are overwhelmingly staffed by people who are dedicated to "solving" a problem in a technically unsound way, in a misguided attempt to try to minimize the harm. ] > IETF has been pressured by powerful concerns to standardize NATs, ] > means of eavesdropping, bits in IP headers to identify porn, protocols ] > that encourage monopolies or give one vendor a competitive advantage, ] > protocols that harm the Internet architecture and the ability of ] > existing and future applications to use the Internet, and even ] > protocols that don't interoperate (but which allow vendors ] > to claim standards compliance). None of these are good ideas, and ] > IETF should ] > neither invest its resources in, nor lend its imprimatur to, bad ] > ideas. ] ] Obviously there are always people who'll try to exploit something for ] personal gain. I have enough trust in both the leadership and the ] participants within the IETF to assume these people won't get very far. There are many more root causes of stupidity than individual greed. ] I'll ignore the architecture stuff here as this could fill a ] mailinglist of its own. The NAT pressure seems to have been effective: ] http://www.ietf.org/html.charters/nat-charter.html Sometimes the pressure does result in a WG being created, and often this turns out to have been a bad idea. The NAT WG has been a disaster, doing far more harm than good. Zeroconf is another example. ] I'm not familiar ] with porn bits, but I can see how something like this could be ] transformed into PICS, which is a perfectly legitimate mechanism that ] addresses a very valid need. People wanted to be able to filter porn on a per-packet basis. We told them that this wasn't appropriate, and that labelling of content wasn't our problem, and they should take their efforts elsewhere. Telling them that was a wise thing for us to do. PICS hasn't been very effective, but at least IETF didn't get bogged down with working on it, and was able to spend its energies on other, hopefully more useful, pursuits. ] Then there is the lawful interception ("eavesdropping") thing. After a ] lot of discussion the IETF came up with a very solid position on this: ] we don't want to put eavesdropping capabilities in our protocols as ] this leads to weaker protocols. But governments are requiring now ] network operators to make lawful interception possible in their ] networks. Now one way to do this would be to simply put in fiber ] splitters all over the place and more or less build a shadow network ] that routes copies of all traffic to a place where the required subset ] can be handed over to the government. A slightly cheaper solution would ] be to have existing equipment copy the "interesting" traffic and only ] forward the copies to the handover location. I fully agree that it ] would be much better if this weren't necessary, because it's a big ] hassle and it still costs a lot of money. But most of us are living in ] democracies, and our administrations and parliaments have decided that ] this is necessary. IETF's job is to do what makes sense for the Internet and its users, not to provide mechanisms that governments demand - especially not when they are not based in technical sanity, and not when they conflict with the interests of Internet users. These days it is clear that the demands of governments, even so-called democratic governments, are often in opposition to the interests of their citizens. IETF should not assume that government demands are legitimate, and we should not try to decide which government demands are legitimate and which aren't. We should do what we think is best for the Internet. ] I would argue that the IETF is _the_ place to work this out, because: ] ] - the IETF has vast experience with IP in general ] - and IP security in particular ] - (nearly?) all IP vendors participate in the IETF ] - the IETF process is open and transparent ] - the IETF standards are available to anyone anywhere without limitation Ah yes, and just ignore the technical infeasibility, ignore governments' abuses of existing eavesdropping measures, and ignore the interests of the Internet community. Just give the governments what they need to monitor and control people and pretend that everything will be okay. There is no civil way to adequately respond to this. But I will do everything in my power to keep IETF from being subverted to these ends. ] If you want to see what can happen if a non-IETF entity does this, go ] to http://www.opentap.org/documents.php3 and have a look at version ] 0.1.2 of the TIIT specs. (Version 1.0.0 was created after several ] vendors had tried to implement 0.1.2.) Feel free to help them if you want to. Just do it elsewhere. ] > Yes, some people will get frustrated with this. So be it. IETF ] > cannot do its job properly without disappointing people. Unless IETF says ] > "no" to bad ideas, there is no reason for IETF to exist. IETF is useless ] > unless it's endorsement is a reasonably reliable indication of quality. ] > Currently, IETF does not say "no" often enough - and that also has harmed ] > its reputation. ] This depends on what the IETF wants to be. Does it want to be the ] guardian of the internet protocols? Does it _only_ want to be this? It ] seems to me that a very important function of the IETF is to get ] vendors together to work out ideas. Now the IETF can pre-judge ideas ] and only allow the "good" ones (or rather, it could if there were 48 ] hours in the day) but I don't think this is a good idea. Of course, you haven't tried to manage IETF's meager resources. You have no idea how thinly spread we are. ] Alternatively, the IETF can go on the way it's doing now and not before ] long vendors will find other venues to get together for this kind of ] stuff. It's been happening for many years. Sometimes those efforts succeed, often they fail for lack of backing or failure to anticipate some need. IETF cannot take on everything anyway. We might as well try to do what good we can, within our areas of interest and expertise. But in order for IETF to accomplish anything useful it must be selective in choosing where to invest its energy. ] ] > ] Like _anyone_ can predict what is going to be good for the internet ] > ] anyway. Large vendors are reasonable indicators of what is wanted in ] > ] the internet and what's going to happen in the internet, though. ] > I disagree with that also. Large vendors do not represent their ] > customers' interests, and they never have. Quite often the interests of ] > large vendors are diametrically opposite of their customers'. Large ] > vendors want to maximize profit, customers want to maximize value. Large ] > vendors want to lock in their customers, customers want flexibility. ] > etc. Which is part of why IETF rules stipulate that participants must ] > act in the best interests of the Internet as a whole. ] That's all very nice but reality is that the IETF writes protocols, and ] vendors implement a subset of the body of the IETF's protocols and then ] add some of their own. Customers then use a subset of what vendors ] implemented. This makes the IETF's influence over what happens on the ] internet indirect by two layers. If vendors come to the IETF that means ] they're at least open to _some_ criticism, so the IETF shouldn't turn ] them away unless there is a fairly clear intention of abuse of the IETF ] process. Experience indicates that attempts to steer vendors away from bad ideas within IETF often fail. Sometimes they do work. It's a judgement call. But the bottom line is that IETF should decide where to concentrate its energies - and should not consider itself bound by either the interests of large vendors or governments. ] > There's a lot of garbage in deployed products. ] ] What's worse than a bad standard? A bad standard with non-interoperable ] implementations. Stongly disagree. Sometimes lack of interoperability is a good thing, if it limits the ability of a bad protocol to be deployed, or if it provides incentives to replace a bad protocol. In the short term operations people pull their hair out trying to make shortsighted ideas work in practice, and that's unfortunate. But IETF needs to be primarily focused on medium- or long-term concerns, not spend its energies trying to fix every poorly-desinged vendor protocol out there. ] Having people work inside the IETF and lending endorsement are two very ] different things. Yes they are. But unfortunately when people do work in IETF they expect IETF to endorse that work even when the work is a failure. ] As long as we're listing problems: the whole RFC status thing is lost ] on pretty much everyone. Stop publishing informational and experimental ] RFCs. Another shortsighted idea. Keith From problem-statement-bounces@alvestrand.no Sun Jul 20 06:12:09 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15975 for ; Sun, 20 Jul 2003 06:12:08 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1D11561BD6; Sun, 20 Jul 2003 12:11:41 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from sequoia.muada.com (sequoia.muada.com [213.156.1.123]) by eikenes.alvestrand.no (Postfix) with ESMTP id C9EC061BB8 for ; Sun, 20 Jul 2003 12:11:38 +0200 (CEST) Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h6KACHxS007787; Sun, 20 Jul 2003 12:12:17 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Sun, 20 Jul 2003 12:11:40 +0200 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) To: Keith Moore From: Iljitsch van Beijnum In-Reply-To: <20030719162511.0f6f0da5.moore@cs.utk.edu> Message-Id: <8E5032C6-BA9A-11D7-8554-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Cc: problem-statement@alvestrand.no Subject: Re: The IETF's problems X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit On zaterdag, jul 19, 2003, at 22:25 Europe/Amsterdam, Keith Moore wrote: > As for the basis on which these decisions are made, there are several > factors - technical merit, evidence of willing and capable volunteers, > availability of resources, perceived liklihood of success, and > perceived > benefit to the community as a whole being foremost among them. And > these are > inherently subjective. If it helps to write these down, fine, but > they should > be obvious. How can they be obvious? I'll get into this a bit more on the "solutions" list but the way I see it is that the IETF should say: sure, we'll put up a mailinglist, we'll give you a slot in a room to talk about this during meetings and we'll accept drafts if IETF participants from at least X different organizations support this. When you're ready for this you get to propose the protocol to a working group that may or may not accept it as a work item. If the wg accepts it, at some point the IESG will have the work reviewed and it can be published as a draft standard. If not, then it may be published as experimental or informational. > ] > Many kinds of work that people want IETF to do are not "very good > ideas". > ] True. But the IETF still needs to work on it. > As a generalization, I strongly disagree. (There may be specific > cases where > I would agree). But in general, we simply do not have enough > resources to > work on bad ideas. Even explaining why they're bad ideas sometimes > takes too > much work. That's why it doesn't make sense to evaluate each and every proposal or -00 draft. But if participants from at least three or so organizations work on something for 6 months or a year and they all feel the protocol has merit, I think it's reasonable to spend some time looking at this. As for resources: the IETF has thousands of participants. I'm sure at least a few hundred are prepared to review proposed protocols from time to time, especially if they know their opinion really counts because they're "official" reviewers rather than the current situation where everyone must decide for themselves if they want to review something and there is no way to know whether this input will be taken in consideration by the powers that be. > ] The same applies here: if people want to create a > ] bad protocol, there is probably some real problem that needs to be > ] solved with a _good_ protocol. > Sometimes yes, sometimes no. Sometimes there's a real problem to be > solved > and a real benefit to the community from solving it. If we can > harness that > interest in solving the problem and use it to produce a good solution, > obviously that's a good thing. But quite often, we are pressured to > endorse > "solutions" that will only do harm. Obviously the IETF leadership should be capable of withstanding this type of pressure. And letting it simmer in a non-endorsed "ad hoc group" or whatever we want to call it probably gets rid of a fair share of bad proposals because those will very likely draw the attention of private participants with opinions on the matter without the need for formal action by the leadership. > And far too often we form working groups > to solve intractable problems, or working groups that are > overwhelmingly > staffed by people who are dedicated to "solving" a problem in a > technically > unsound way, in a misguided attempt to try to minimize the harm. If you can get something into a wg then you're well on your way to having it endorsed by "the IETF". So let people work on it outside a wg and then when there is plenty of opportunity to say "yea" or "nay". This forces people to work on the technical side of protocols first rather than getting something inside a wg. > IETF's job is to do what makes sense for the Internet and its users, > not to > provide mechanisms that governments demand - especially not when they > are > not based in technical sanity, and not when they conflict with the > interests > of Internet users. These days it is clear that the demands of > governments, > even so-called democratic governments, are often in opposition to the > interests of their citizens. IETF should not assume that government > demands > are legitimate, and we should not try to decide which government > demands are > legitimate and which aren't. We should do what we think is best for > the > Internet. Missing the point by a wide margin... Operators must take certain actions because these are demanded by governments. (This isn't entirely unreasonable by the way: do we want the internet to be a place where people can break the law in ways they can't elsewhere?) So operators look to their vendors to implement certain functionality. Yes, this sucks, but it's going to happen anyway. But let's at least standardize the handover interfaces so operators / mediation implementers only have to spend money on implementing this once. > ] I would argue that the IETF is _the_ place to work this out, because: > ] - the IETF has vast experience with IP in general > ] - and IP security in particular > ] - (nearly?) all IP vendors participate in the IETF > ] - the IETF process is open and transparent > ] - the IETF standards are available to anyone anywhere without > limitation > Ah yes, and just ignore the technical infeasibility, Nonsense. It's done today. But in proprietary ways that are more expensive than necessary. > ignore governments' abuses of existing eavesdropping measures, People sometimes pull the emergency break for no good reason. Rip them out then. This is a non-technical issue that must be addressed through nont-technical means. > and ignore the interests of the Internet community. Just give the > governments what they need to monitor and control people and pretend > that everything will be okay. On the internet everyone is nice so we don't need law enforcement. Yeah right. > There is no civil way to adequately respond to this. But I will do > everything > in my power to keep IETF from being subverted to these ends. This is a balancing act. You don't want to give unlimited power to governments because power corrupts and it _will_ be abused at some point. On the other hand, you don't want to leave governments powerless because that leaves us with the law of the jungle. Obviously different people are going to favor different tradoffs, but I think one where people get to use strong crypto, but governments have the ability to monitor the encrypted traffic under certain circumstances is a fair way to do it. This makes casual intrusion of privacy by governments very hard, but when necessary, it's still possible to uncover networks and gather information that can likely be decrypted and used as evidence later if and when the keys are recovered using more traditional techniques (search warrant). The IETF did the right thing twice before by creating protocols that allow strong encryption, and then refuse to add backdoors. Now it's time to do the right thing a third time by standardizing handover and provisioning protocols so operators can fullfil their obligations under the law in the most cost-effective and safest possible way. > ] If you want to see what can happen if a non-IETF entity does this, go > ] to http://www.opentap.org/documents.php3 and have a look at version > ] 0.1.2 of the TIIT specs. (Version 1.0.0 was created after several > ] vendors had tried to implement 0.1.2.) > Feel free to help them if you want to. Just do it elsewhere. :-) The real question is: do YOU want your ISP to have this stuff in their network? > ] Now the IETF can pre-judge ideas > ] and only allow the "good" ones (or rather, it could if there were 48 > ] hours in the day) but I don't think this is a good idea. > Of course, you haven't tried to manage IETF's meager resources. You > have no > idea how thinly spread we are. So let the participants earn their keep. Submit a draft? Review two others. With enough reviews for each protocol and for each reviewer, there shouldn't be much problems in determining which reviews have a high statistical likelihood of being "good". > But the bottom line is that IETF should decide where to concentrate its > energies - and should not consider itself bound by either the interests > of large vendors or governments. The way things are going now is a road leading nowhere: just reading all the drafts that come out is a full time job. So either _really_ do this and limit what's being done under the umbrella of the IETF by an order of magnitude or so, or remove the pretense of any selection on the input side but focus on the output side after the useful (which may or may not equal "good") ideas have floated to the surface. I can imagine a system where the IESG has time to evaluate n proposals (where n can be increased by not trying to do the full technical review inside the IESG) per unit of time so it simply evaluates the n proposals with the most support from the IETF membership at large. (Where membership could be "showed up at the meeting" or something else.) > ] What's worse than a bad standard? A bad standard with > non-interoperable > ] implementations. > Stongly disagree. Sometimes lack of interoperability is a good thing, > if it limits the ability of a bad protocol to be deployed, or if it > provides > incentives to replace a bad protocol. If the protocol isn't bad enough that it carries an inherent incentive for replacement, then maybe it's not so bad after all. > In the short term operations people pull > their hair out trying to make shortsighted ideas work in practice, and > that's > unfortunate. That's what we need, operations people with less hair... > But IETF needs to be primarily focused on medium- or long-term > concerns, not spend its energies trying to fix every poorly-desinged > vendor > protocol out there. Don't fix it. Give them a mailinglist and a meeting room and a whiteboard. They are big boys and girls so they can do this themselves. The good stuff will float to the surface. > ] Having people work inside the IETF and lending endorsement are two > very > ] different things. > Yes they are. But unfortunately when people do work in IETF they > expect IETF > to endorse that work even when the work is a failure. I think there is rough consensus on what should be done in these cases. > ] As long as we're listing problems: the whole RFC status thing is lost > ] on pretty much everyone. Stop publishing informational and > experimental > ] RFCs. > Another shortsighted idea. Maybe. But with close to 3000 RFCs out there and nearly noone knowing which are jokes, which are curiosities, which are [the list goes on] and which are standards, there is a problem that needs to be addressed. From problem-statement-bounces@alvestrand.no Sun Jul 20 09:23:08 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18540 for ; Sun, 20 Jul 2003 09:23:08 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D396361BB8; Sun, 20 Jul 2003 15:22:40 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1534661B8F for ; Sun, 20 Jul 2003 15:22:39 +0200 (CEST) Received: from newdev.harvard.edu (localhost [127.0.0.1]) by newdev.harvard.edu (8.12.9/8.12.2) with ESMTP id h6KDMc9n023496 for ; Sun, 20 Jul 2003 09:22:38 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.9/8.12.2/Submit) id h6KDMcVf023495 for problem-statement@alvestrand.no; Sun, 20 Jul 2003 09:22:38 -0400 (EDT) Date: Sun, 20 Jul 2003 09:22:38 -0400 (EDT) From: Scott Bradner Message-Id: <200307201322.h6KDMcVf023495@newdev.harvard.edu> To: problem-statement@alvestrand.no Subject: alernate standards track proposal X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no I just submitted an ID that describes a possible alternate IETF standards track for those who do not want to wait: http://www.sobco.com/ietf/draft-bradner-ietf-stds.trk-00.txt discussion on solutions list please Scott From problem-statement-bounces@alvestrand.no Sun Jul 20 11:17:56 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21146 for ; Sun, 20 Jul 2003 11:17:55 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 87E7561B9D; Sun, 20 Jul 2003 17:17:28 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from swan.mail.pas.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8D67461B90 for ; Sun, 20 Jul 2003 17:17:27 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by swan.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19eFw9-0006SC-00; Sun, 20 Jul 2003 08:17:21 -0700 Date: Sun, 20 Jul 2003 11:16:47 -0400 From: Keith Moore To: Iljitsch van Beijnum Message-Id: <20030720111647.4b731fc9.moore@cs.utk.edu> In-Reply-To: <8E5032C6-BA9A-11D7-8554-00039388672E@muada.com> References: <20030719162511.0f6f0da5.moore@cs.utk.edu> <8E5032C6-BA9A-11D7-8554-00039388672E@muada.com> X-Mailer: Sylpheed version 0.9.1 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no, moore@cs.utk.edu Subject: Re: The IETF's problems X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit since most of this is not in scope for problem-statement - either it is solution space or something else entirely - I'll make my public reply brief, and reply privately in more detail. - your proposed solutions for managing increased workload will not scale, nor will they ensure technical soundness. - you are being unrealistic in expecting IETF to take on every bit of work for which there is interest, even if IETF doesn't give them a working group - it is not in the interests of the Internet, nor in the interest of IETF, for IETF to support the efforts of governments to use the Internet for surveillance. no matter how well-intended, IETF will not be able to limit the efforts of governments who wish to use this capability inappropriately. IETF work in this area can at best be a waste of its energy, and at worst lend support to corrupt governments. - rough consensus is not a reliable indicator of protocol quality, nor a sufficient condition for standardization. and for the one topic relevant to problem-statement: - I agree that with so many RFCs the distinction between the various kinds of status is unclear. however experimental and informational RFCs are useful as supplemental material to standards documents, and for other purposes, so I do not agree with your proposed solution. From problem-statement-bounces@alvestrand.no Sun Jul 20 12:16:31 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22100 for ; Sun, 20 Jul 2003 12:16:31 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8936261B90; Sun, 20 Jul 2003 18:16:03 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from sequoia.muada.com (sequoia.muada.com [213.156.1.123]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1A0A361B8F for ; Sun, 20 Jul 2003 18:16:02 +0200 (CEST) Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h6KGGfxS011510; Sun, 20 Jul 2003 18:16:41 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Sun, 20 Jul 2003 18:16:05 +0200 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) To: Keith Moore From: Iljitsch van Beijnum In-Reply-To: <20030720111647.4b731fc9.moore@cs.utk.edu> Message-Id: <76AF66AE-BACD-11D7-8554-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Cc: problem-statement@alvestrand.no Subject: Re: The IETF's problems X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit On zondag, jul 20, 2003, at 17:16 Europe/Amsterdam, Keith Moore wrote: > since most of this is not in scope for problem-statement - either it > is solution space or something else entirely - I'll make my public > reply brief, and reply privately in more detail. Ok. > - your proposed solutions for managing increased workload will not > scale, > nor will they ensure technical soundness. You are right that creating a structured way for the membership at large to review doesn't magically solve everything. But I'm pretty sure it will at least help. More when I've subscribed to the solutions list. > - you are being unrealistic in expecting IETF to take on every bit of > work for which there is interest, even if IETF doesn't give them a > working > group Ok, I guess I am. However, the current situation is very problematic, as the filter that must let in useful new work and keep out not-so-useful new work doesn't really do its job. I would even like to go so far as it keeps out new people to a very large degree while those in the inner circle can pretty much put anything they want on the agenda. > - it is not in the interests of the Internet, nor in the interest of > IETF, > for IETF to support the efforts of governments to use the Internet for > surveillance. no matter how well-intended, IETF will not be able to > limit > the efforts of governments who wish to use this capability > inappropriately. > IETF work in this area can at best be a waste of its energy, and at > worst > lend support to corrupt governments. How stubborn can one person be? 1. The law says operators must be capable of X. 2. In order to do X, operators need capability Y from their equipment. 3. A vendor comes to the IETF and says: let's standardize a protocol for doing Y. Now how is frustrating 3. going to keep X from happening??? In fact, failing to create a way to limit interception to only that which falls withing the scope of the warrant almost guarantees governments will end up with more intercepted data than they asked for. How can this be a good thing? > and for the one topic relevant to problem-statement: > - I agree that with so many RFCs the distinction between the various > kinds of status is unclear. however experimental and informational > RFCs are useful as supplemental material to standards documents, > and for other purposes, so I do not agree with your proposed solution. I think we've been miscommunicating here. I didn't mean these shouldn't be published anymore, just that they shouldn't share a namespace with standards documents. I completely agree that there is lots of useful supplemental material. However, not nearly enough of it is published in a structured way. For instance, I can understand why someone would think the deletion of drafts is a good idea, but in practice this really doesn't help with anything. From problem-statement-bounces@alvestrand.no Sun Jul 20 12:25:33 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22249 for ; Sun, 20 Jul 2003 12:25:33 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 210FB61B90; Sun, 20 Jul 2003 18:25:06 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from flamingo.mail.pas.earthlink.net (flamingo.mail.pas.earthlink.net [207.217.120.232]) by eikenes.alvestrand.no (Postfix) with ESMTP id 188FA61B8F for ; Sun, 20 Jul 2003 18:25:04 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by flamingo.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19eGzb-00007b-00; Sun, 20 Jul 2003 09:24:59 -0700 Date: Sun, 20 Jul 2003 12:24:27 -0400 From: Keith Moore To: Iljitsch van Beijnum Message-Id: <20030720122427.63234216.moore@cs.utk.edu> In-Reply-To: <76AF66AE-BACD-11D7-8554-00039388672E@muada.com> References: <20030720111647.4b731fc9.moore@cs.utk.edu> <76AF66AE-BACD-11D7-8554-00039388672E@muada.com> X-Mailer: Sylpheed version 0.9.1 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no, moore@cs.utk.edu Subject: Re: The IETF's problems X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit > How stubborn can one person be? > > 1. The law says operators must be capable of X. yes, how stubborn can one person be? just because a government passes a law doesn't mean IETF should expend its energy to try to help them. there are lots of corrupt governments, and lots of bad laws, neither of which are deserving of IETF support. nor is there anything IETF can do to limit the harm that will be done. the most we should do is to say "nothing has changed since we issued RFC 1984" now, can we please get back to the topic of this list? From problem-statement-bounces@alvestrand.no Sun Jul 20 12:39:11 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22419 for ; Sun, 20 Jul 2003 12:39:11 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B385D61B90; Sun, 20 Jul 2003 18:38:43 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from sequoia.muada.com (sequoia.muada.com [213.156.1.123]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8AF9C61B8F for ; Sun, 20 Jul 2003 18:38:42 +0200 (CEST) Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h6KGdMxS011763; Sun, 20 Jul 2003 18:39:22 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Sun, 20 Jul 2003 18:38:45 +0200 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) To: Keith Moore From: Iljitsch van Beijnum In-Reply-To: <20030720122427.63234216.moore@cs.utk.edu> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Cc: problem-statement@alvestrand.no Subject: Re: The IETF's problems X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit On zondag, jul 20, 2003, at 18:24 Europe/Amsterdam, Keith Moore wrote: >> How stubborn can one person be? > yes, how stubborn can one person be? > just because a government passes a law doesn't mean IETF should expend > its > energy to try to help them. There is a little more going on than just one government passing a law. And it's certainly not about helping governments, it's about helping service providers and smaller vendors. Cisco is trying to do the responsible thing here by coming to the IETF to standardize this stuff. > now, can we please get back to the topic of this list? This is a prime example of the topic of this list: the IETF is unable to determine what it should work on and what it shouldn't work on in a satisfactory way. From problem-statement-bounces@alvestrand.no Sun Jul 20 12:43:26 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22549 for ; Sun, 20 Jul 2003 12:43:26 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 06F1B61BB9; Sun, 20 Jul 2003 18:43:00 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by eikenes.alvestrand.no (Postfix) with ESMTP id A748761B8F for ; Sun, 20 Jul 2003 18:42:58 +0200 (CEST) Received: from newdev.harvard.edu (localhost [127.0.0.1]) by newdev.harvard.edu (8.12.9/8.12.2) with ESMTP id h6KGgv9n023969 for ; Sun, 20 Jul 2003 12:42:57 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.9/8.12.2/Submit) id h6KGgvGh023968 for problem-statement@alvestrand.no; Sun, 20 Jul 2003 12:42:57 -0400 (EDT) Date: Sun, 20 Jul 2003 12:42:57 -0400 (EDT) From: Scott Bradner Message-Id: <200307201642.h6KGgvGh023968@newdev.harvard.edu> To: problem-statement@alvestrand.no Subject: Re: alernate standards track proposal X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no something seems to be wrong with resolving my web site so I just posted a copy of my proposal to the solutions list Scott From problem-statement-bounces@alvestrand.no Sun Jul 20 13:29:14 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23049 for ; Sun, 20 Jul 2003 13:29:14 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1EDA261BB9; Sun, 20 Jul 2003 19:28:45 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7C35161B8F for ; Sun, 20 Jul 2003 19:28:42 +0200 (CEST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h6KHSduD021524; Sun, 20 Jul 2003 10:28:40 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJU33161; Sun, 20 Jul 2003 10:28:39 -0700 (PDT) Message-Id: <200307201728.AJU33161@mira-sjc5-c.cisco.com> To: Iljitsch van Beijnum From: Melinda Shore In-Reply-To: Message from iljitsch@muada.com of "Sun, 20 Jul 2003 18:38:45 +0200." Date: Sun, 20 Jul 2003 13:28:38 -0400 Cc: problem-statement@alvestrand.no Subject: Re: The IETF's problems X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no > This is a prime example of the topic of this list: the IETF is unable > to determine what it should work on and what it shouldn't work on in a > satisfactory way. The discussion itself isn't doing much to distill the topic down to document text, and we need to stay focused. Do you feel that existing text regarding scope in the problem statement document is inadequate? Thanks, Melinda From problem-statement-bounces@alvestrand.no Sun Jul 20 13:53:52 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23348 for ; Sun, 20 Jul 2003 13:53:52 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3E5FF61B90; Sun, 20 Jul 2003 19:53:23 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by eikenes.alvestrand.no (Postfix) with ESMTP id E189361B8F for ; Sun, 20 Jul 2003 19:53:20 +0200 (CEST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h6KHq0J01938; Sun, 20 Jul 2003 13:52:00 -0400 (EDT) Date: Sun, 20 Jul 2003 13:51:59 -0400 From: Keith Moore To: Iljitsch van Beijnum Message-Id: <20030720135159.7cfef1e7.moore@cs.utk.edu> In-Reply-To: References: <20030720122427.63234216.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no, moore@cs.utk.edu Subject: Re: The IETF's problems X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit > > just because a government passes a law doesn't mean IETF should > > expend its energy to try to help them. > > There is a little more going on than just one government passing a > law. yes, there are lots of governments trying to conduct mass surveillance on people. that still doesn't mean IETF should help them. > And it's certainly not about helping governments, it's about helping > service providers and smaller vendors. no, it's about not wasting IETF energy by investing it in areas where it can only do harm. > Cisco is trying to do the > responsible thing here by coming to the IETF to standardize this > stuff. Cisco is trying to get IETF backing for an irresponsible activity. What Cisco does is its own business, but IETF shouldn't be goaded into supporting it just because Cisco does it - particuarly when nothing useful can come of it and when it is inconsistent with IETF's goals. > > now, can we please get back to the topic of this list? > > This is a prime example of the topic of this list: the IETF is unable > to determine what it should work on and what it shouldn't work on in a > satisfactory way. it's a prime example of why we shouldn't work on something just because large vendors want us to. From problem-statement-bounces@alvestrand.no Sun Jul 20 14:27:24 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23692 for ; Sun, 20 Jul 2003 14:27:23 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 77BA061B90; Sun, 20 Jul 2003 20:26:55 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from mtiwmhc13.worldnet.att.net (mtiwmhc13.worldnet.att.net [204.127.131.117]) by eikenes.alvestrand.no (Postfix) with ESMTP id A8FE861B8F for ; Sun, 20 Jul 2003 20:26:53 +0200 (CEST) Received: from tsg1 (174.sanjose-08-09rs16rt.ca.dial-access.att.net[12.81.3.174]) by mtiwmhc13.worldnet.att.net (mtiwmhc13) with SMTP id <2003072018264911300f0uj1e>; Sun, 20 Jul 2003 18:26:50 +0000 Message-ID: <06b301c34eec$71b128f0$020aff0a@tsg1> From: "todd glassey" To: "James Seng" , "Contreras, Jorge" References: <20030718143540.324c7ab7.moore@cs.utk.edu><7C1FF869-B9DB-11D7-8554-00039388672E@muada.com> <20030719093851.37135aa8.moore@cs.utk.edu> <034b01c34e01$80ac5fa0$020aff0a@tsg1> <3F196AD8.1070107@pobox.org.sg> Date: Sun, 20 Jul 2003 10:59:49 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Cc: problem-statement@alvestrand.no, Keith Moore Subject: Re: The IETF's problems X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "James Seng" To: "todd glassey" Cc: "Keith Moore" ; "Iljitsch van Beijnum" ; Sent: Saturday, July 19, 2003 8:59 AM Subject: Re: The IETF's problems > we dont decide what technologies are made available for use on the > Internet. > > but we can choose the work we want to do, and RFC we want to publish. No James you cannot. You can decide what you personally want to work on but the instant you try and stop someone elses initiative you become a legal problem to the organization. The ISTE is not your personal resource, in fact the vetting resource is not the IETF's at all. It belongsx to the participants, and any refusal to allow any protocol or submission in is a problem. Ask Jorge if you doubt this. > > ps: My view is that so long there is sufficient interest (or rough > consensus) in any work, whether it comes from a large vendor or not is > irrelevant. In fact, if a good idea comes a large vendor and people are > interested to work on it, all the more we should. Cool - I also have very similar views, and I also see that it is irrelevent where a submission comes from as long as its properly disclosed. Myself, I think that caveat emptor is the watchword here anyway so... But the real issue here is that the IETF has essentially used itself to lock any numbe rof initiatives out of the running becuase one of the sponsers already had an initiative underway there or had a financial interest in not losing their "champion" for lack of a better word. Unfortunately, what this has made is an Oligarchy of sorts of the IETF and its initiatives. There is no way to retire a standard, nor any possibiliy for any upstart to realistically bring a protocol through fruition in the IETF's process if any of the established players dont want it to happen... I suggest that you read the document I just submitted to the I-D desk called Fair and Open RFC2026... Its an analysis of the terms fair and open and an analysis of the language used in RFC2026 and what it mandates as far as acceptable IETF processes. Except that its bounced several times already... for some reason... Todd > > james > > todd glassey wrote: > > Keith - who are you or the IETF to make any commentary or anything else as > > to what technologies are made available for use on the Internet. You nor > > your management are empowered to govern the Internet and as such your > > actions here constitute an restraint of trade if their are implemented as > > policy. > > > > Todd > > > > ----- Original Message ----- > > From: "Keith Moore" > > To: "Iljitsch van Beijnum" > > Cc: ; > > Sent: Saturday, July 19, 2003 6:38 AM > > Subject: Re: The IETF's problems > > > > > > > >>] >> But when even large vendors are unable to get protocols that > >>] >> they feel is important (and have implemented or are implementing) > >>] >> "through" IETF, there is a problem. > >>] > >>] > Let's get this straight right now. > >>] > >>] Yes, let's. Because whichever party is suffering from the misconception > >>] here, the result is the same: some people are unhappy with what the > >>] IETF does because their expectations don't match reality. > >> > >>some people are unhappy with the IETF because their expection does not > >>match their perception of IETF's behavior. > >> > >>or even more succinctly "some people are unhappy with the IETF" > >> > >>well, big deal. > >> > >>] If people in general and large vendors > >>] in particular come to the IETF wanting to work on something within the > >>] IETF, and this work falls within the areas of interest of the IETF, > >>] then it would be a very good idea that the IETF indeed work on this. > >> > >>I strongly disagree with this as a categorial statement. Many kinds of > > > > work > > > >>that people want IETF to do are not "very good ideas". IETF has been > >>pressured by powerful concerns to standardize NATs, means of > > > > eavesdropping, > > > >>bits in IP headers to identify porn, protocols that encourage monopolies > > > > or > > > >>give one vendor a competitive advantage, protocols that harm the Internet > >>architecture and the ability of existing and future applications to use > > > > the > > > >>Internet, and even protocols that don't interoperate (but which allow > > > > vendors > > > >>to claim standards compliance). None of these are good ideas, and IETF > > > > should > > > >>neither invest its resources in, nor lend its imprimatur to, bad ideas. > >> > >>Yes, some people will get frustrated with this. So be it. IETF cannot do > > > > its > > > >>job properly without disappointing people. Unless IETF says "no" to bad > >>ideas, there is no reason for IETF to exist. IETF is useless unless it's > >>endorsement is a reasonably reliable indication of quality. Currently, > > > > IETF > > > >>does not say "no" often enough - and that also has harmed its reputation. > >> > >>] > And large vendors are not reliable indicators of what is good for the > >>] > Internet. > >>] > >>] Like _anyone_ can predict what is going to be good for the internet > >>] anyway. Large vendors are reasonable indicators of what is wanted in > >>] the internet and what's going to happen in the internet, though. > >> > >>I disagree with that also. Large vendors do not represent their > > > > customers' > > > >>interests, and they never have. Quite often the interests of large > > > > vendors > > > >>are diametrically opposite of their customers'. Large vendors want to > >>maximize profit, customers want to maximize value. Large vendors want to > > > > lock > > > >>in their customers, customers want flexibility. etc. Which is part of > > > > why > > > >>IETF rules stipulate that participants must act in the best interests of > > > > the > > > >>Internet as a whole. > >> > >>] They're implementing the stuff most boxes connected to the net will be > >>] running a couple of years from now. > >> > >>The stuff may be in those boxes, and people may even try to use it. But > > > > that > > > >>doesn't mean it's deserving of standardization or endorsement. There's a > > > > lot > > > >>of garbage in deployed products. > >> > >> > > > > > > > > > > From problem-statement-bounces@alvestrand.no Sun Jul 20 14:46:10 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24253 for ; Sun, 20 Jul 2003 14:46:09 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2760F61B90; Sun, 20 Jul 2003 20:45:41 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2F45461B8F for ; Sun, 20 Jul 2003 20:45:39 +0200 (CEST) Received: from tsg1 (174.sanjose-08-09rs16rt.ca.dial-access.att.net[12.81.3.174]) by mtiwmhc12.worldnet.att.net (mtiwmhc12) with SMTP id <2003072018453611200lot7ue>; Sun, 20 Jul 2003 18:45:36 +0000 Message-ID: <06b601c34eef$10f88aa0$020aff0a@tsg1> From: "todd glassey" To: "Scott Bradner" , References: <200307201322.h6KDMcVf023495@newdev.harvard.edu> Date: Sun, 20 Jul 2003 11:45:11 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: Re: alernate standards track proposal X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Scott/All there is an analysis document that has been submitted to the I_D editors on the requirements of being Fair and Open as per your latest version of RFC2026. I believe that this document bears examination since these words are key to maintaining equality and open access to all of the IETF... if there is anyone that wants to see this draft immediately try http://www.glassey.com/repository/fairandopen.txt or http://www.glassey.com/repository/fairandopen.pdf Todd Glassey ----- Original Message ----- From: "Scott Bradner" To: Sent: Sunday, July 20, 2003 6:22 AM Subject: alernate standards track proposal > > I just submitted an ID that describes a possible alternate > IETF standards track > > for those who do not want to wait: > http://www.sobco.com/ietf/draft-bradner-ietf-stds.trk-00.txt > > discussion on solutions list please > > Scott From problem-statement-bounces@alvestrand.no Sun Jul 20 20:49:55 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02156 for ; Sun, 20 Jul 2003 20:49:54 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A04DB61BE6; Mon, 21 Jul 2003 02:49:25 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from mtiwmhc11.worldnet.att.net (mtiwmhc11.worldnet.att.net [204.127.131.115]) by eikenes.alvestrand.no (Postfix) with ESMTP id B0BBB61BB0 for ; Mon, 21 Jul 2003 02:49:23 +0200 (CEST) Received: from tsg1 (174.sanjose-08-09rs16rt.ca.dial-access.att.net[12.81.3.174]) by mtiwmhc11.worldnet.att.net (mtiwmhc11) with SMTP id <2003072100491711100cdf5de>; Mon, 21 Jul 2003 00:49:18 +0000 Message-ID: <003f01c34f21$ddee8fa0$020aff0a@tsg1> From: "todd glassey" To: "Iljitsch van Beijnum" , "Melinda Shore" References: <200307201728.AJU33161@mira-sjc5-c.cisco.com> Date: Sun, 20 Jul 2003 17:39:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Cc: problem-statement@alvestrand.no Subject: Re: The IETF's problems X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Melinda, ----- Original Message ----- From: "Melinda Shore" To: "Iljitsch van Beijnum" Cc: Sent: Sunday, July 20, 2003 10:28 AM Subject: Re: The IETF's problems > > This is a prime example of the topic of this list: the IETF is unable > > to determine what it should work on and what it shouldn't work on in a > > satisfactory way. > > The discussion itself isn't doing much to distill the topic > down to document text, and we need to stay focused. Do you > feel that existing text regarding scope in the problem > statement document is inadequate? the cause(s) of the problem here is that the IETF is not an entity that has a brain nor an opinion. It is by its charter and definition, an "Open and Fair" standards process... and as such the IETF provides a platform for moving those initiatives submitted within it to satisfaction of a preset series of goals or milestones. It, the IETF then is an organization and one by pure definition that gets no opinion on anything, except as to whether the cafeteria style checklist items for any given initiative are completed and nothing more. This is the key failing of the IETF in that WG Chairs have used it to set what they will and wont work on and this has caused probably billions of dollars in damages to companies that tried to work with the IETF and were shutdown. As to whether this phenomenum is real or not, I personally lost about 4M in equity in Coastek primarily from what the VC's told us becuase PKIX refused to hear another timestamping protocol back when the original one was proposed in 1997. Todd Glassey > > Thanks, > > Melinda From problem-statement-bounces@alvestrand.no Sun Jul 20 20:50:02 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02171 for ; Sun, 20 Jul 2003 20:50:01 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 519A461BED; Mon, 21 Jul 2003 02:49:34 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from mtiwmhc11.worldnet.att.net (mtiwmhc11.worldnet.att.net [204.127.131.115]) by eikenes.alvestrand.no (Postfix) with ESMTP id 36AAB61BB0 for ; Mon, 21 Jul 2003 02:49:25 +0200 (CEST) Received: from tsg1 (174.sanjose-08-09rs16rt.ca.dial-access.att.net[12.81.3.174]) by mtiwmhc11.worldnet.att.net (mtiwmhc11) with SMTP id <2003072100492211100cdf5ee>; Mon, 21 Jul 2003 00:49:23 +0000 Message-ID: <004001c34f21$e1570f00$020aff0a@tsg1> From: "todd glassey" To: "Keith Moore" , "Iljitsch van Beijnum" References: <20030720122427.63234216.moore@cs.utk.edu> <20030720135159.7cfef1e7.moore@cs.utk.edu> Date: Sun, 20 Jul 2003 17:45:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Cc: problem-statement@alvestrand.no, moore@cs.utk.edu Subject: Re: The IETF's problems X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Keith Moore" To: "Iljitsch van Beijnum" Cc: ; Sent: Sunday, July 20, 2003 10:51 AM Subject: Re: The IETF's problems > > > just because a government passes a law doesn't mean IETF should > > > expend its energy to try to help them. > > > > There is a little more going on than just one government passing a > > law. > > yes, there are lots of governments trying to conduct mass surveillance > on people. that still doesn't mean IETF should help them. The IETF is not to stop them either. The IETF is a standards process not the morality or ethics keeper of the Internet unless you and your sponsers want to pay damage claims from the rest of us. > > > And it's certainly not about helping governments, it's about helping > > service providers and smaller vendors. > > no, it's about not wasting IETF energy by investing it in areas where > it can only do harm. No its not. Its about people like you being able to say what is and is not woked on. The only way to describe the effect herein is "restraint of trade" and "tortuous interferance with the operations of a business" that is dependant on the IETF's open and fair services. > > > Cisco is trying to do the > > responsible thing here by coming to the IETF to standardize this > > stuff. > > Cisco is trying to get IETF backing for an irresponsible activity. > What Cisco does is its own business, but IETF shouldn't be goaded > into supporting it just because Cisco does it - particuarly when > nothing useful can come of it and when it is inconsistent with IETF's > goals. I agree with you here personally as far as Cisco's initiatives go, but I also want to state that Cisco's initiatives have the same weight as all others here and should be the same. So they like anyone else that completes the process should be able to get a standard issued against their wares. its up to the marketplace and not the IETF to determine what is and is not the dominent player. > > > > now, can we please get back to the topic of this list? > > > > This is a prime example of the topic of this list: the IETF is unable > > to determine what it should work on and what it shouldn't work on in a > > satisfactory way. > > it's a prime example of why we shouldn't work on something just because > large vendors want us to. But your push back essentially allows you to state that the IETF can decided what and what it does not want to work on and that likewise is a restraint of trade development. Todd > From problem-statement-bounces@alvestrand.no Sun Jul 20 21:22:48 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02617 for ; Sun, 20 Jul 2003 21:22:47 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0A05761BE9; Mon, 21 Jul 2003 03:22:19 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2FCFD61BE6; Mon, 21 Jul 2003 03:22:17 +0200 (CEST) Received: from tsg1 (174.sanjose-08-09rs16rt.ca.dial-access.att.net[12.81.3.174]) by mtiwmhc12.worldnet.att.net (mtiwmhc12) with SMTP id <2003072101221311200q5rr3e>; Mon, 21 Jul 2003 01:22:14 +0000 Message-ID: <007101c34f26$77bb6ff0$020aff0a@tsg1> From: "todd glassey" To: , "Contreras, Jorge" , "Harald Tveit Alvestrand" Date: Sun, 20 Jul 2003 18:21:44 -0700 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_006E_01C34EEB.C66FE990" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: Fw: The results of your email commands X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no This is a multi-part message in MIME format. ------=_NextPart_000_006E_01C34EEB.C66FE990 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Is the bouncing part of what you will also fix Harald? Todd ----- Original Message ----- From: To: Sent: Sunday, July 20, 2003 5:59 PM Subject: The results of your email commands > The results of your email command are provided below. Attached is your > original message. > > > - Unprocessed: > anything regarding that ID's cannot be submitted for consideration past a > particular cut off date, but that does not mean that the ones submitted will > get considered in the next meeting, but that the Editors Operations are shut > down for the period around the Meetings and this either needs to be > documented or changed so that they are up 7x24 and 365 days a year. > Todd > ----- Original Message ----- > From: "Internet Draft Submission Manager" > To: > Sent: Sunday, July 20, 2003 11:29 AM > Subject: Re: resubmission of Glassey's Fair and Open draft > > Greetings: > > > > This message is being sent to acknowledge receipt of your > > Internet-Draft submission or message to internet-drafts@ietf.org. > > Please note that the pre-meeting cutoff date for Internet-Draft > submissions > > was Monday, June 30th 2003 at 9:00 AM Eastern Time. > > > > Therefore, if you submitted an Internet-Draft, then your > > - Ignored: > > document will NOT be processed or retained. Please resubmit your document > > on or after Friday, July 18th 2003. > > > > All Internet-Drafts submitted on or after July 18th will be processed > upon > > receipt. However, Internet-Draft announcements will not be sent until > > after the IETF Meeting. > > > > The IETF Secretariat > > > > > - Done. > > ------=_NextPart_000_006E_01C34EEB.C66FE990 Content-Type: message/rfc822; name="problem with Submission Features in RFC2026 - Fw_ resubmission ofGlassey's Fair and Open draft.eml" Content-Disposition: attachment; filename="problem with Submission Features in RFC2026 - Fw_ resubmission ofGlassey's Fair and Open draft.eml" Return-Path: X-Original-To: problem-statement-request@alvestrand.no Delivered-To: problem-statement-request@alvestrand.no Received: from mtiwmhc11.worldnet.att.net (mtiwmhc11.worldnet.att.net [204.127.131.115]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4D9ED61BE3 for ; Mon, 21 Jul 2003 02:59:43 +0200 (CEST) Received: from tsg1 (174.sanjose-08-09rs16rt.ca.dial-access.att.net[12.81.3.174]) by mtiwmhc11.worldnet.att.net (mtiwmhc11) with SMTP id <2003072100593711100admmte>; Mon, 21 Jul 2003 00:59:37 +0000 Message-ID: <005d01c34f23$4f3503f0$020aff0a@tsg1> From: "todd glassey" To: Subject: problem with Submission Features in RFC2026 - Fw: resubmission of Glassey's Fair and Open draft Date: Sun, 20 Jul 2003 17:56:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit This is a problem statement that I could not find in RFC2026 and that was anything regarding that ID's cannot be submitted for consideration past a particular cut off date, but that does not mean that the ones submitted will get considered in the next meeting, but that the Editors Operations are shut down for the period around the Meetings and this either needs to be documented or changed so that they are up 7x24 and 365 days a year. Todd ----- Original Message ----- From: "Internet Draft Submission Manager" To: Sent: Sunday, July 20, 2003 11:29 AM Subject: Re: resubmission of Glassey's Fair and Open draft > Greetings: > > This message is being sent to acknowledge receipt of your > Internet-Draft submission or message to internet-drafts@ietf.org. > Please note that the pre-meeting cutoff date for Internet-Draft submissions > was Monday, June 30th 2003 at 9:00 AM Eastern Time. > > Therefore, if you submitted an Internet-Draft, then your > document will NOT be processed or retained. Please resubmit your document > on or after Friday, July 18th 2003. > > All Internet-Drafts submitted on or after July 18th will be processed upon > receipt. However, Internet-Draft announcements will not be sent until > after the IETF Meeting. > > The IETF Secretariat > ------=_NextPart_000_006E_01C34EEB.C66FE990-- From problem-statement-bounces@alvestrand.no Mon Jul 21 04:38:05 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20949 for ; Mon, 21 Jul 2003 04:38:05 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0F92C61BE8; Mon, 21 Jul 2003 10:37:37 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from HALVESTR-W2K1.cisco.com (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 00F7D61B9C; Mon, 21 Jul 2003 10:37:32 +0200 (CEST) Date: Mon, 21 Jul 2003 07:23:06 +0200 From: Harald Tveit Alvestrand To: todd glassey , problem-statement@alvestrand.no Message-ID: <200296070.1058772186@localhost> In-Reply-To: <007101c34f26$77bb6ff0$020aff0a@tsg1> References: <007101c34f26$77bb6ff0$020aff0a@tsg1> X-Mailer: Mulberry/3.0.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: Fw: The results of your email commands X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit stop sending regular mail to problem-statement-request. That should stop you getting replies from the subscribe-handling autoresponder. Harald --On 20. juli 2003 18:21 -0700 todd glassey wrote: > Is the bouncing part of what you will also fix Harald? > From problem-statement-bounces@alvestrand.no Mon Jul 21 05:17:37 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21761 for ; Mon, 21 Jul 2003 05:17:37 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3356161B9E; Mon, 21 Jul 2003 11:17:09 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from sentosa.post1.com (sentosa.post1.com [202.27.17.100]) by eikenes.alvestrand.no (Postfix) with SMTP id 13C1161B9C for ; Mon, 21 Jul 2003 11:17:06 +0200 (CEST) Received: (qmail 69312 invoked from network); 21 Jul 2003 09:21:56 -0000 Received: from bb220-255-119-238.singnet.com.sg (HELO pobox.org.sg) (220.255.119.238) by sentosa.post1.com with SMTP; 21 Jul 2003 09:21:56 -0000 Message-ID: <3F1BAF80.3010506@pobox.org.sg> Date: Mon, 21 Jul 2003 17:16:48 +0800 From: James Seng User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en, zh-cn, zh-tw, ja, ko MIME-Version: 1.0 To: todd glassey References: <20030718143540.324c7ab7.moore@cs.utk.edu><7C1FF869-B9DB-11D7-8554-00039388672E@muada.com> <20030719093851.37135aa8.moore@cs.utk.edu> <034b01c34e01$80ac5fa0$020aff0a@tsg1> <3F196AD8.1070107@pobox.org.sg> <06b301c34eec$71b128f0$020aff0a@tsg1> In-Reply-To: <06b301c34eec$71b128f0$020aff0a@tsg1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no, Keith Moore , "Contreras, Jorge" Subject: Re: The IETF's problems X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit > No James you cannot. You can decide what you personally want to work on but > the instant you try and stop someone elses initiative you become a legal > problem to the organization. The ISTE is not your personal resource, in fact > the vetting resource is not the IETF's at all. It belongsx to the > participants, and any refusal to allow any protocol or submission in is a > problem. We (as in IETF) can decide what we want to do or not, like it or not, as a group. If someone comes along and say they have a solution for world hunger and wants to publish it as an RFC, we will tell them "go away". Proposals not accepted in IETF can seek out other groups or they are free to deploy it anyway. IETF could not and will not step them. It is not a legal problem. -James Seng From problem-statement-bounces@alvestrand.no Mon Jul 21 09:12:02 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26471 for ; Mon, 21 Jul 2003 09:12:01 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E929F61BEE; Mon, 21 Jul 2003 15:11:32 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from znsgs01r.nortelnetworks.com (h33s128a211n47.user.nortelnetworks.com [47.211.128.33]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5F4D261BED for ; Mon, 21 Jul 2003 15:11:31 +0200 (CEST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.160.46.124]) by znsgs01r.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h6LDBEZ00970; Mon, 21 Jul 2003 14:11:14 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 21 Jul 2003 14:11:15 +0100 Message-ID: <4103264BC8D3D51180B7002048400C4501623581@zhard0jd.europe.nortel.com> From: "Elwyn Davies" To: "'Melinda Shore'" , Iljitsch van Beijnum Date: Mon, 21 Jul 2003 14:11:13 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C34F89.8F674710" Cc: problem-statement@alvestrand.no Subject: RE: The IETF's problems X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C34F89.8F674710 Content-Type: text/plain; charset="iso-8859-1" I agree with Melinda. If you want something altered or included in the problem statement draft, the combattants on this thread are going to have to state clearly how they would like the text altered. I have not yet seen anything that actually significantly enhances the arguments in the current draft - I believe that Iljitsch's initial comments are actually all covered by the existing text in one way or another. I do not believe that having or not having three short windows in which drafts cannot be submitted could be considered a 'root cause problem'. IMHO, it is a useful deadline which concentrates the mind(s) of authors and editorial teams towards actually getting something out there in a reasonably timely fashion, and gives the victims who have to read the flood of words some chance of being uptodate with what has been written by the time it is discussed in the f2f meetings. Given the percentage of people who do seem to read most drafts, anything that helps with this is highly desirable. I await some well-honed text! Regards, Elwyn > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: 20 July 2003 18:29 > To: Iljitsch van Beijnum > Cc: problem-statement@alvestrand.no > Subject: Re: The IETF's problems > > > > This is a prime example of the topic of this list: the IETF > is unable > > to determine what it should work on and what it shouldn't > work on in a > > satisfactory way. > > The discussion itself isn't doing much to distill the topic > down to document text, and we need to stay focused. Do you > feel that existing text regarding scope in the problem > statement document is inadequate? > > Thanks, > > Melinda > ------_=_NextPart_001_01C34F89.8F674710 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: The IETF's problems

I agree with Melinda.

If you want something altered or included in the = problem statement draft, the combattants on this thread are going to = have to state clearly how they would like the text altered.  I = have not yet seen anything that actually significantly enhances the = arguments in the current draft - I believe that Iljitsch's initial = comments are actually all covered by the existing text in one way or = another.

I do not believe that having or not having three = short windows in which drafts cannot be submitted could be considered a = 'root cause problem'.  IMHO, it is a useful deadline which = concentrates the mind(s) of authors and editorial teams towards = actually getting something out there in a reasonably timely fashion, = and gives the victims who have to read the flood of words some chance = of being uptodate with what has been written by the time it is = discussed in the f2f meetings.   Given the percentage of = people who do seem to read most drafts, anything that helps with this = is highly desirable.

I await some well-honed text!

Regards,
Elwyn

> -----Original Message-----
> From: Melinda Shore [mailto:mshore@cisco.com]
> Sent: 20 July 2003 18:29
> To: Iljitsch van Beijnum
> Cc: problem-statement@alvestrand.no
> Subject: Re: The IETF's problems
>
>
> > This is a prime example of the topic of = this list: the IETF
> is unable
> > to determine what it should work on and = what it shouldn't
> work on in a
> > satisfactory way.
>
> The discussion itself isn't doing much to = distill the topic
> down to document text, and we need to stay = focused.  Do you
> feel that existing text regarding scope in the = problem
> statement document is inadequate?
>
> Thanks,
>
> Melinda
>

------_=_NextPart_001_01C34F89.8F674710-- From problem-statement-bounces@alvestrand.no Mon Jul 21 11:31:32 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00865 for ; Mon, 21 Jul 2003 11:31:30 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id EBCA861BED; Mon, 21 Jul 2003 17:31:01 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by eikenes.alvestrand.no (Postfix) with ESMTP id CDC6D61B9C for ; Mon, 21 Jul 2003 17:30:59 +0200 (CEST) Received: from tsg1 (154.sanjose-06-07rs16rt.ca.dial-access.att.net[12.81.2.154]) by mtiwmhc12.worldnet.att.net (mtiwmhc12) with SMTP id <2003072115305511200lmuj8e>; Mon, 21 Jul 2003 15:30:56 +0000 Message-ID: <009401c34f9d$04a4e100$020aff0a@tsg1> From: "todd glassey" To: "Elwyn Davies" , "'Melinda Shore'" , "Iljitsch van Beijnum" References: <4103264BC8D3D51180B7002048400C4501623581@zhard0jd.europe.nortel.com> Date: Mon, 21 Jul 2003 08:27:56 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_007B_01C34F61.FC753E70" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Cc: problem-statement@alvestrand.no Subject: Re: The IETF's problems X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no This is a multi-part message in MIME format. ------=_NextPart_000_007B_01C34F61.FC753E70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: The IETF's problemsElwyn and Melinda ----- Original Message -----=20 From: Elwyn Davies=20 To: 'Melinda Shore' ; Iljitsch van Beijnum=20 Cc: problem-statement@alvestrand.no=20 Sent: Monday, July 21, 2003 6:11 AM Subject: RE: The IETF's problems=20 I agree with Melinda.=20 If you want something altered or included in the problem statement = draft, the combattants on this thread are going to have to state clearly = how they would like the text altered. I have not yet seen anything that = actually significantly enhances the arguments in the current draft - I = believe that Iljitsch's initial comments are actually all covered by the = existing text in one way or another. Internet Draft Filing process There are several perceptual problems with the filing of Internet Drafts = that must be normalized across the entire IETF in order to meet the = requirements of being fair to all. As well as being open to all = submissions. The first of these is that No I-D can be refused publication since its = purpose is to solicit the creation of a vetting group and to create a = formal initiative. With the current process for introducing a technology = to the IETF, that is filing an I-D, no I-D's filed can be supressed for = any reasons except improper IP releases against them. No other = justifications are reasonable and in fact constitiute a restraint of = someone's abilities to create an initiative creating an adversarial role = for the IETF itself. The Second issue here is that likewise, no Working Group can refuse the = Publication of a I-D to it as a proposal to create a vetting team and = run the vetting as a formal initiative within the IETF. This also = constitutes a restraint of trade in the form of quashing critical = business development in the form of creating Industry Standards. I do not believe that having or not having three short windows in = which drafts cannot be submitted could be considered a 'root cause = problem'. =20 I do - It has to do with whether the publishing team is the publishing = team or not. It seems that they have other roles as well and may not be = available to manage the publishing efforts during meetings, and that's = fine, but there is no reason to bounce any filings or throw them away = becuase the I-D team is busy elsewhere. Its reasonable with modern = technology to allow them to sit there while the IETF meeting is in pro, = no matter what is going on in the IETF (meeting in progress or not).=20 IETF meeting Agenda's obviously have a cut-off date, but that is = relative to the periodic meetings only regarding consideration in that = meeting itself, and should have no impact on the filing of the I-D = itself. It is fine to tell people that the IETF's publishing team is = elsewise engaged during a meeting but to make people refile them. IMHO, it is a useful deadline which concentrates the mind(s) of = authors and editorial teams towards actually getting something out there = in a reasonably timely fashion, and gives the victims who have to read = the flood of words some chance of being uptodate with what has been = written by the time it is discussed in the f2f meetings. =20 This is already addressed by the "dropdead" date for inclusion in the = Meeting Agenda's... Nothing else is needed to satisfy this requirement. Given the percentage of people who do seem to read most drafts, = anything that helps with this is highly desirable. I await some well-honed text!=20 Regards,=20 Elwyn=20 > -----Original Message-----=20 > From: Melinda Shore [mailto:mshore@cisco.com]=20 > Sent: 20 July 2003 18:29=20 > To: Iljitsch van Beijnum=20 > Cc: problem-statement@alvestrand.no=20 > Subject: Re: The IETF's problems=20 >=20 >=20 > > This is a prime example of the topic of this list: the IETF=20 > is unable=20 > > to determine what it should work on and what it shouldn't=20 > work on in a=20 > > satisfactory way.=20 Which is why the IETF has no real say in what it works on. The IETF is = not a political or commercial lobby. It is a standards platform with a = practice model. >=20 > The discussion itself isn't doing much to distill the topic=20 > down to document text, and we need to stay focused. Do you=20 > feel that existing text regarding scope in the problem=20 > statement document is inadequate?=20 >=20 > Thanks,=20 >=20 > Melinda=20 >=20 ------=_NextPart_000_007B_01C34F61.FC753E70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: The IETF's problems
Elwyn and Melinda
----- Original Message -----
From:=20 Elwyn Davies
To: 'Melinda Shore' ; Iljitsch = van=20 Beijnum
Cc: problem-statement@alvestr= and.no=20
Sent: Monday, July 21, 2003 = 6:11 AM
Subject: RE: The IETF's = problems

I agree with Melinda.

If you want something altered or included in the = problem=20 statement draft, the combattants on this thread are going to have to = state=20 clearly how they would like the text altered.  I have not yet = seen=20 anything that actually significantly enhances the arguments in the = current=20 draft - I believe that Iljitsch's initial comments are actually all = covered by=20 the existing text in one way or another.

 

Internet Draft Filing process

There are several perceptual problems with = the filing of=20 Internet Drafts that must be normalized across the entire IETF in order = to meet=20 the requirements of being fair to all. As well as being open to all=20 submissions.

The first of these is that No I-D can be = refused=20 publication since its purpose is to solicit the creation of a vetting = group and=20 to create a formal initiative. With the current process for introducing = a=20 technology to the IETF, that is filing an I-D, no I-D's filed can be = supressed=20 for any reasons except improper IP releases against them. No other=20 justifications are reasonable and in fact constitiute a restraint of = someone's=20 abilities to create an initiative creating an adversarial role for the = IETF=20 itself.

The Second issue here is that likewise, no = Working Group=20 can refuse the Publication of a I-D to it as a proposal to create a = vetting team=20 and run the vetting as a formal initiative within the IETF. This also=20 constitutes a restraint of trade in the form of quashing critical = business=20 development in the form of creating Industry Standards.

I do not believe that having or not having three = short windows=20 in which drafts cannot be submitted could be considered a 'root cause=20 problem'. 

I do - It has to do with = whether the=20 publishing team is the publishing team or not. It seems that they have = other=20 roles as well and may not be available to manage the publishing efforts = during=20 meetings, and that's fine, but there is no reason to bounce any filings = or throw=20 them away becuase the I-D team is busy elsewhere. Its reasonable with = modern=20 technology to allow them to sit there while the IETF meeting is in pro, = no=20 matter what is going on in the IETF (meeting in progress or not). =

IETF meeting Agenda's obviously=20 have a cut-off date, but that is relative to the periodic meetings only=20 regarding consideration in that meeting itself, and should have no = impact on the=20 filing of the I-D itself. It is fine to tell people that the IETF's = publishing team is elsewise engaged during a meeting but to make people = refile=20 them.

IMHO, it is a useful deadline which concentrates the = mind(s)=20 of authors and editorial teams towards actually getting something out = there in=20 a reasonably timely fashion, and gives the victims who have to read = the flood=20 of words some chance of being uptodate with what has been written by = the time=20 it is discussed in the f2f meetings.   =

This is already addressed by the "dropdead" = date for=20 inclusion in the Meeting Agenda's... Nothing else is needed to satisfy = this=20 requirement.

Given the percentage of people who do seem to read = most=20 drafts, anything that helps with this is highly desirable.

I await some well-honed text!

Regards,
Elwyn

> -----Original Message-----
>=20 From: Melinda Shore [mailto:mshore@cisco.com] =
> Sent: 20 July 2003 18:29
> = To: Iljitsch=20 van Beijnum
> Cc:=20 problem-statement@alvestrand.no
> = Subject: Re: The=20 IETF's problems
>
>=20
> > This is a prime example of the = topic of this=20 list: the IETF
> is unable =
> > to determine what it should work on and what it = shouldn't=20
> work on in a
> >=20 satisfactory way.

Which is why the IETF has no real say = in what it=20 works on. The IETF is not a political or commercial lobby. It is a = standards=20 platform with a practice model.


>
> The discussion itself isn't = doing much=20 to distill the topic
> down to document = text, and we=20 need to stay focused.  Do you
> feel = that=20 existing text regarding scope in the problem
>=20 statement document is inadequate?
> =
> Thanks,
>
>=20 Melinda
>

------=_NextPart_000_007B_01C34F61.FC753E70-- From problem-statement-bounces@alvestrand.no Mon Jul 21 11:31:41 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00885 for ; Mon, 21 Jul 2003 11:31:40 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C5E6561BF5; Mon, 21 Jul 2003 17:31:13 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by eikenes.alvestrand.no (Postfix) with ESMTP id 76EC361B9C for ; Mon, 21 Jul 2003 17:31:01 +0200 (CEST) Received: from tsg1 (154.sanjose-06-07rs16rt.ca.dial-access.att.net[12.81.2.154]) by mtiwmhc12.worldnet.att.net (mtiwmhc12) with SMTP id <2003072115305911200lmuj9e>; Mon, 21 Jul 2003 15:31:00 +0000 Message-ID: <009501c34f9d$06c046f0$020aff0a@tsg1> From: "todd glassey" To: "James Seng" , References: <20030718143540.324c7ab7.moore@cs.utk.edu><7C1FF869-B9DB-11D7-8554-00039388672E@muada.com> <20030719093851.37135aa8.moore@cs.utk.edu> <034b01c34e01$80ac5fa0$020aff0a@tsg1> <3F196AD8.1070107@pobox.org.sg> <06b301c34eec$71b128f0$020aff0a@tsg1> <3F1BAF80.3010506@pobox.org.sg> Date: Mon, 21 Jul 2003 08:30:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: Re: The IETF's problems X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit James - you have illustrated one of the key problems facing the IETF and that is that it is NOT a fair and open platform for standards processes. todd ----- Original Message ----- From: "James Seng" To: "todd glassey" Cc: "Contreras, Jorge" ; "Keith Moore" ; "Iljitsch van Beijnum" ; Sent: Monday, July 21, 2003 2:16 AM Subject: Re: The IETF's problems > > No James you cannot. You can decide what you personally want to work on but > > the instant you try and stop someone else's initiative you become a legal > > problem to the organization. The IETF is not your personal resource, in fact > > the vetting resource is not the IETF's at all. It belongs to the > > participants, and any refusal to allow any protocol or submission in is a > > problem. > > We (as in IETF) can decide what we want to do or not, like it or not, as > a group. If someone comes along and say they have a solution for world > hunger and wants to publish it as an RFC, we will tell them "go away". > > Proposals not accepted in IETF can seek out other groups or they are > free to deploy it anyway. IETF could not and will not step them. It is > not a legal problem. > > -James Seng > From problem-statement-bounces@alvestrand.no Mon Jul 21 11:39:58 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01098 for ; Mon, 21 Jul 2003 11:39:57 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7BD1261BED; Mon, 21 Jul 2003 17:39:29 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from sentosa.post1.com (sentosa.post1.com [202.27.17.100]) by eikenes.alvestrand.no (Postfix) with SMTP id 9814761B9E for ; Mon, 21 Jul 2003 17:39:26 +0200 (CEST) Received: (qmail 74931 invoked from network); 21 Jul 2003 15:44:17 -0000 Received: from bb220-255-119-238.singnet.com.sg (HELO pobox.org.sg) (220.255.119.238) by sentosa.post1.com with SMTP; 21 Jul 2003 15:44:17 -0000 Message-ID: <3F1C091F.70904@pobox.org.sg> Date: Mon, 21 Jul 2003 23:39:11 +0800 From: James Seng User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en, zh-cn, zh-tw, ja, ko MIME-Version: 1.0 To: todd glassey References: <20030718143540.324c7ab7.moore@cs.utk.edu><7C1FF869-B9DB-11D7-8554-00039388672E@muada.com> <20030719093851.37135aa8.moore@cs.utk.edu> <034b01c34e01$80ac5fa0$020aff0a@tsg1> <3F196AD8.1070107@pobox.org.sg> <06b301c34eec$71b128f0$020aff0a@tsg1> <3F1BAF80.3010506@pobox.org.sg> <009501c34f9d$06c046f0$020aff0a@tsg1> In-Reply-To: <009501c34f9d$06c046f0$020aff0a@tsg1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: The IETF's problems X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit RFC for world hunger? of course not! the only time you actually going to see an RFC for world hunger is probably on 1st April. Maybe you can try world hunger problem in OASIS? They were suppose to be "fair and open platform". james todd glassey wrote: > James - you have illustrated one of the key problems facing the IETF and > that is that it is NOT a fair and open platform for standards processes. > > todd > ----- Original Message ----- > From: "James Seng" > To: "todd glassey" > Cc: "Contreras, Jorge" ; "Keith Moore" > ; "Iljitsch van Beijnum" ; > > Sent: Monday, July 21, 2003 2:16 AM > Subject: Re: The IETF's problems > > > >>>No James you cannot. You can decide what you personally want to work on > > but > >>>the instant you try and stop someone else's initiative you become a > > legal > >>>problem to the organization. The IETF is not your personal resource, in > > fact > >>>the vetting resource is not the IETF's at all. It belongs to the >>>participants, and any refusal to allow any protocol or submission in is > > a > >>>problem. >> >>We (as in IETF) can decide what we want to do or not, like it or not, as >>a group. If someone comes along and say they have a solution for world >>hunger and wants to publish it as an RFC, we will tell them "go away". >> >>Proposals not accepted in IETF can seek out other groups or they are >>free to deploy it anyway. IETF could not and will not step them. It is >>not a legal problem. >> >>-James Seng >> > > > > From problem-statement-bounces@alvestrand.no Mon Jul 21 12:07:55 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02044 for ; Mon, 21 Jul 2003 12:07:55 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2A84161BED; Mon, 21 Jul 2003 18:07:27 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8624961B9E for ; Mon, 21 Jul 2003 18:07:25 +0200 (CEST) Received: from cisco.com (171.68.223.137) by sj-iport-2.cisco.com with ESMTP; 21 Jul 2003 09:07:59 -0700 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h6LG7NuG028927; Mon, 21 Jul 2003 09:07:23 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJU88625; Mon, 21 Jul 2003 09:07:21 -0700 (PDT) Message-Id: <200307211607.AJU88625@mira-sjc5-c.cisco.com> To: "todd glassey" From: Melinda Shore In-Reply-To: Message from todd.glassey@worldnet.att.net of "Mon, 21 Jul 2003 08:30:24 PDT." <009501c34f9d$06c046f0$020aff0a@tsg1> Date: Mon, 21 Jul 2003 12:07:21 -0400 Cc: James Seng , problem-statement@alvestrand.no Subject: Re: The IETF's problems X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Todd - This working group and this mailing list exist to execute two specific pieces of work. It is not a general forum for griping about the IETF. This is your second warning today (the first being Avri's). Everybody else - please exercise some judgment about becoming involved with off-topic discussions. Melinda From problem-statement-bounces@alvestrand.no Tue Jul 22 09:35:36 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13014 for ; Tue, 22 Jul 2003 09:35:35 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A287261B98; Tue, 22 Jul 2003 15:35:06 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from sequoia.muada.com (sequoia.muada.com [213.156.1.123]) by eikenes.alvestrand.no (Postfix) with ESMTP id 401B261B93 for ; Tue, 22 Jul 2003 15:35:05 +0200 (CEST) Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h6MDZgxS041758; Tue, 22 Jul 2003 15:35:43 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Tue, 22 Jul 2003 15:35:06 +0200 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) To: Melinda Shore From: Iljitsch van Beijnum In-Reply-To: <200307201728.AJU33161@mira-sjc5-c.cisco.com> Message-Id: <4E535D0E-BC49-11D7-974F-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Cc: problem-statement@alvestrand.no Subject: Re: The IETF's problems X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit On zondag, jul 20, 2003, at 19:28 Europe/Amsterdam, Melinda Shore wrote: > The discussion itself isn't doing much to distill the topic > down to document text, and we need to stay focused. Do you > feel that existing text regarding scope in the problem > statement document is inadequate? Not sure what you mean by scope. However, many of the "root" problems in the problems draft aren't that fundamental. The three most fundamental problems I see are: - the IETF doesn't know what it wants to be: a "real" standards organization or some kind of a grass roots movement - inability to make decisions other than just wait until there is agreement or come up with convoluted processes that only work because people are forced to interact until they somehow solve the problem - inability to manage resources effectively and efficiently Iljitsch From problem-statement-bounces@alvestrand.no Tue Jul 22 11:47:50 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17849 for ; Tue, 22 Jul 2003 11:47:50 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E6BDA61B98; Tue, 22 Jul 2003 17:47:20 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from mtiwmhc11.worldnet.att.net (mtiwmhc11.worldnet.att.net [204.127.131.115]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2074761B92 for ; Tue, 22 Jul 2003 17:47:19 +0200 (CEST) Received: from tsg1 (206.sanjose-06-07rs16rt.ca.dial-access.att.net[12.81.2.206]) by mtiwmhc11.worldnet.att.net (mtiwmhc11) with SMTP id <20030722154715111008g1p0e>; Tue, 22 Jul 2003 15:47:16 +0000 Message-ID: <0c8f01c35068$7177e6d0$020aff0a@tsg1> From: "todd glassey" To: "Melinda Shore" , "Iljitsch van Beijnum" References: <4E535D0E-BC49-11D7-974F-00039388672E@muada.com> Date: Tue, 22 Jul 2003 08:20:21 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Cc: problem-statement@alvestrand.no Subject: Re: The IETF's problems X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Melinda - All - I have a question, and that is "do you consider the IETF's not formally allowing more than one standard track item per/WG per/initiative-scope" a problem?, because I do, and I consider it a serious one at that. What I am referring to is the fundamental issue of whether WG's should be allowed to limit the number of initiatives on any one track to one, and my take is that the answer here is NO. My reasons for asking this are that RFC2026 and 2223 as well as 2418 all talk about the scope and process of the standards model, but none of them really have any process for one effort to supersede another unless that effort is done by the people "owning" that spot originally. There are no "hostile takeover guidelines" or processes, and that means that any evolution of challenge of a commercially used protocol has to have the blessings of the WG Chair and those that already own that standing in a WG (This of course pertains to existing protocols predominantly). So look - here is an example, Say I have a protocol for "Whiz-Banging" and there is already a protocol on track inside a WG that Whiz-Bangs but in a different manner. So the question is whether the IETF can support two or more Whiz-Banging implementations, or only one, because if the answer is "only one" then we need to also have a method for how would anyone introduce the second Whiz-Banging protocol to the IETF to compete with the other? The problem is that the answer is today that functionally that this will never happen. And it is because it is very very unlikely that the folks with their Whiz-Banging Protocol are going to want to roll-over and die... So then what happens??? The challenging Whiz-Banger is submitted to the I-D staff as a disclosure. The I-D staff go to the WG Chair who makes a judgment that they will not allow that protocol to harm the one that has already gotten investment from them and the others in their WG, so now the WG Chair takes an active role in suppressing the challenging effort. But say the I-D issues get past the WG Chair, so then perhaps with the current model the I-D staff also decide that they don't want to publish this draft because it competes with an already in-process or existing standard or standards-track participant. So this is yet another hurdle to publication and an issue. So now they as well are part of a restraint of trade development process as well. So the question simply is where does this end? Just how does the IETF allow for a competitive effort, since anything else seems to have serious legal issues with restraint of market development (the building of standards is a key part of this). Or is this just not of importance to this IETF? Todd Glassey ----- Original Message ----- From: "Iljitsch van Beijnum" To: "Melinda Shore" Cc: Sent: Tuesday, July 22, 2003 6:35 AM Subject: Re: The IETF's problems > On zondag, jul 20, 2003, at 19:28 Europe/Amsterdam, Melinda Shore wrote: > > > The discussion itself isn't doing much to distill the topic > > down to document text, and we need to stay focused. Do you > > feel that existing text regarding scope in the problem > > statement document is inadequate? > > Not sure what you mean by scope. > > However, many of the "root" problems in the problems draft aren't that > fundamental. The three most fundamental problems I see are: > > - the IETF doesn't know what it wants to be: a "real" standards > organization or some kind of a grass roots movement > - inability to make decisions other than just wait until there is > agreement or come up with convoluted processes that only work because > people are forced to interact until they somehow solve the problem > - inability to manage resources effectively and efficiently > > Iljitsch > From problem-statement-bounces@alvestrand.no Tue Jul 22 12:21:30 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18771 for ; Tue, 22 Jul 2003 12:21:30 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id AFD4261B9B; Tue, 22 Jul 2003 18:21:01 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1963C61B98 for ; Tue, 22 Jul 2003 18:21:00 +0200 (CEST) Received: from dfnjgl21 (autoimage.com[216.62.6.129](untrusted sender)) by comcast.net (sccrmhc12) with SMTP id <20030722162058012000u3d1e> (Authid: sdawkins@comcast.net); Tue, 22 Jul 2003 16:20:58 +0000 Message-ID: <006c01c3506d$3c196360$8100000a@DFNJGL21> From: "Spencer Dawkins" To: References: <4E535D0E-BC49-11D7-974F-00039388672E@muada.com> <0c8f01c35068$7177e6d0$020aff0a@tsg1> Date: Tue, 22 Jul 2003 11:20:43 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: Re: The IETF's problems X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list Reply-To: Spencer Dawkins List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Ummm, but we DO have competing documents. I think we're more likely to do them in parallel working groups (see IMPP/SIMPLE/XMPP for running code), and that's probably better anyway (less mud-slinging within a working group), but don't even START on how many IPv6 transition mechanisms we have, or how many MANETs we have, or ... Spencer ----- Original Message ----- From: "todd glassey" To: "Melinda Shore" ; "Iljitsch van Beijnum" Cc: Sent: Tuesday, July 22, 2003 10:20 AM Subject: Re: The IETF's problems > Melinda - All - > I have a question, and that is "do you consider the IETF's not formally > allowing more than one standard track item per/WG per/initiative-scope" a > problem?, because I do, and I consider it a serious one at that. What I am > referring to is the fundamental issue of whether WG's should be allowed to > limit the number of initiatives on any one track to one, and my take is that > the answer here is NO. > > My reasons for asking this are that RFC2026 and 2223 as well as 2418 all > talk about the scope and process of the standards model, but none of them > really have any process for one effort to supersede another unless that > effort is done by the people "owning" that spot originally. There are no > "hostile takeover guidelines" or processes, and that means that any > evolution of challenge of a commercially used protocol has to have the > blessings of the WG Chair and those that already own that standing in a WG > (This of course pertains to existing protocols predominantly). > > So look - here is an example, Say I have a protocol for "Whiz-Banging" and > there is already a protocol on track inside a WG that Whiz-Bangs but in a > different manner. So the question is whether the IETF can support two or > more Whiz-Banging implementations, or only one, because if the answer is > "only one" then we need to also have a method for how would anyone introduce > the second Whiz-Banging protocol to the IETF to compete with the other? > > The problem is that the answer is today that functionally that this will > never happen. And it is because it is very very unlikely that the folks with > their Whiz-Banging Protocol are going to want to roll-over and die... > > So then what happens??? The challenging Whiz-Banger is submitted to the I-D > staff as a disclosure. The I-D staff go to the WG Chair who makes a judgment > that they will not allow that protocol to harm the one that has already > gotten investment from them and the others in their WG, so now the WG Chair > takes an active role in suppressing the challenging effort. But say the I-D > issues get past the WG Chair, so then perhaps with the current model the I-D > staff also decide that they don't want to publish this draft because it > competes with an already in-process or existing standard or standards-track > participant. So this is yet another hurdle to publication and an issue. So > now they as well are part of a restraint of trade development process as > well. > > So the question simply is where does this end? Just how does the IETF allow > for a competitive effort, since anything else seems to have serious legal > issues with restraint of market development (the building of standards is a > key part of this). Or is this just not of importance to this IETF? > > Todd Glassey > ----- Original Message ----- > From: "Iljitsch van Beijnum" > To: "Melinda Shore" > Cc: > Sent: Tuesday, July 22, 2003 6:35 AM > Subject: Re: The IETF's problems > > > > On zondag, jul 20, 2003, at 19:28 Europe/Amsterdam, Melinda Shore wrote: > > > > > The discussion itself isn't doing much to distill the topic > > > down to document text, and we need to stay focused. Do you > > > feel that existing text regarding scope in the problem > > > statement document is inadequate? > > > > Not sure what you mean by scope. > > > > However, many of the "root" problems in the problems draft aren't that > > fundamental. The three most fundamental problems I see are: > > > > - the IETF doesn't know what it wants to be: a "real" standards > > organization or some kind of a grass roots movement > > - inability to make decisions other than just wait until there is > > agreement or come up with convoluted processes that only work because > > people are forced to interact until they somehow solve the problem > > - inability to manage resources effectively and efficiently > > > > Iljitsch > > > From problem-statement-bounces@alvestrand.no Tue Jul 22 12:46:45 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19249 for ; Tue, 22 Jul 2003 12:46:45 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D347161B9C; Tue, 22 Jul 2003 18:46:16 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from mtiwmhc13.worldnet.att.net (mtiwmhc13.worldnet.att.net [204.127.131.117]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3841F61B9B for ; Tue, 22 Jul 2003 18:46:15 +0200 (CEST) Received: from tsg1 (206.sanjose-06-07rs16rt.ca.dial-access.att.net[12.81.2.206]) by mtiwmhc13.worldnet.att.net (mtiwmhc13) with SMTP id <2003072216461211300m8unbe>; Tue, 22 Jul 2003 16:46:12 +0000 Message-ID: <0cc601c35070$acbd1d20$020aff0a@tsg1> From: "todd glassey" To: "Spencer Dawkins" , References: <4E535D0E-BC49-11D7-974F-00039388672E@muada.com><0c8f01c35068$7177e6d0$020aff0a@tsg1> <006c01c3506d$3c196360$8100000a@DFNJGL21> Date: Tue, 22 Jul 2003 09:45:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: Re: The IETF's problems X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit The problem is that this is not consistent across all WG's - And AD's are really the last word still on whether a competitive WG was created. What I am trying to illustrate here Spencer is that the really fair process involves creating an initiative based on the ability to field a team of vetting resources. So if there is a WG that has 200 people subscribed to it, how many of then actually work on any given initiative? the numbers will surprise you and the list archive bears all this out. The real issue is then creating a formal requirement for all WG's to participate in the process equally and allow for any number of initiatives as long as the work gets done. Todd ----- Original Message ----- From: "Spencer Dawkins" To: Sent: Tuesday, July 22, 2003 9:20 AM Subject: Re: The IETF's problems > Ummm, but we DO have competing documents. I think we're more likely > to do them in parallel working groups (see IMPP/SIMPLE/XMPP for > running code), and that's probably better anyway (less mud-slinging > within a working group), but don't even START on how many IPv6 > transition mechanisms we have, or how many MANETs we have, or ... > > Spencer > > ----- Original Message ----- > From: "todd glassey" > To: "Melinda Shore" ; "Iljitsch van Beijnum" > > Cc: > Sent: Tuesday, July 22, 2003 10:20 AM > Subject: Re: The IETF's problems > > > > Melinda - All - > > I have a question, and that is "do you consider the IETF's not formally > > allowing more than one standard track item per/WG per/initiative-scope" a > > problem?, because I do, and I consider it a serious one at that. What I am > > referring to is the fundamental issue of whether WG's should be allowed to > > limit the number of initiatives on any one track to one, and my take is > that > > the answer here is NO. > > > > My reasons for asking this are that RFC2026 and 2223 as well as 2418 all > > talk about the scope and process of the standards model, but none of them > > really have any process for one effort to supersede another unless that > > effort is done by the people "owning" that spot originally. There are no > > "hostile takeover guidelines" or processes, and that means that any > > evolution of challenge of a commercially used protocol has to have the > > blessings of the WG Chair and those that already own that standing in a WG > > (This of course pertains to existing protocols predominantly). > > > > So look - here is an example, Say I have a protocol for "Whiz-Banging" and > > there is already a protocol on track inside a WG that Whiz-Bangs but in a > > different manner. So the question is whether the IETF can support two or > > more Whiz-Banging implementations, or only one, because if the answer is > > "only one" then we need to also have a method for how would anyone > introduce > > the second Whiz-Banging protocol to the IETF to compete with the other? > > > > The problem is that the answer is today that functionally that this will > > never happen. And it is because it is very very unlikely that the folks > with > > their Whiz-Banging Protocol are going to want to roll-over and die... > > > > So then what happens??? The challenging Whiz-Banger is submitted to the > I-D > > staff as a disclosure. The I-D staff go to the WG Chair who makes a > judgment > > that they will not allow that protocol to harm the one that has already > > gotten investment from them and the others in their WG, so now the WG > Chair > > takes an active role in suppressing the challenging effort. But say the > I-D > > issues get past the WG Chair, so then perhaps with the current model the > I-D > > staff also decide that they don't want to publish this draft because it > > competes with an already in-process or existing standard or > standards-track > > participant. So this is yet another hurdle to publication and an issue. So > > now they as well are part of a restraint of trade development process as > > well. > > > > So the question simply is where does this end? Just how does the IETF > allow > > for a competitive effort, since anything else seems to have serious legal > > issues with restraint of market development (the building of standards is > a > > key part of this). Or is this just not of importance to this IETF? > > > > Todd Glassey > > ----- Original Message ----- > > From: "Iljitsch van Beijnum" > > To: "Melinda Shore" > > Cc: > > Sent: Tuesday, July 22, 2003 6:35 AM > > Subject: Re: The IETF's problems > > > > > > > On zondag, jul 20, 2003, at 19:28 Europe/Amsterdam, Melinda Shore wrote: > > > > > > > The discussion itself isn't doing much to distill the topic > > > > down to document text, and we need to stay focused. Do you > > > > feel that existing text regarding scope in the problem > > > > statement document is inadequate? > > > > > > Not sure what you mean by scope. > > > > > > However, many of the "root" problems in the problems draft aren't that > > > fundamental. The three most fundamental problems I see are: > > > > > > - the IETF doesn't know what it wants to be: a "real" standards > > > organization or some kind of a grass roots movement > > > - inability to make decisions other than just wait until there is > > > agreement or come up with convoluted processes that only work because > > > people are forced to interact until they somehow solve the problem > > > - inability to manage resources effectively and efficiently > > > > > > Iljitsch > > > > > > From problem-statement-bounces@alvestrand.no Tue Jul 22 13:01:36 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19670 for ; Tue, 22 Jul 2003 13:01:36 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id AE80261B9E; Tue, 22 Jul 2003 19:01:08 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from sequoia.muada.com (sequoia.muada.com [213.156.1.123]) by eikenes.alvestrand.no (Postfix) with ESMTP id F363C61B9C for ; Tue, 22 Jul 2003 19:01:07 +0200 (CEST) Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h6MH1kxS043968; Tue, 22 Jul 2003 19:01:46 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Tue, 22 Jul 2003 19:01:05 +0200 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) To: "todd glassey" From: Iljitsch van Beijnum In-Reply-To: <0cc601c35070$acbd1d20$020aff0a@tsg1> Message-Id: <1535EBDC-BC66-11D7-974F-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Cc: problem-statement@alvestrand.no Subject: Re: The IETF's problems X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit On dinsdag, jul 22, 2003, at 18:45 Europe/Amsterdam, todd glassey wrote: > The problem is that this is not consistent across all WG's - And AD's > are > really the last word still on whether a competitive WG was created. [...] > The real issue is then creating a formal requirement for all WG's to > participate in the process equally and allow for any number of > initiatives > as long as the work gets done. What I don't get is why the IESG should be involved in managing the wgs in the first place. > ----- Original Message ----- > From: "Spencer Dawkins" > To: > Sent: Tuesday, July 22, 2003 9:20 AM > Subject: Re: The IETF's problems And as long as we're talking about problems: what is this "let's repeat everyhting I'm replying to verbatim" nonsens all about? I feel like I'm emailing with a bunch of three year olds that have been online for all of five minutes sometimes. From problem-statement-bounces@alvestrand.no Tue Jul 22 18:03:33 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27892 for ; Tue, 22 Jul 2003 18:03:32 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E35C161B94; Wed, 23 Jul 2003 00:03:03 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by eikenes.alvestrand.no (Postfix) with ESMTP id 194D561B92 for ; Wed, 23 Jul 2003 00:03:01 +0200 (CEST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h6MM2wQk024900 for ; Tue, 22 Jul 2003 15:02:58 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJW87618; Tue, 22 Jul 2003 15:02:57 -0700 (PDT) Message-Id: <200307222202.AJW87618@mira-sjc5-c.cisco.com> To: problem-statement@alvestrand.no From: Melinda Shore Date: Tue, 22 Jul 2003 18:02:57 -0400 Subject: A few hums X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Full meeting minutes should be out by the end of the week, but in the meantime you all should be aware of some hums that were taken and their outcomes, and we need to get those ratified and turned into decisions on this mailing list. In the discussion of timeliness, we asked for a hum whether or not the current text in section 2.1 of the problem statement document is adequate. The hum was positive (the text is adequate). In the discussion of ADs who function as WG chairs, we asked whether this was adequately covered in section 2.6.6 of the problem statement document. The hum indicated that those present feel that it is. In the discussion of the IETF's scope, the question was whether or not the existing text in the problem statement document sufficiently addressed the issue. The hum indicated that those present felt it does. In the discussion of whether or not there's a problem accomodating ESL speakers, the discussion broadened a bit to cover cultural issues, the hum indicated that those present felt that we needed more text on this issue. In the discussion of whether or not the existing IETF document format is a problem, the hum indicated that those present felt that it is not. We took a hum to see if those present felt that the process document is headed in the right direction. The hum indicated that they do. We took a hum to see if those present felt that we need to define a process to identify values, mission, scope, and goals. The hum was split. We took a hum to see when work should start on the short-term solutions proposals in the process document. The options were 1) when the problem statement is approved, 2) when the process document is approved, and 3) now. The hum was overwhelmingly in favor of "now." Needs more discussion: Appeals process Size of IETF documents Cross-organizational decision-making From problem-statement-bounces@alvestrand.no Tue Jul 22 18:19:20 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29346 for ; Tue, 22 Jul 2003 18:19:20 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 86FF161B94; Wed, 23 Jul 2003 00:18:52 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3409161B92 for ; Wed, 23 Jul 2003 00:18:50 +0200 (CEST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h6MMHSJ19665; Tue, 22 Jul 2003 18:17:30 -0400 (EDT) Date: Tue, 22 Jul 2003 18:17:28 -0400 From: Keith Moore To: Iljitsch van Beijnum Message-Id: <20030722181728.25379635.moore@cs.utk.edu> In-Reply-To: <1535EBDC-BC66-11D7-974F-00039388672E@muada.com> References: <0cc601c35070$acbd1d20$020aff0a@tsg1> <1535EBDC-BC66-11D7-974F-00039388672E@muada.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no, moore@cs.utk.edu Subject: Re: The IETF's problems X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit > What I don't get is why the IESG should be involved in managing the > wgs in the first place. because, left to themselves, WGs will happily create things that don't satisfy various requirements (such as security), or which interfere with other parties' interests (like zeroconf or nat WGs trying to fundamentally change the way IP works), and then the WGs will get very annoyed when they only learn *after* they think they're done why IESG (for quite valid reasons) refuses to approve their documents and their work isn't even fixable. what I don't get is why anyone could think that WGs should be allowed to make standards without some broad-based oversight. From problem-statement-bounces@alvestrand.no Tue Jul 22 18:57:14 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00021 for ; Tue, 22 Jul 2003 18:57:13 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 82B1861B94; Wed, 23 Jul 2003 00:56:45 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from sequoia.muada.com (sequoia.muada.com [213.156.1.123]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4371661B92 for ; Wed, 23 Jul 2003 00:56:44 +0200 (CEST) Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h6MMvMxS047662; Wed, 23 Jul 2003 00:57:22 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Wed, 23 Jul 2003 00:56:41 +0200 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) To: Keith Moore From: Iljitsch van Beijnum In-Reply-To: <20030722181728.25379635.moore@cs.utk.edu> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Cc: problem-statement@alvestrand.no Subject: Re: The IETF's problems X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit On woensdag, jul 23, 2003, at 00:17 Europe/Amsterdam, Keith Moore wrote: >> What I don't get is why the IESG should be involved in managing the >> wgs in the first place. > because, left to themselves, WGs will happily create things that > don't satisfy various requirements (such as security), or which > interfere with other parties' interests (like zeroconf or nat WGs > trying to fundamentally change the way IP works), and then the WGs will > get very annoyed when they only learn *after* they think they're done > why IESG (for quite valid reasons) refuses to approve their documents > and their work isn't even fixable. I don't think the annoyance can be avoided in cases like this. All this work just to move the moment when this happens around doesn't seem like a very effective use of time and energy. And does the current way of doing this really work? And what's the problem with zeroconf anyway? > what I don't get is why anyone could think that WGs should be allowed > to > make standards without some broad-based oversight. The current way of doing this doesn't work very well. If someone can come up with something better, that would be great. If not... then we need to be more radical. From problem-statement-bounces@alvestrand.no Tue Jul 22 19:03:17 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00194 for ; Tue, 22 Jul 2003 19:03:16 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1811C61B94; Wed, 23 Jul 2003 01:02:49 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from pintail.mail.pas.earthlink.net (pintail.mail.pas.earthlink.net [207.217.120.122]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5495A61B92 for ; Wed, 23 Jul 2003 01:02:47 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by pintail.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19f69a-0002As-00; Tue, 22 Jul 2003 16:02:43 -0700 Date: Tue, 22 Jul 2003 19:02:02 -0400 From: Keith Moore To: Iljitsch van Beijnum Message-Id: <20030722190202.06a32538.moore@cs.utk.edu> In-Reply-To: References: <20030722181728.25379635.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.9.1 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no, moore@cs.utk.edu Subject: Re: The IETF's problems X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit > > because, left to themselves, WGs will happily create things that > > don't satisfy various requirements (such as security), or which > > interfere with other parties' interests (like zeroconf or nat WGs > > trying to fundamentally change the way IP works), and then the WGs will > > get very annoyed when they only learn *after* they think they're done > > why IESG (for quite valid reasons) refuses to approve their documents > > and their work isn't even fixable. > > I don't think the annoyance can be avoided in cases like this. All this > work just to move the moment when this happens around doesn't seem like > a very effective use of time and energy. so if you're trying to go somewhere, you'd rather just start out travelling in a random direction, and wait until you think you should be there to find out that your course is 90 degress off? > And does the current way of doing this really work? not as well as we'd like. that's one of our biggest problems. > And what's the problem with zeroconf anyway? it breaks widely-held assumptions about the scope and stability of IPv4 addresses. > > what I don't get is why anyone could think that WGs should be allowed > > to make standards without some broad-based oversight. > > The current way of doing this doesn't work very well. If someone can > come up with something better, that would be great. If not... then we > need to be more radical. so if banging your head against a foam pillow doesn't work, try banging it against a brick wall? From problem-statement-bounces@alvestrand.no Tue Jul 22 19:18:18 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00518 for ; Tue, 22 Jul 2003 19:18:16 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B9A9F61B94; Wed, 23 Jul 2003 01:15:34 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from sequoia.muada.com (sequoia.muada.com [213.156.1.123]) by eikenes.alvestrand.no (Postfix) with ESMTP id 73FC961B92 for ; Wed, 23 Jul 2003 01:15:33 +0200 (CEST) Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h6MNGBxS047895; Wed, 23 Jul 2003 01:16:12 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Wed, 23 Jul 2003 01:15:31 +0200 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) To: Melinda Shore From: Iljitsch van Beijnum In-Reply-To: <200307222202.AJW87618@mira-sjc5-c.cisco.com> Message-Id: <6381DCB0-BC9A-11D7-974F-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Cc: problem-statement@alvestrand.no Subject: Re: A few hums X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit On woensdag, jul 23, 2003, at 00:02 Europe/Amsterdam, Melinda Shore wrote: > In the discussion of whether or not there's a problem > accomodating ESL speakers, the discussion broadened a bit to > cover cultural issues, the hum indicated that those present > felt that we needed more text on this issue. Something that people who aren't used to working in a second or third language may not realize is that it often simply takes more time to digest what is said in English for non-native speakers. For me, it's especially this humming thing that usually happens way too fast. There was more than one occasion last week where the hum was over before I could join in. For some unknown reason, this problem is much less for me with hand raising, although a few triple negatives in the question slow me down in that case too. And was it just me or were many of the participants from Japan especially hard to understand? I think in many cases this is exacerbated when people (try to) speak too fast. Maybe some kind of sunday session where people who will be presenting later in the week can get some feedback on the way they speak can take the edge off here. The system they use for the ICANN meetings where all text is typed in verbatim and projected on a screen is also a very good solution and comes in handy for other reasons as well, but this is probably way too expensive. As for cultural issues: it may be good to say something about what is the appropriate way to get someone's attention for exchanging a few words before/after a session or in the hallways. From problem-statement-bounces@alvestrand.no Tue Jul 22 22:54:42 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03771 for ; Tue, 22 Jul 2003 22:54:41 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2A89761B9F; Wed, 23 Jul 2003 04:54:13 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from sentosa.post1.com (sentosa.post1.com [202.27.17.100]) by eikenes.alvestrand.no (Postfix) with SMTP id F023C61B98 for ; Wed, 23 Jul 2003 04:54:09 +0200 (CEST) Received: (qmail 99928 invoked from network); 23 Jul 2003 02:58:49 -0000 Received: from ida120.ida.gov.sg (HELO pobox.org.sg) (210.24.194.120) by sentosa.post1.com with SMTP; 23 Jul 2003 02:58:49 -0000 Message-ID: <3F1DF8BC.5030600@pobox.org.sg> Date: Wed, 23 Jul 2003 10:53:48 +0800 From: James Seng User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en, zh-cn, zh-tw, ja, ko MIME-Version: 1.0 To: todd glassey References: <4E535D0E-BC49-11D7-974F-00039388672E@muada.com><0c8f01c35068$7177e6d0$020aff0a@tsg1> <006c01c3506d$3c196360$8100000a@DFNJGL21> <0cc601c35070$acbd1d20$020aff0a@tsg1> In-Reply-To: <0cc601c35070$acbd1d20$020aff0a@tsg1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: The IETF's problems X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit It is good to be inconsistent. Different areas, different wgs, different requirements. Some can have one, some can have more then one. -James Seng todd glassey wrote: > The problem is that this is not consistent across all WG's - And AD's are > really the last word still on whether a competitive WG was created. > > What I am trying to illustrate here Spencer is that the really fair process > involves creating an initiative based on the ability to field a team of > vetting resources. So if there is a WG that has 200 people subscribed to it, > how many of then actually work on any given initiative? the numbers will > surprise you and the list archive bears all this out. > > The real issue is then creating a formal requirement for all WG's to > participate in the process equally and allow for any number of initiatives > as long as the work gets done. > > Todd > > ----- Original Message ----- > From: "Spencer Dawkins" > To: > Sent: Tuesday, July 22, 2003 9:20 AM > Subject: Re: The IETF's problems > > > >>Ummm, but we DO have competing documents. I think we're more likely >>to do them in parallel working groups (see IMPP/SIMPLE/XMPP for >>running code), and that's probably better anyway (less mud-slinging >>within a working group), but don't even START on how many IPv6 >>transition mechanisms we have, or how many MANETs we have, or ... >> >>Spencer >> >>----- Original Message ----- >>From: "todd glassey" >>To: "Melinda Shore" ; "Iljitsch van Beijnum" >> >>Cc: >>Sent: Tuesday, July 22, 2003 10:20 AM >>Subject: Re: The IETF's problems >> >> >> >>>Melinda - All - >>>I have a question, and that is "do you consider the IETF's not formally >>>allowing more than one standard track item per/WG per/initiative-scope" > > a > >>>problem?, because I do, and I consider it a serious one at that. What I > > am > >>>referring to is the fundamental issue of whether WG's should be allowed > > to > >>>limit the number of initiatives on any one track to one, and my take is >> >>that >> >>>the answer here is NO. >>> >>>My reasons for asking this are that RFC2026 and 2223 as well as 2418 all >>>talk about the scope and process of the standards model, but none of > > them > >>>really have any process for one effort to supersede another unless that >>>effort is done by the people "owning" that spot originally. There are no >>>"hostile takeover guidelines" or processes, and that means that any >>>evolution of challenge of a commercially used protocol has to have the >>>blessings of the WG Chair and those that already own that standing in a > > WG > >>>(This of course pertains to existing protocols predominantly). >>> >>>So look - here is an example, Say I have a protocol for "Whiz-Banging" > > and > >>>there is already a protocol on track inside a WG that Whiz-Bangs but in > > a > >>>different manner. So the question is whether the IETF can support two or >>>more Whiz-Banging implementations, or only one, because if the answer is >>>"only one" then we need to also have a method for how would anyone >> >>introduce >> >>>the second Whiz-Banging protocol to the IETF to compete with the other? >>> >>>The problem is that the answer is today that functionally that this will >>>never happen. And it is because it is very very unlikely that the folks >> >>with >> >>>their Whiz-Banging Protocol are going to want to roll-over and die... >>> >>>So then what happens??? The challenging Whiz-Banger is submitted to the >> >>I-D >> >>>staff as a disclosure. The I-D staff go to the WG Chair who makes a >> >>judgment >> >>>that they will not allow that protocol to harm the one that has already >>>gotten investment from them and the others in their WG, so now the WG >> >>Chair >> >>>takes an active role in suppressing the challenging effort. But say the >> >>I-D >> >>>issues get past the WG Chair, so then perhaps with the current model the >> >>I-D >> >>>staff also decide that they don't want to publish this draft because it >>>competes with an already in-process or existing standard or >> >>standards-track >> >>>participant. So this is yet another hurdle to publication and an issue. > > So > >>>now they as well are part of a restraint of trade development process as >>>well. >>> >>>So the question simply is where does this end? Just how does the IETF >> >>allow >> >>>for a competitive effort, since anything else seems to have serious > > legal > >>>issues with restraint of market development (the building of standards > > is > >>a >> >>>key part of this). Or is this just not of importance to this IETF? >>> >>>Todd Glassey >>>----- Original Message ----- >>>From: "Iljitsch van Beijnum" >>>To: "Melinda Shore" >>>Cc: >>>Sent: Tuesday, July 22, 2003 6:35 AM >>>Subject: Re: The IETF's problems >>> >>> >>> >>>>On zondag, jul 20, 2003, at 19:28 Europe/Amsterdam, Melinda Shore > > wrote: > >>>>>The discussion itself isn't doing much to distill the topic >>>>>down to document text, and we need to stay focused. Do you >>>>>feel that existing text regarding scope in the problem >>>>>statement document is inadequate? >>>> >>>>Not sure what you mean by scope. >>>> >>>>However, many of the "root" problems in the problems draft aren't that >>>>fundamental. The three most fundamental problems I see are: >>>> >>>>- the IETF doesn't know what it wants to be: a "real" standards >>>>organization or some kind of a grass roots movement >>>>- inability to make decisions other than just wait until there is >>>>agreement or come up with convoluted processes that only work because >>>>people are forced to interact until they somehow solve the problem >>>>- inability to manage resources effectively and efficiently >>>> >>>>Iljitsch >>>> >>> > > > From problem-statement-bounces@alvestrand.no Tue Jul 22 23:08:59 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04033 for ; Tue, 22 Jul 2003 23:08:59 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7CB7261B99; Wed, 23 Jul 2003 05:08:30 +0200 (CEST) X-Original-To: problem-statement@Alvestrand.no Delivered-To: problem-statement@Alvestrand.no Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by eikenes.alvestrand.no (Postfix) with ESMTP id 45E9C61B92; Wed, 23 Jul 2003 05:08:27 +0200 (CEST) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h6N3CMF02664; Tue, 22 Jul 2003 20:12:23 -0700 Date: Tue, 22 Jul 2003 20:08:24 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/11) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <9815145718.20030722200824@brandenburg.com> To: Harald Alvestrand MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Request for Clarification: Major Changes are Needed X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list Reply-To: dcrocker@brandenburg.com List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Harald, Over recent months, you have said a number of times that you believed that the IETF needs to undergo "major changes". When the IETF Chair says that major changes are needed, that should get our attention, and it certainly has gotten mine. Unfortunately, I do not know what you mean. The changes after Kobe could be called major and they could actually be called quite small, since the vast portion of IETF process and structure remained unchanged. So I think it would be very helpful to have the IETF Chair add some substance to the stated conclusion that major change is needed. What do you mean? d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Wed Jul 23 02:41:14 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03540 for ; Wed, 23 Jul 2003 02:41:13 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0770361B99; Wed, 23 Jul 2003 08:40:43 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from d06lmsgate-4.uk.ibm.com (d06lmsgate-4.uk.ibm.com [195.212.29.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3705361B99 for ; Wed, 23 Jul 2003 08:40:41 +0200 (CEST) Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by d06lmsgate-4.uk.ibm.com (8.12.9/8.12.8) with ESMTP id h6N6edXl019498 for ; Wed, 23 Jul 2003 07:40:40 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h6N6ZDel274356 for ; Wed, 23 Jul 2003 08:35:19 +0200 Received: from hursley.ibm.com (dhcp22-107.zurich.ibm.com [9.4.22.107]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id IAA48072 for ; Wed, 23 Jul 2003 08:35:02 +0200 Message-ID: <3F1E2C9B.9CFDA853@hursley.ibm.com> Date: Wed, 23 Jul 2003 08:35:07 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: problem-statement@alvestrand.no References: <20030722181728.25379635.moore@cs.utk.edu> <20030722190202.06a32538.moore@cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Late surprises redux [Re: The IETF's problems] X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit We discussed this some months ago under the subject 'avoiding late surprises.' The conclusion was that the major process bug here is that early drafts are not reviewed for IETF-wide issues. Of course nobody can rationally expect the IESG to take on the extra work of reviewing early drafts. Hence draft-carpenter-solution-sirs-01.txt, whose discussion belongs on solutions@alvestrand.no Brian Keith Moore wrote: > > > > because, left to themselves, WGs will happily create things that > > > don't satisfy various requirements (such as security), or which > > > interfere with other parties' interests (like zeroconf or nat WGs > > > trying to fundamentally change the way IP works), and then the WGs will > > > get very annoyed when they only learn *after* they think they're done > > > why IESG (for quite valid reasons) refuses to approve their documents > > > and their work isn't even fixable. > > > > I don't think the annoyance can be avoided in cases like this. All this > > work just to move the moment when this happens around doesn't seem like > > a very effective use of time and energy. > > so if you're trying to go somewhere, you'd rather just start out travelling in > a random direction, and wait until you think you should be there to find out > that your course is 90 degress off? > > > And does the current way of doing this really work? > > not as well as we'd like. that's one of our biggest problems. > > > And what's the problem with zeroconf anyway? > > it breaks widely-held assumptions about the scope and stability of IPv4 > addresses. > > > > what I don't get is why anyone could think that WGs should be allowed > > > to make standards without some broad-based oversight. > > > > The current way of doing this doesn't work very well. If someone can > > come up with something better, that would be great. If not... then we > > need to be more radical. > > so if banging your head against a foam pillow doesn't work, try banging it > against a brick wall? From problem-statement-bounces@alvestrand.no Wed Jul 23 02:46:36 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03682 for ; Wed, 23 Jul 2003 02:46:36 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B1D0461B99; Wed, 23 Jul 2003 08:46:05 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from netcore.fi (netcore.fi [193.94.160.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E49FA61B98 for ; Wed, 23 Jul 2003 08:46:03 +0200 (CEST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6N6jmf15317; Wed, 23 Jul 2003 09:45:48 +0300 Date: Wed, 23 Jul 2003 09:45:47 +0300 (EEST) From: Pekka Savola To: Iljitsch van Beijnum In-Reply-To: <6381DCB0-BC9A-11D7-974F-00039388672E@muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Melinda Shore , problem-statement@alvestrand.no Subject: Re: A few hums X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Just adding my two cents.. On Wed, 23 Jul 2003, Iljitsch van Beijnum wrote: [...] > And was it just me Nope. > or were many of the participants from Japan > especially hard to understand? YES! > I think in many cases this is > exacerbated when people (try to) speak too fast. [...] Indeed. However, *I* at least don't have any problems with understanding fast speaking, *as long as* the speaker is a native speaker (or close enough), i.e. can speak in a way I'm used to hear English spoken. I'm not sure how big a problem this is for most folks. But when someone with e.g. a strong French or Japanese/Korean accent tries to speak fast, then everyone is lost immediately.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From problem-statement-bounces@alvestrand.no Wed Jul 23 04:30:27 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05786 for ; Wed, 23 Jul 2003 04:30:27 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5D88761B98; Wed, 23 Jul 2003 10:29:57 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from sequoia.muada.com (sequoia.muada.com [213.156.1.123]) by eikenes.alvestrand.no (Postfix) with ESMTP id A51DE61AA5 for ; Wed, 23 Jul 2003 10:29:55 +0200 (CEST) Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h6N8UXxS053822; Wed, 23 Jul 2003 10:30:34 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Wed, 23 Jul 2003 10:29:52 +0200 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) To: Pekka Savola From: Iljitsch van Beijnum In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Cc: problem-statement@alvestrand.no Subject: Re: A few hums X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit On woensdag, jul 23, 2003, at 08:45 Europe/Amsterdam, Pekka Savola wrote: >> I think in many cases this is >> exacerbated when people (try to) speak too fast. [...] > Indeed. > However, *I* at least don't have any problems with understanding fast > speaking, *as long as* the speaker is a native speaker (or close > enough), > i.e. can speak in a way I'm used to hear English spoken. I'm not sure > how > big a problem this is for most folks. I don't know if people come to IETF meetings who find it difficult to follow English when it is spoken clear but fast. Speed in itself isn't a problem for me, as long as I get a few moments to let everything sink in before I'm required to react. However, speaking fast and still articulate well is something that is hard even for native speakers. And the people who speak the fastest usually use the most "uhm", "ahhh", "errr" and so on so it really doesn't help anyway. > But when someone with e.g. a strong French or Japanese/Korean accent > tries > to speak fast, then everyone is lost immediately.. Yes, this is often the case although there are also many people with accents that don't get in the way. From problem-statement-bounces@alvestrand.no Wed Jul 23 07:05:22 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08422 for ; Wed, 23 Jul 2003 07:05:21 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A338961B98; Wed, 23 Jul 2003 13:04:52 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by eikenes.alvestrand.no (Postfix) with ESMTP id D406761AA5 for ; Wed, 23 Jul 2003 13:04:51 +0200 (CEST) Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h6NB4pVI088991; Wed, 23 Jul 2003 13:04:51 +0200 (CEST) Received: from [10.1.1.130] (brunner.office [10.1.1.130]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 600EC8F280; Wed, 23 Jul 2003 12:44:58 +0200 (CEST) Date: Wed, 23 Jul 2003 13:04:50 +0200 From: Marcus Brunner To: James Kempf , "Bound, Jim" , Dave Crocker , problem-statement@alvestrand.no Message-ID: <10334049.1058965490@[10.1.1.130]> In-Reply-To: <00b801c36a64$4a4d4e40$036015ac@T23KEMPF> References: <9C422444DE99BC46B3AD3C6EAFC9711B03241074@tayexc13.americas.cpqco rp.net> <00b801c36a64$4a4d4e40$036015ac@T23KEMPF> X-Mailer: Mulberry/3.0.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: making strategic problems concrete X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list Reply-To: Marcus Brunner List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit James, I have not seen another standardization organization having a better solution. Agreeing is a long painful process, which we can not avoid. Marcus --On Sonntag, 24. August 2003 10:22 -0700 James Kempf wrote: > Jim, > > I think another problem is sometimes there are just multiple possible > designs with equally good technical properties, with minor tradeoffs in > one direction or another. From an engineering standpoint, any of them > might make sense. From a market standpoint however, people want one to > avoid costly investments in multiple different kinds of infrastructure. > The difficulty is how to select one. Using concensus may ultimately lead > to the different parties simply failing to yield, or incorporating > different parts of each design resulting in an overall design that is > much more complex than really necessary. > > jak > > > > ----- Original Message ----- > From: "Bound, Jim" > To: "Dave Crocker" ; > Sent: Sunday, March 23, 2003 9:24 PM > Subject: RE: making strategic problems concrete > > >> >> >> >> > 1) state precisely what fundamental operational problems they see >> > >> > eg., not just "we've gotten big" but rather "our getting >> > big means attendees are not always seeking timely >> > productive outcome" or "it takes too long to hear >> > everyone's views" or...) >> > 2) state precisely what fundamental organizational or >> > operational changes they believe are called for (and how it >> > will fix> the problem.) >> >> Technical work that has been accepted within the working group, which >> also has strong technical proponents with different solutions, takes a >> very long time to achieve compromise, and creates time-to-market barrier >> for that technical work to achieve Proposed Standard, BCP, or even >> Informational status. >> >> Not sure what the solution is totally but thinking, but I think the >> complexity as was pointed out in the plenary on this topic at the podium >> was that problems are interrelated and why this job here is hard. Trying >> to fix it with SIRs is not going to work. >> >> A lot of the problems in the IETF are systemic from lack of trust. Here >> are a few, that in turn creates operational problems. >> >> Consensus is not well defined, it permits a persistent reviewing of the >> same topic over and over. It is good to revisit our ideas, but after >> first agreement, having defined checkpoints, similar to project change >> control in industry, would assist with when a previous consensus point >> can be open for review. Or at least a process to do this so it is not >> random and ad hoc. This would also permit a bad consensus decision to >> be revisited and prevent it not being revisited if it has become broken. >> >> It is "perceived" that Design Teams, IESG, and just about everything we >> do is a good ole boy network. I believe this is not done on purpose nor >> the majority of efforts. But perception is reality. This creates >> distrust and machavellian moves by factions within the working group to >> do end run around the good ole boy network. This slows up the process >> for any subject. We need an open and documented process for any ad hoc >> groups like SIR. >> >> IESG members should not have anything to do with the Nom-Com it is like >> the Government being in the voting booth with you. This creates a >> distrust of our POISED process and a simple thing to fix. No one near >> the NOMCOM from the IESG or IAB except for formal questions. If having >> knowledge at the meeting then use past IESG/IAB members or ISOC >> Trustees. >> >> Elistism. For example, when an AD says "this list" don't have this >> expertise that's really bad unless that AD knows everyone really really >> well on that list. I would argue that is not possible given the breadth >> our ADs have to cover. Better they don't say things like this, and its >> rude. >> >> Most specs run into WG trouble when the mission, goals, objective, >> assumptions, and problem being addressed are not known until far to late >> in the process. This causes a longer time to reach consensus for each >> point with the proposed work. If each spec puts each of the above >> attributes in the first section of its spec it will go a long way to >> create a faster process. Specs should be able to define those in no >> more than 4 sentences. It is also critical that assumptions be >> discussed across the topic areas, because we often spend to much time in >> debate of the solution when we did not realize our assumptions were >> different. >> >> I will stop here for now. >> >> /jim >> >> > -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ Phone: +49 (0) 6221 905 11 29 Mobile: +49 (0) 163 275 17 43 personal home page: http://www.brubers.org/marcus From problem-statement-bounces@alvestrand.no Wed Jul 23 07:56:32 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08974 for ; Wed, 23 Jul 2003 07:56:32 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A2A8861B98; Wed, 23 Jul 2003 13:56:01 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by eikenes.alvestrand.no (Postfix) with ESMTP id E76F761AA5 for ; Wed, 23 Jul 2003 13:55:59 +0200 (CEST) Received: from newdev.harvard.edu (localhost [127.0.0.1]) by newdev.harvard.edu (8.12.9/8.12.2) with ESMTP id h6NBtw9n019097 for ; Wed, 23 Jul 2003 07:55:58 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.9/8.12.2/Submit) id h6NBtwbt019096 for problem-statement@alvestrand.no; Wed, 23 Jul 2003 07:55:58 -0400 (EDT) Date: Wed, 23 Jul 2003 07:55:58 -0400 (EDT) From: Scott Bradner Message-Id: <200307231155.h6NBtwbt019096@newdev.harvard.edu> To: problem-statement@alvestrand.no Subject: ideas for alternate approval processes X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no I've just submitted an ID with some ideas on how the IETF approval process might be changed to answer some of the problems listed in the problem statement if you do not want to wait you can get a copy at http://www.sobco.com/ietf/draft-bradner-ietf-proc-ideas-00.txt discissions on the solutions list please Scott From problem-statement-bounces@alvestrand.no Wed Jul 23 10:02:41 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13073 for ; Wed, 23 Jul 2003 10:02:40 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B85AB61B9B; Wed, 23 Jul 2003 16:02:11 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from HALVESTR-W2K1.cisco.com (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 15E4561B99; Wed, 23 Jul 2003 16:02:05 +0200 (CEST) Date: Tue, 22 Jul 2003 17:40:26 +0200 From: Harald Tveit Alvestrand To: Ted Lemon , problem-statement@alvestrand.no Message-ID: <323735266.1058895626@localhost> In-Reply-To: <200307171130.15885.mellon@nominum.com> References: <265000-220037316193037308@M2W060.mail2web.com> <200307171130.15885.mellon@nominum.com> X-Mailer: Mulberry/3.0.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Transcriptions (Re: Hearing and Speaking Problems for Non-Native Englishspeakingparticipants.) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Background info only...... --On 17. juli 2003 11:30 +0200 Ted Lemon wrote: > On Wednesday 16 July 2003 21:30, spencer@mcsr-labs.org wrote: >> This does point up the difference between scribe notes and WG minutes. In >> most cases I've been involved with, we've had the choice of "he said/she >> said" notes with all the details, or summaries without all the details. >> We have the possibility of publishing BOTH, and I think Jabber would >> help us make this happen. >> >> And what do others think? > > I'm a bit puzzled as to why we don't just record the entire meeting from > the sound board, and do the minutes off of a complete transcript. This > would provide a nice incentive for non-mike-talkers, and it's a lot more > reliable than relying on random scribes, particularly since the scribes > in question are usually active participants in the wg whose comments are > lost when they go up to the microphone. In meeting rooms where we use microphones anyway, recording the sessions wouldn't change the dynamics much. In smaller meetings (some still occur :-), it would change the dynamics; the introduction of room mikes has been one of the things that has made IETF meetings more formal (and sometimes less fun?) over the last 10 years. I don't know how much knowing that a meeting is recorded would impact people's style of participation. Professional transcription services cost money (I have heard the number, but don't remember - USD 250 occured somewhere, but I can't remember if that was per hour or per 2 1/2 hour session - we do about 200 hours of meetings at an IETF, so at 250/hour, it would be about 50.000 USD), and would require expert review to get all the terms right (I remember an ICANN session that consistently transcribed "DNSSEC" as "DNS Sex"). Just knowing that the recordings were available (MP3 files?) would probably be good enough for many people, and would allow scribes to focus on recording what decisions were made - something that can be quite hard at times from "he said, she said" style minutes! (BTW, this is sometimes done. Someone once transcribed my commencement speech from the Minneapolis plenary, I proofread/edited it, and published it as an article in the ISOC newsletter. It was the only way I'd ever get to know what I actually said - but I have no idea how much time it cost!) Harald From problem-statement-bounces@alvestrand.no Wed Jul 23 10:34:23 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15056 for ; Wed, 23 Jul 2003 10:34:22 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E228061B9A; Wed, 23 Jul 2003 16:33:51 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5989361B99 for ; Wed, 23 Jul 2003 16:33:50 +0200 (CEST) Received: from tsg1 (190.sanjose-05-10rs16rt.ca.dial-access.att.net[12.81.6.190]) by mtiwmhc12.worldnet.att.net (mtiwmhc12) with SMTP id <2003072314334611200q22aqe>; Wed, 23 Jul 2003 14:33:47 +0000 Message-ID: <004901c35127$529c3850$020aff0a@tsg1> From: "todd glassey" To: "James Seng" References: <4E535D0E-BC49-11D7-974F-00039388672E@muada.com><0c8f01c35068$7177e6d0$020aff0a@tsg1> <006c01c3506d$3c196360$8100000a@DFNJGL21> <0cc601c35070$acbd1d20$020aff0a@tsg1> <3F1DF8BC.5030600@pobox.org.sg> Date: Wed, 23 Jul 2003 07:17:20 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Cc: problem-statement@alvestrand.no Subject: Re: The IETF's problems X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit James - with inconsistency - how is it possible that ANYONE gets the same treatment or gets their standard processed under the same mechanisms? and the answer is that they cant. So then the IETF is not a Uniform Standards Practice but rather an adversarial one for some and a greased-skid for others. Todd ----- Original Message ----- From: "James Seng" To: "todd glassey" Cc: "Spencer Dawkins" ; Sent: Tuesday, July 22, 2003 7:53 PM Subject: Re: The IETF's problems > It is good to be inconsistent. Different areas, different wgs, different > requirements. Some can have one, some can have more then one. > > -James Seng > > todd glassey wrote: > > > The problem is that this is not consistent across all WG's - And AD's are > > really the last word still on whether a competitive WG was created. > > > > What I am trying to illustrate here Spencer is that the really fair process > > involves creating an initiative based on the ability to field a team of > > vetting resources. So if there is a WG that has 200 people subscribed to it, > > how many of then actually work on any given initiative? the numbers will > > surprise you and the list archive bears all this out. > > > > The real issue is then creating a formal requirement for all WG's to > > participate in the process equally and allow for any number of initiatives > > as long as the work gets done. > > > > Todd > > > > ----- Original Message ----- > > From: "Spencer Dawkins" > > To: > > Sent: Tuesday, July 22, 2003 9:20 AM > > Subject: Re: The IETF's problems > > > > > > > >>Ummm, but we DO have competing documents. I think we're more likely > >>to do them in parallel working groups (see IMPP/SIMPLE/XMPP for > >>running code), and that's probably better anyway (less mud-slinging > >>within a working group), but don't even START on how many IPv6 > >>transition mechanisms we have, or how many MANETs we have, or ... > >> > >>Spencer > >> > >>----- Original Message ----- > >>From: "todd glassey" > >>To: "Melinda Shore" ; "Iljitsch van Beijnum" > >> > >>Cc: > >>Sent: Tuesday, July 22, 2003 10:20 AM > >>Subject: Re: The IETF's problems > >> > >> > >> > >>>Melinda - All - > >>>I have a question, and that is "do you consider the IETF's not formally > >>>allowing more than one standard track item per/WG per/initiative-scope" > > > > a > > > >>>problem?, because I do, and I consider it a serious one at that. What I > > > > am > > > >>>referring to is the fundamental issue of whether WG's should be allowed > > > > to > > > >>>limit the number of initiatives on any one track to one, and my take is > >> > >>that > >> > >>>the answer here is NO. > >>> > >>>My reasons for asking this are that RFC2026 and 2223 as well as 2418 all > >>>talk about the scope and process of the standards model, but none of > > > > them > > > >>>really have any process for one effort to supersede another unless that > >>>effort is done by the people "owning" that spot originally. There are no > >>>"hostile takeover guidelines" or processes, and that means that any > >>>evolution of challenge of a commercially used protocol has to have the > >>>blessings of the WG Chair and those that already own that standing in a > > > > WG > > > >>>(This of course pertains to existing protocols predominantly). > >>> > >>>So look - here is an example, Say I have a protocol for "Whiz-Banging" > > > > and > > > >>>there is already a protocol on track inside a WG that Whiz-Bangs but in > > > > a > > > >>>different manner. So the question is whether the IETF can support two or > >>>more Whiz-Banging implementations, or only one, because if the answer is > >>>"only one" then we need to also have a method for how would anyone > >> > >>introduce > >> > >>>the second Whiz-Banging protocol to the IETF to compete with the other? > >>> > >>>The problem is that the answer is today that functionally that this will > >>>never happen. And it is because it is very very unlikely that the folks > >> > >>with > >> > >>>their Whiz-Banging Protocol are going to want to roll-over and die... > >>> > >>>So then what happens??? The challenging Whiz-Banger is submitted to the > >> > >>I-D > >> > >>>staff as a disclosure. The I-D staff go to the WG Chair who makes a > >> > >>judgment > >> > >>>that they will not allow that protocol to harm the one that has already > >>>gotten investment from them and the others in their WG, so now the WG > >> > >>Chair > >> > >>>takes an active role in suppressing the challenging effort. But say the > >> > >>I-D > >> > >>>issues get past the WG Chair, so then perhaps with the current model the > >> > >>I-D > >> > >>>staff also decide that they don't want to publish this draft because it > >>>competes with an already in-process or existing standard or > >> > >>standards-track > >> > >>>participant. So this is yet another hurdle to publication and an issue. > > > > So > > > >>>now they as well are part of a restraint of trade development process as > >>>well. > >>> > >>>So the question simply is where does this end? Just how does the IETF > >> > >>allow > >> > >>>for a competitive effort, since anything else seems to have serious > > > > legal > > > >>>issues with restraint of market development (the building of standards > > > > is > > > >>a > >> > >>>key part of this). Or is this just not of importance to this IETF? > >>> > >>>Todd Glassey > >>>----- Original Message ----- > >>>From: "Iljitsch van Beijnum" > >>>To: "Melinda Shore" > >>>Cc: > >>>Sent: Tuesday, July 22, 2003 6:35 AM > >>>Subject: Re: The IETF's problems > >>> > >>> > >>> > >>>>On zondag, jul 20, 2003, at 19:28 Europe/Amsterdam, Melinda Shore > > > > wrote: > > > >>>>>The discussion itself isn't doing much to distill the topic > >>>>>down to document text, and we need to stay focused. Do you > >>>>>feel that existing text regarding scope in the problem > >>>>>statement document is inadequate? > >>>> > >>>>Not sure what you mean by scope. > >>>> > >>>>However, many of the "root" problems in the problems draft aren't that > >>>>fundamental. The three most fundamental problems I see are: > >>>> > >>>>- the IETF doesn't know what it wants to be: a "real" standards > >>>>organization or some kind of a grass roots movement > >>>>- inability to make decisions other than just wait until there is > >>>>agreement or come up with convoluted processes that only work because > >>>>people are forced to interact until they somehow solve the problem > >>>>- inability to manage resources effectively and efficiently > >>>> > >>>>Iljitsch > >>>> > >>> > > > > > > > > From problem-statement-bounces@alvestrand.no Wed Jul 23 10:43:57 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15548 for ; Wed, 23 Jul 2003 10:43:56 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B0A3D61B9C; Wed, 23 Jul 2003 16:43:26 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from smail.alcatel.fr (colt-na165.alcatel.fr [62.23.212.165]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5EF2461B98; Wed, 23 Jul 2003 16:43:24 +0200 (CEST) Received: from frmail31.netfr.alcatel.fr (frmail31.netfr.alcatel.fr [155.132.251.42]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id h6NEhFPU013572; Wed, 23 Jul 2003 16:43:22 +0200 To: Harald Tveit Alvestrand X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: Alistair.Urie@alcatel.com Date: Wed, 23 Jul 2003 16:43:17 +0200 X-MIMETrack: Serialize by Router on FRMAIL31/FR/ALCATEL(Release 5.0.11 |July 24, 2002) at 07/23/2003 16:43:22 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-new Cc: problem-statement@alvestrand.no, problem-statement-bounces@alvestrand.no Subject: Re: Transcriptions (Re: Hearing and Speaking Problems for Non-Native Englishspeakingparticipants.) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Harald, I really don't see the point to transcript type minutes. They rarely add anything of "real value" and sometimes an accurate record can come back to "haunt" you! Within ETSI we sometimes record important meetings and then only use the tapes when there is a dispute about the accuracy of the minutes. This is much cheaper than systematic transcription. - Alistair URIE P.S. As far as accuracy of Jabber transciptions go I note that last wednesday night my name was recorded as "Alex T" rather than Alistair U..... Harald Tveit Alvestrand To: Ted Lemon , problem-statement@alvestrand.no Sent by: cc: problem-statement-bounces@al Subject: Transcriptions (Re: Hearing and Speaking Problems for Non-Native vestrand.no Englishspeakingparticipants.) 22/07/2003 17:40 Background info only...... --On 17. juli 2003 11:30 +0200 Ted Lemon wrote: > On Wednesday 16 July 2003 21:30, spencer@mcsr-labs.org wrote: >> This does point up the difference between scribe notes and WG minutes. In >> most cases I've been involved with, we've had the choice of "he said/she >> said" notes with all the details, or summaries without all the details. >> We have the possibility of publishing BOTH, and I think Jabber would >> help us make this happen. >> >> And what do others think? > > I'm a bit puzzled as to why we don't just record the entire meeting from > the sound board, and do the minutes off of a complete transcript. This > would provide a nice incentive for non-mike-talkers, and it's a lot more > reliable than relying on random scribes, particularly since the scribes > in question are usually active participants in the wg whose comments are > lost when they go up to the microphone. In meeting rooms where we use microphones anyway, recording the sessions wouldn't change the dynamics much. In smaller meetings (some still occur :-), it would change the dynamics; the introduction of room mikes has been one of the things that has made IETF meetings more formal (and sometimes less fun?) over the last 10 years. I don't know how much knowing that a meeting is recorded would impact people's style of participation. Professional transcription services cost money (I have heard the number, but don't remember - USD 250 occured somewhere, but I can't remember if that was per hour or per 2 1/2 hour session - we do about 200 hours of meetings at an IETF, so at 250/hour, it would be about 50.000 USD), and would require expert review to get all the terms right (I remember an ICANN session that consistently transcribed "DNSSEC" as "DNS Sex"). Just knowing that the recordings were available (MP3 files?) would probably be good enough for many people, and would allow scribes to focus on recording what decisions were made - something that can be quite hard at times from "he said, she said" style minutes! (BTW, this is sometimes done. Someone once transcribed my commencement speech from the Minneapolis plenary, I proofread/edited it, and published it as an article in the ISOC newsletter. It was the only way I'd ever get to know what I actually said - but I have no idea how much time it cost!) Harald From problem-statement-bounces@alvestrand.no Wed Jul 23 11:35:34 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17087 for ; Wed, 23 Jul 2003 11:35:33 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 78EEB61B9B; Wed, 23 Jul 2003 17:35:03 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9275B61B9A for ; Wed, 23 Jul 2003 17:35:01 +0200 (CEST) Received: from tsg1 (190.sanjose-05-10rs16rt.ca.dial-access.att.net[12.81.6.190]) by mtiwmhc12.worldnet.att.net (mtiwmhc12) with SMTP id <2003072315345811200lmudke>; Wed, 23 Jul 2003 15:34:59 +0000 Message-ID: <005201c3512f$df3d38b0$020aff0a@tsg1> From: "todd glassey" To: "Pekka Savola" , "Iljitsch van Beijnum" References: Date: Wed, 23 Jul 2003 08:08:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Cc: problem-statement@alvestrand.no Subject: Re: A few hums X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit So the issues with multiple languages are 1) people that don't speak English as their primary language MAY find it hard to understand English Dialog spoken too fast in a public forum. 2) people that don't speak English as their primary language may not have an equal participation opportunity because of the language issues and so they are slighted by the IETF's participation process... 3) people that likewise don't speak English as a primary language may miss any number of the nuances and any local colloquialisms that are used in technology disclosures... The analysis of this is pretty simple. Some people that are not Native English speakers MAY suffer herein... but this is subjective and dependant on the individuals perceptions and experience in speaking local dialects and technical English... What's the solution? - That's actually pretty simple too. The basic question here is whether the IETF can afford to take on a publications process that encompasses more than one language. And the answer is obviously NO if it is to retain any of its current flavor. So with that said, the also obvious answer is that in a meeting where one does not understand any of what is said, those individuals need to pose a question to the chair or the speakers to qualify their commentary more. Or just to explain themselves such that all understand the commentary. And this is more a rule of order than anything else it seems to me... Todd ----- Original Message ----- From: "Iljitsch van Beijnum" To: "Pekka Savola" Cc: Sent: Wednesday, July 23, 2003 1:29 AM Subject: Re: A few hums > On woensdag, jul 23, 2003, at 08:45 Europe/Amsterdam, Pekka Savola > wrote: > > >> I think in many cases this is > >> exacerbated when people (try to) speak too fast. [...] > > > Indeed. > > > However, *I* at least don't have any problems with understanding fast > > speaking, *as long as* the speaker is a native speaker (or close > > enough), > > i.e. can speak in a way I'm used to hear English spoken. I'm not sure > > how > > big a problem this is for most folks. > > I don't know if people come to IETF meetings who find it difficult to > follow English when it is spoken clear but fast. Speed in itself isn't > a problem for me, as long as I get a few moments to let everything sink > in before I'm required to react. However, speaking fast and still > articulate well is something that is hard even for native speakers. And > the people who speak the fastest usually use the most "uhm", "ahhh", > "errr" and so on so it really doesn't help anyway. > > > But when someone with e.g. a strong French or Japanese/Korean accent > > tries > > to speak fast, then everyone is lost immediately.. > > Yes, this is often the case although there are also many people with > accents that don't get in the way. > > From problem-statement-bounces@alvestrand.no Wed Jul 23 13:26:27 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20367 for ; Wed, 23 Jul 2003 13:26:26 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B61B161B9C; Wed, 23 Jul 2003 19:25:25 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by eikenes.alvestrand.no (Postfix) with ESMTP id DCA8F61B99 for ; Wed, 23 Jul 2003 19:25:23 +0200 (CEST) Received: from depa.dmes.org (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id 5A73D1B203B for ; Wed, 23 Jul 2003 12:18:07 -0500 (CDT) From: Ted Lemon To: problem-statement@alvestrand.no Date: Wed, 23 Jul 2003 12:25:32 -0500 User-Agent: KMail/1.5 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200307231225.32643.mellon@nominum.com> Subject: Re: Transcriptions (Re: Hearing and Speaking Problems for Non-Native Englishspeakingparticipants.) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit I have a little experience with recording too, and I agree that it would be prohibitive to get it done professionally. I also agree that transcripts generally aren't that useful. But having the MP3 available for generating the minutes probably is - you don't need a transcript to do minutes. It might be worth seeing if it's possible to get audio out from the boards in the meeting rooms, and then, at the chair's discretion, possibly record that using some Windows or Linux audio software. Making it a formal policy would probably be a mistake because of the cost, but making it possible and encouraging working groups to do it on a volunteer basis might be worthwhile. From problem-statement-bounces@alvestrand.no Wed Jul 23 13:32:58 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20605 for ; Wed, 23 Jul 2003 13:32:57 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4E4D261B9D; Wed, 23 Jul 2003 19:32:26 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by eikenes.alvestrand.no (Postfix) with ESMTP id 365E661B99 for ; Wed, 23 Jul 2003 19:32:25 +0200 (CEST) Received: from dfnjgl21 (autoimage.com[216.62.6.129](untrusted sender)) by comcast.net (sccrmhc13) with SMTP id <2003072317322301600aag04e> (Authid: sdawkins@comcast.net); Wed, 23 Jul 2003 17:32:24 +0000 Message-ID: <014201c35140$61403320$8100000a@DFNJGL21> From: "Spencer Dawkins" To: References: <265000-220037316193037308@M2W060.mail2web.com><200307171130.15885.mellon@nominum.com> <323735266.1058895626@localhost> Date: Wed, 23 Jul 2003 12:32:08 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: Re: Transcriptions (Re: Hearing and Speaking Problems for Non-Native Englishspeakingparticipants.) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list Reply-To: Spencer Dawkins List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit It's worth noting that meeting audio/video for working groups meeting in MBONE-equipped rooms has been available for playback for a number of years, and I don't know that I've noticed any difference in behavior between MBONE sessions and non-MBONE sessions. So maybe no one behaves differently for very long ("reality television meets the IETF")... I know Harald knows this, and will remember it as soon as the jet lag wears off. Or maybe it's all that DNS Sex? Spencer ----- Original Message ----- From: "Harald Tveit Alvestrand" To: "Ted Lemon" ; Sent: Tuesday, July 22, 2003 10:40 AM Subject: Transcriptions (Re: Hearing and Speaking Problems for Non-Native Englishspeakingparticipants.) > > In meeting rooms where we use microphones anyway, recording the sessions > wouldn't change the dynamics much. In smaller meetings (some still occur > :-), it would change the dynamics; the introduction of room mikes has been > one of the things that has made IETF meetings more formal (and sometimes > less fun?) over the last 10 years. I don't know how much knowing that a > meeting is recorded would impact people's style of participation. From problem-statement-bounces@alvestrand.no Wed Jul 23 13:57:36 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21475 for ; Wed, 23 Jul 2003 13:57:35 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id F181761B9F; Wed, 23 Jul 2003 19:57:04 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6CD9F61B9E for ; Wed, 23 Jul 2003 19:57:02 +0200 (CEST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h6NHuwJ12412; Wed, 23 Jul 2003 13:56:59 -0400 (EDT) Date: Wed, 23 Jul 2003 13:56:58 -0400 From: Keith Moore To: Spencer Dawkins Message-Id: <20030723135658.62fe4b50.moore@cs.utk.edu> In-Reply-To: <014201c35140$61403320$8100000a@DFNJGL21> References: <265000-220037316193037308@M2W060.mail2web.com> <200307171130.15885.mellon@nominum.com> <323735266.1058895626@localhost> <014201c35140$61403320$8100000a@DFNJGL21> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no, moore@cs.utk.edu Subject: Re: Transcriptions (Re: Hearing and Speaking Problems for Non-Native Englishspeakingparticipants.) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit > It's worth noting that meeting audio/video for working groups meeting > in MBONE-equipped rooms has been available for playback for a number > of years, and I don't know that I've noticed any difference in > behavior between MBONE sessions and non-MBONE sessions. During the brief time I was a WG chair I used to specifically request non-MBONE rooms because I found it disruptive to force people to queue at the microphone. Of course, this was for a relatively small group. Once you have a few hundred people in the room you have to have some access control mechanism - if not a microphone, then some other sort of talking stick, recognition by the chair, etc. From problem-statement-bounces@alvestrand.no Wed Jul 23 15:06:27 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24151 for ; Wed, 23 Jul 2003 15:06:26 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A043661BAC; Wed, 23 Jul 2003 21:03:21 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from purple.nge.isi.edu (AStrasbourg-206-1-12-217.w80-14.abo.wanadoo.fr [80.14.240.217]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0BC6361BAB for ; Wed, 23 Jul 2003 21:03:20 +0200 (CEST) Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.9/8.12.9) with SMTP id h6NJ3G9Z079502; Wed, 23 Jul 2003 20:03:17 +0100 (BST) (envelope-from csp@csperkins.org) Date: Wed, 23 Jul 2003 21:03:16 +0200 From: Colin Perkins To: Keith Moore Message-Id: <20030723210316.2a873d5e.csp@csperkins.org> In-Reply-To: <20030723135658.62fe4b50.moore@cs.utk.edu> References: <265000-220037316193037308@M2W060.mail2web.com> <200307171130.15885.mellon@nominum.com> <323735266.1058895626@localhost> <014201c35140$61403320$8100000a@DFNJGL21> <20030723135658.62fe4b50.moore@cs.utk.edu> Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.3 (GTK+ 1.2.10; i386-unknown-freebsd4.8) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: Transcriptions (Re: Hearing and Speaking Problems for Non-Native Englishspeakingparticipants.) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit --> Keith Moore writes: > > It's worth noting that meeting audio/video for working groups meeting > > in MBONE-equipped rooms has been available for playback for a number > > of years, and I don't know that I've noticed any difference in > > behavior between MBONE sessions and non-MBONE sessions. > > During the brief time I was a WG chair I used to specifically request > non-MBONE rooms because I found it disruptive to force people to > queue at the microphone. Of course, this was for a relatively small > group. Once you have a few hundred people in the room you have to have > some access control mechanism - if not a microphone, then some other > sort of talking stick, recognition by the chair, etc. We actually do the opposite: request a room with multicast, so we can tap into the feed and record the meeting. I've found it to be very helpful in writing the minutes. Of course, this was for a group which was big enough to need room microphones anyway... Colin From problem-statement-bounces@alvestrand.no Wed Jul 23 15:34:03 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27506 for ; Wed, 23 Jul 2003 15:34:01 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6868561BAE; Wed, 23 Jul 2003 21:33:31 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from mtiwmhc11.worldnet.att.net (mtiwmhc11.worldnet.att.net [204.127.131.115]) by eikenes.alvestrand.no (Postfix) with ESMTP id D156061BAD for ; Wed, 23 Jul 2003 21:33:29 +0200 (CEST) Received: from tsg1 (190.sanjose-05-10rs16rt.ca.dial-access.att.net[12.81.6.190]) by mtiwmhc11.worldnet.att.net (mtiwmhc11) with SMTP id <2003072319332511100cef0pe>; Wed, 23 Jul 2003 19:33:26 +0000 Message-ID: <00cf01c35151$2d8bbfc0$020aff0a@tsg1> From: "todd glassey" To: "Marcus Brunner" , "James Kempf" , "Bound, Jim" , "Dave Crocker" , References: <9C422444DE99BC46B3AD3C6EAFC9711B03241074@tayexc13.americas.cpqcorp.net> <00b801c36a64$4a4d4e40$036015ac@T23KEMPF> <10334049.1058965490@[10.1.1.130]> Date: Wed, 23 Jul 2003 12:29:03 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: Re: making strategic problems concrete X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Marcus - I think Jim has some strong points here that need to be captured here. But the all boil down to whether the process of olde (that of the IETF of 20 years ago) still makes sense or can even survive a rudimentary legal attack for damages. My feeling is that today's IETF would be washed up the first time someone sues it for any number of issues and problems it has foist upon a group of its participants. More inline below. ----- Original Message ----- From: "Marcus Brunner" To: "James Kempf" ; "Bound, Jim" ; "Dave Crocker" ; Sent: Wednesday, July 23, 2003 4:04 AM Subject: Re: making strategic problems concrete > James, > > I have not seen another standardization organization having a better > solution. Agreeing is a long painful process, which we can not avoid. > > Marcus > > --On Sonntag, 24. August 2003 10:22 -0700 James Kempf > wrote: > > > Jim, > > > > I think another problem is sometimes there are just multiple possible > > designs with equally good technical properties, with minor tradeoffs in > > one direction or another. From an engineering standpoint, any of them > > might make sense. Yes this is true. > > From a market standpoint however, people want one to > > avoid costly investments in multiple different kinds of infrastructure. > > The difficulty is how to select one. I would disagree here though, it is not the IETF's role to control or decide what is and is not a standard. Its the IETF's role to see that all initiative get the same opportunities and treatment within its defined process. Let me amplify on this a bit, the IETF is not the decision gate for what is and what is not foisted or released onto the Internet, but rather an oracle to testify as to how well "it" works and as to whether "it" is operational with other protocols (the other "its"). The IETF then is not a lobby. It is not a guild where only people that pay the price get to play, and more importantly it IS the every-man's Internet Standards Group by its own charter. > > Using concensus may ultimately lead > > to the different parties simply failing to yield, or incorporating > > different parts of each design resulting in an overall design that is > > much more complex than really necessary. > > > > jak The other problem is that when you have a consensus based system you have a responsibility to show that the consensus was achieved reasonably and ethically and that there is a reliable history demonstrating this integrity. The IETF has NONE of this and that is the issue. There is no reliable accountability for the consensus process herein and that also is an issue... The real question is, that since the IETF was founded as a free, and open-to-all type of organization, as to whether it can continue to survive as such in todays world, which BTW is very different from the world of 20 years ago when the IETF's processes made more sense than they do today. > > > > > > > > ----- Original Message ----- > > From: "Bound, Jim" > > To: "Dave Crocker" ; > > Sent: Sunday, March 23, 2003 9:24 PM > > Subject: RE: making strategic problems concrete > > > > > >> > >> > >> > >> > 1) state precisely what fundamental operational problems they see > >> > > >> > eg., not just "we've gotten big" but rather "our getting > >> > big means attendees are not always seeking timely > >> > productive outcome" or "it takes too long to hear > >> > everyone's views" or...) > >> > 2) state precisely what fundamental organizational or > >> > operational changes they believe are called for (and how it > >> > will fix> the problem.) > >> > >> Technical work that has been accepted within the working group, which > >> also has strong technical proponents with different solutions, takes a > >> very long time to achieve compromise, and creates time-to-market barrier > >> for that technical work to achieve Proposed Standard, BCP, or even > >> Informational status. > >> > >> Not sure what the solution is totally but thinking, but I think the > >> complexity as was pointed out in the plenary on this topic at the podium > >> was that problems are interrelated and why this job here is hard. Trying > >> to fix it with SIRs is not going to work. > >> > >> A lot of the problems in the IETF are systemic from lack of trust. Here > >> are a few, that in turn creates operational problems. > >> > >> Consensus is not well defined, it permits a persistent reviewing of the > >> same topic over and over. It is good to revisit our ideas, but after > >> first agreement, having defined checkpoints, similar to project change > >> control in industry, would assist with when a previous consensus point > >> can be open for review. Or at least a process to do this so it is not > >> random and ad hoc. This would also permit a bad consensus decision to > >> be revisited and prevent it not being revisited if it has become broken. > >> > >> It is "perceived" that Design Teams, IESG, and just about everything we > >> do is a good ole boy network. I believe this is not done on purpose nor > >> the majority of efforts. But perception is reality. This creates > >> distrust and machavellian moves by factions within the working group to > >> do end run around the good ole boy network. This slows up the process > >> for any subject. We need an open and documented process for any ad hoc > >> groups like SIR. > >> > >> IESG members should not have anything to do with the Nom-Com it is like > >> the Government being in the voting booth with you. This creates a > >> distrust of our POISED process and a simple thing to fix. No one near > >> the NOMCOM from the IESG or IAB except for formal questions. If having > >> knowledge at the meeting then use past IESG/IAB members or ISOC > >> Trustees. > >> > >> Elistism. For example, when an AD says "this list" don't have this > >> expertise that's really bad unless that AD knows everyone really really > >> well on that list. I would argue that is not possible given the breadth > >> our ADs have to cover. Better they don't say things like this, and its > >> rude. > >> > >> Most specs run into WG trouble when the mission, goals, objective, > >> assumptions, and problem being addressed are not known until far to late > >> in the process. This causes a longer time to reach consensus for each > >> point with the proposed work. If each spec puts each of the above > >> attributes in the first section of its spec it will go a long way to > >> create a faster process. Specs should be able to define those in no > >> more than 4 sentences. It is also critical that assumptions be > >> discussed across the topic areas, because we often spend to much time in > >> debate of the solution when we did not realize our assumptions were > >> different. > >> > >> I will stop here for now. > >> > >> /jim > >> > >> > > > > > > -------------------------------------- > Dr. Marcus Brunner > Network Laboratories > NEC Europe Ltd. > > E-Mail: brunner@ccrle.nec.de > WWW: http://www.ccrle.nec.de/ > Phone: +49 (0) 6221 905 11 29 > Mobile: +49 (0) 163 275 17 43 > personal home page: http://www.brubers.org/marcus > > > > From problem-statement-bounces@alvestrand.no Wed Jul 23 15:52:44 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29066 for ; Wed, 23 Jul 2003 15:52:42 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3499061BB8; Wed, 23 Jul 2003 21:52:12 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by eikenes.alvestrand.no (Postfix) with ESMTP id 728BD61BB0 for ; Wed, 23 Jul 2003 21:52:10 +0200 (CEST) Received: from employees.org (171.68.223.137) by sj-iport-2.cisco.com with ESMTP; 23 Jul 2003 12:53:18 -0700 Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h6NJq5uI017632 for ; Wed, 23 Jul 2003 12:52:07 -0700 (PDT) Received: from cisco.com (sjc-vpn2-60.cisco.com [10.21.112.60]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id AIH12056; Wed, 23 Jul 2003 12:45:44 -0700 (PDT) Received: by cisco.com (sSMTP sendmail emulation); Wed, 23 Jul 2003 15:51:59 -0400 Date: Wed, 23 Jul 2003 15:51:59 -0400 From: Scott W Brim To: problem-statement@alvestrand.no Message-ID: <20030723155159.B2568@sbrim-w2k01> Mail-Followup-To: Scott W Brim , problem-statement@alvestrand.no References: <200307222202.AJW87618@mira-sjc5-c.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200307222202.AJW87618@mira-sjc5-c.cisco.com>; from mshore@cisco.com on Tue, Jul 22, 2003 at 06:02:57PM -0400 Subject: values etc. (was Re: A few hums) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no On Tue, Jul 22, 2003 06:02:57PM -0400, Melinda Shore allegedly wrote: > We took a hum to see if those present felt that we need to > define a process to identify values, mission, scope, and > goals. The hum was split. I'm against. From problem-statement-bounces@alvestrand.no Wed Jul 23 18:58:25 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06900 for ; Wed, 23 Jul 2003 18:58:24 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5361261BAD; Thu, 24 Jul 2003 00:57:55 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8D99961BAB for ; Thu, 24 Jul 2003 00:57:53 +0200 (CEST) Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h6NMvoQk028589 for ; Wed, 23 Jul 2003 15:57:51 -0700 (PDT) Received: from cisco.com (sjc-vpn2-60.cisco.com [10.21.112.60]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id AIH33840; Wed, 23 Jul 2003 15:51:23 -0700 (PDT) Received: by cisco.com (sSMTP sendmail emulation); Wed, 23 Jul 2003 18:57:39 -0400 Date: Wed, 23 Jul 2003 18:57:39 -0400 From: Scott W Brim To: problem-statement@alvestrand.no Message-ID: <20030723185739.E2568@sbrim-w2k01> Mail-Followup-To: Scott W Brim , problem-statement@alvestrand.no References: <200307222202.AJW87618@mira-sjc5-c.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200307222202.AJW87618@mira-sjc5-c.cisco.com>; from mshore@cisco.com on Tue, Jul 22, 2003 at 06:02:57PM -0400 Subject: English (was Re: A few hums) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no I agree with the hums on everything else, btw. On Tue, Jul 22, 2003 06:02:57PM -0400, Melinda Shore allegedly wrote: > In the discussion of whether or not there's a problem > accomodating ESL speakers, the discussion broadened a bit to > cover cultural issues, the hum indicated that those present > felt that we needed more text on this issue. Since I can't find any text at all right now, how about: The IETF has never decided to do anything about the known problems with language and verbal communication despite its increasing international participation. At this point there are serious difficulties for those who are not native speakers of English, in understanding presentations and arguments, in reading and understanding colloquial text, and in formulating responses in order to participate in the usual lively IETF discussion. There are also problems for those who speak English natively but are not used to the accent or dialect of another participant. The IETF needs to decide, explicitly, what it will or will not do about these issues. From problem-statement-bounces@alvestrand.no Thu Jul 24 04:23:41 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28592 for ; Thu, 24 Jul 2003 04:23:40 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3684361BB0; Thu, 24 Jul 2003 10:23:12 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from sequoia.muada.com (sequoia.muada.com [213.156.1.123]) by eikenes.alvestrand.no (Postfix) with ESMTP id 924E861BAF for ; Thu, 24 Jul 2003 10:23:10 +0200 (CEST) Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h6O8NlxS069111; Thu, 24 Jul 2003 10:23:47 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Thu, 24 Jul 2003 10:23:06 +0200 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) To: Scott W Brim From: Iljitsch van Beijnum In-Reply-To: <20030723185739.E2568@sbrim-w2k01> Message-Id: <0D45FC35-BDB0-11D7-B006-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Cc: problem-statement@alvestrand.no Subject: Re: English (was Re: A few hums) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit On donderdag, jul 24, 2003, at 00:57 Europe/Amsterdam, Scott W Brim wrote: > Since I can't find any text at all right now, how about: > The IETF has never decided to do anything about the known problems > with language and verbal communication despite its increasing > international participation. At this point there are serious > difficulties for those who are not native speakers of English, in > understanding presentations and arguments, in reading and > understanding colloquial text, and in formulating responses in order > to participate in the usual lively IETF discussion. There are also > problems for those who speak English natively but are not used to the > accent or dialect of another participant. The IETF needs to decide, > explicitly, what it will or will not do about these issues. This here is dangerously close to blowing the whole thing way out of proportion. Yes, it would be nicer to if I could use my native language, but I'm not waiting for all you guys to learn Dutch. I haven't worked with interpretation, but from what I see (UN, european parliament) it sucks. And the IETF can't afford it anyway. So I'll manage to get by in English. And guess what: most of your colloquialisms aren't that difficult to understand. (Now spelling, that's another matter.) There is enough evidence that non-native English speakers can function just fine within the IETF. Unfortunately, there are also examples to the contrary, at least to some degree, as some participants can be hard to understand. I do maintain that this has very likely something to do with the speed at which is spoken, so it should be possible to gain improvement here with some one-on-one feedback. What I'd really like to know is how many people would like to participate in the IETF but don't because of language issues. If this turns out to be a large number, more effort in this area is justified. But it could also be a negligible number, so no action is warranted. From problem-statement-bounces@alvestrand.no Thu Jul 24 06:20:25 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01228 for ; Thu, 24 Jul 2003 06:20:24 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 20FCD61BB4; Thu, 24 Jul 2003 12:19:57 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from netcore.fi (netcore.fi [193.94.160.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E108E61BAF for ; Thu, 24 Jul 2003 12:19:54 +0200 (CEST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6OAItN00365; Thu, 24 Jul 2003 13:18:55 +0300 Date: Thu, 24 Jul 2003 13:18:55 +0300 (EEST) From: Pekka Savola To: Iljitsch van Beijnum In-Reply-To: <0D45FC35-BDB0-11D7-B006-00039388672E@muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: problem-statement@alvestrand.no, Scott W Brim Subject: Re: English (was Re: A few hums) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no On Thu, 24 Jul 2003, Iljitsch van Beijnum wrote: > There is enough evidence that non-native English speakers can function > just fine within the IETF. Unfortunately, there are also examples to > the contrary, at least to some degree, as some participants can be hard > to understand. I do maintain that this has very likely something to do > with the speed at which is spoken, so it should be possible to gain > improvement here with some one-on-one feedback. > > What I'd really like to know is how many people would like to > participate in the IETF but don't because of language issues. If this > turns out to be a large number, more effort in this area is justified. > But it could also be a negligible number, so no action is warranted. Another problem I've seen, unfortunately, is that internet-drafts from certain people have been of *awful* language. In a document of a dozen pages, excluding the standard boilerplates, you can hardly find a sentence which does not break English grammar, spelling, choice of wrong words or be otherwise difficult to understand. Forcing people to review these seems like a waste of time from almost everyone's perspective. It just takes *considerably* more effort to do. Luckily enough this is rather rare, but happens nonetheless. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From problem-statement-bounces@alvestrand.no Thu Jul 24 09:55:29 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06470 for ; Thu, 24 Jul 2003 09:55:29 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3700B61BD8; Thu, 24 Jul 2003 15:55:00 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from ran.psg.com (ip166.usw12.rb1.bel.nwlink.com [209.20.253.166]) by eikenes.alvestrand.no (Postfix) with ESMTP id ED5DF61BB9 for ; Thu, 24 Jul 2003 15:54:57 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19fgYa-000KEr-JJ for problem-statement@alvestrand.no; Thu, 24 Jul 2003 06:54:56 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 24 Jul 2003 06:54:56 -0700 To: problem-statement@alvestrand.no References: <0D45FC35-BDB0-11D7-B006-00039388672E@muada.com> Message-Id: Subject: Re: English (was Re: A few hums) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit if we think we can solve the global multi-language/culture problem, why the heck don't we get real and work on world hunger and peace? let's face it, we live in a multi-lingual world, embarrassingly, american has become the lingua franca of our technology. there are some simple (but hard) things folk can do to make themselves easier to understand, speak slowly and clearly, use no idioms, have clear slides which help folk read along, etc. i would wager that there is some nice web page on this if we googled correctly. beyond that, yes it's a problem, but we ain't gonna fix it. randy From problem-statement-bounces@alvestrand.no Thu Jul 24 10:47:57 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09697 for ; Thu, 24 Jul 2003 10:47:56 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4DF6D61B9C; Thu, 24 Jul 2003 16:47:28 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from klapautius.it.su.se (as13-3-2.rny.s.bonet.se [217.215.166.49]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8F13761B94 for ; Thu, 24 Jul 2003 16:47:26 +0200 (CEST) Received: from it.su.se (localhost.localdomain [127.0.0.1]) by klapautius.it.su.se (8.11.6/8.11.6) with ESMTP id h6OEi5101741; Thu, 24 Jul 2003 16:44:05 +0200 Message-ID: <3F1FF0B4.4030204@it.su.se> Date: Thu, 24 Jul 2003 16:44:04 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Randy Bush References: <0D45FC35-BDB0-11D7-B006-00039388672E@muada.com> In-Reply-To: X-Enigmail-Version: 0.76.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: English (was Re: A few hums) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Randy Bush wrote: >if we think we can solve the global multi-language/culture problem, >why the heck don't we get real and work on world hunger and peace? > >let's face it, we live in a multi-lingual world, embarrassingly, >american has become the lingua franca of our technology. there >are some simple (but hard) things folk can do to make themselves >easier to understand, speak slowly and clearly, use no idioms, >have clear slides which help folk read along, etc. i would wager >that there is some nice web page on this if we googled correctly. > >beyond that, yes it's a problem, but we ain't gonna fix it. > >randy > > Really! Just consider us poor Swedes who are all taught to speak and write the Queen's English at school. How are we supposed to cope with "American" ?!? ;-) I believe the web-page you were looking for is http://www.geocities.com/CollegePark/6174/brit-queue-51st.htm MVH (I bet you don't know what that stands for either :-) ) leifj From problem-statement-bounces@alvestrand.no Thu Jul 24 11:08:18 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10272 for ; Thu, 24 Jul 2003 11:08:17 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1405361B9C; Thu, 24 Jul 2003 17:07:49 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from vmmr7.verisignmail.com (vmmrnat.verisignmail.com [216.168.230.187]) by eikenes.alvestrand.no (Postfix) with ESMTP id 76DBE61B9B for ; Thu, 24 Jul 2003 17:07:46 +0200 (CEST) Received: from ms3.verisignmail.com (ms3.verisignmail.com [216.168.230.176] (may be forged)) by vmmr7.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id OYR20101; Thu, 24 Jul 2003 11:06:56 -0400 (EDT) Received: from BOBDEV (pool-162-83-238-146.ny5030.east.verizon.net [162.83.238.146]) by ms3.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id ALJ96776; Thu, 24 Jul 2003 11:06:55 -0400 (EDT) From: "Bob Wyman" To: "'Scott W Brim'" , Date: Thu, 24 Jul 2003 11:07:09 -0400 Message-ID: <001201c351f5$411b4750$640aa8c0@BOBDEV> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: <20030723185739.E2568@sbrim-w2k01> Importance: Normal X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: RE: English (was Re: A few hums) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list Reply-To: bob@wyman.us List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: quoted-printable Sorry for entering solution space... However, it seems to me that it would make sense at future IETF meetings to do at least two things: 1. Provide a specific Sunday orientation for ESL attendees or add an optional "for-ESL folk" extension to the traditional orientation. While much of the content would be similar to the normal orientation meeting, this meeting would go at a slower pace and encourage "bonding" between attendees. If people with language difficulties can hook up with others at the meeting, they may be able to support each other in resolving confusions as the meetings progress. 2. Designate a specific area as a meeting place for ESL and/or non-English speaking attendees that would be open throughout the meeting. The idea would be to encourage people to go there to meet others in with similar problems and also for people who were willing to provide assistance to ESL attendees to have a way of meeting people who needed help. bob wyman -----Original Message----- From: problem-statement-bounces@alvestrand.no [mailto:problem-statement-bounces@alvestrand.no] On Behalf Of Scott W Brim Sent: Wednesday, July 23, 2003 6:58 PM To: problem-statement@alvestrand.no Subject: English (was Re: A few hums) I agree with the hums on everything else, btw. On Tue, Jul 22, 2003 06:02:57PM -0400, Melinda Shore allegedly wrote: > In the discussion of whether or not there's a problem accomodating ESL > speakers, the discussion broadened a bit to cover cultural issues, the > hum indicated that those present felt that we needed more text on this > issue. Since I can't find any text at all right now, how about: The IETF has never decided to do anything about the known problems with language and verbal communication despite its increasing international participation. At this point there are serious difficulties for those who are not native speakers of English, in understanding presentations and arguments, in reading and understanding colloquial text, and in formulating responses in order to participate in the usual lively IETF discussion. There are also problems for those who speak English natively but are not used to the accent or dialect of another participant. The IETF needs to decide, explicitly, what it will or will not do about these issues. From problem-statement-bounces@alvestrand.no Thu Jul 24 12:46:25 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13768 for ; Thu, 24 Jul 2003 12:46:24 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B459761BAC; Thu, 24 Jul 2003 18:45:57 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from mtiwmhc11.worldnet.att.net (mtiwmhc11.worldnet.att.net [204.127.131.115]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9494161B9C for ; Thu, 24 Jul 2003 18:45:55 +0200 (CEST) Received: from tsg1 (116.sanjose-06-07rs16rt.ca.dial-access.att.net[12.81.2.116]) by mtiwmhc11.worldnet.att.net (mtiwmhc11) with SMTP id <20030724164552111008b4ope>; Thu, 24 Jul 2003 16:45:53 +0000 Message-ID: <00bd01c35203$08c67830$020aff0a@tsg1> From: "todd glassey" To: "Leif Johansson" , "Randy Bush" References: <0D45FC35-BDB0-11D7-B006-00039388672E@muada.com> <3F1FF0B4.4030204@it.su.se> Date: Thu, 24 Jul 2003 08:00:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Cc: problem-statement@alvestrand.no Subject: Re: English (was Re: A few hums) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit What it sounds like we need is an official IETF lexicon. Or possibly at least a set of agreed upon common terms. Todd ----- Original Message ----- From: "Leif Johansson" To: "Randy Bush" Cc: Sent: Thursday, July 24, 2003 7:44 AM Subject: Re: English (was Re: A few hums) > Randy Bush wrote: > > >if we think we can solve the global multi-language/culture problem, > >why the heck don't we get real and work on world hunger and peace? > > > >let's face it, we live in a multi-lingual world, embarrassingly, > >american has become the lingua franca of our technology. there > >are some simple (but hard) things folk can do to make themselves > >easier to understand, speak slowly and clearly, use no idioms, > >have clear slides which help folk read along, etc. i would wager > >that there is some nice web page on this if we googled correctly. > > > >beyond that, yes it's a problem, but we ain't gonna fix it. > > > >randy > > > > > Really! Just consider us poor Swedes who are all taught to speak and > write the > Queen's English at school. How are we supposed to cope with "American" > ?!? ;-) > > I believe the web-page you were looking for is > > http://www.geocities.com/CollegePark/6174/brit-queue-51st.htm > > MVH (I bet you don't know what that stands for either :-) ) leifj > > > From problem-statement-bounces@alvestrand.no Thu Jul 24 13:44:23 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17750 for ; Thu, 24 Jul 2003 13:44:23 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 21C4C61BAE; Thu, 24 Jul 2003 19:43:54 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from klapautius.it.su.se (as13-3-2.rny.s.bonet.se [217.215.166.49]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6A0A961BAC for ; Thu, 24 Jul 2003 19:43:52 +0200 (CEST) Received: from it.su.se (localhost.localdomain [127.0.0.1]) by klapautius.it.su.se (8.11.6/8.11.6) with ESMTP id h6OHeR102519; Thu, 24 Jul 2003 19:40:27 +0200 Message-ID: <3F201A0B.5040202@it.su.se> Date: Thu, 24 Jul 2003 19:40:27 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: todd glassey References: <0D45FC35-BDB0-11D7-B006-00039388672E@muada.com> <3F1FF0B4.4030204@it.su.se> <00bd01c35203$08c67830$020aff0a@tsg1> In-Reply-To: <00bd01c35203$08c67830$020aff0a@tsg1> X-Enigmail-Version: 0.76.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Randy Bush , problem-statement@alvestrand.no Subject: Re: English (was Re: A few hums) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit todd glassey wrote: >What it sounds like we need is an official IETF lexicon. Or possibly at >least a set of agreed upon common terms. > > > Well, if the time spent deciding what MUST, MAY, SHOULD and friends mean is any indication of how long this will take, if we start quickly we should be done any century now... :-) MVH leifj From problem-statement-bounces@alvestrand.no Thu Jul 24 13:56:02 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18629 for ; Thu, 24 Jul 2003 13:56:02 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B325A61BAE; Thu, 24 Jul 2003 19:55:32 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from mtiwmhc13.worldnet.att.net (mtiwmhc13.worldnet.att.net [204.127.131.117]) by eikenes.alvestrand.no (Postfix) with ESMTP id E5BC961BAC for ; Thu, 24 Jul 2003 19:55:30 +0200 (CEST) Received: from tsg1 (116.sanjose-06-07rs16rt.ca.dial-access.att.net[12.81.2.116]) by mtiwmhc13.worldnet.att.net (mtiwmhc13) with SMTP id <2003072417552811300fbl8se>; Thu, 24 Jul 2003 17:55:28 +0000 Message-ID: <015401c3520c$c115ea70$020aff0a@tsg1> From: "todd glassey" To: "Leif Johansson" References: <0D45FC35-BDB0-11D7-B006-00039388672E@muada.com> <3F1FF0B4.4030204@it.su.se> <00bd01c35203$08c67830$020aff0a@tsg1> <3F201A0B.5040202@it.su.se> Date: Thu, 24 Jul 2003 10:55:16 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Cc: Randy Bush , problem-statement@alvestrand.no Subject: Re: English (was Re: A few hums) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Leif - their meaning was not the issue. The issue was how they were used and the rules for that use. What we are looking for here is not the use rules but the ideas themselves that we want to carve out. And I do understand your concerns too and support them as well, but the reality of this is that these terms really do need to be defined one would think... Todd ----- Original Message ----- From: "Leif Johansson" To: "todd glassey" Cc: "Randy Bush" ; Sent: Thursday, July 24, 2003 10:40 AM Subject: Re: English (was Re: A few hums) > todd glassey wrote: > > >What it sounds like we need is an official IETF lexicon. Or possibly at > >least a set of agreed upon common terms. > > > > > > > Well, if the time spent deciding what MUST, MAY, SHOULD and friends > mean is any indication of how long this will take, if we start quickly > we should > be done any century now... :-) > > MVH leifj > > > From problem-statement-bounces@alvestrand.no Thu Jul 24 14:30:40 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20164 for ; Thu, 24 Jul 2003 14:30:38 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7040761BB9; Thu, 24 Jul 2003 20:30:05 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from sequoia.muada.com (sequoia.muada.com [213.156.1.123]) by eikenes.alvestrand.no (Postfix) with ESMTP id 27C8661BB8 for ; Thu, 24 Jul 2003 20:30:04 +0200 (CEST) Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h6OIUfxS075602; Thu, 24 Jul 2003 20:30:41 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Thu, 24 Jul 2003 20:30:03 +0200 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) To: Cyrus Shaoul From: Iljitsch van Beijnum In-Reply-To: <20030724102852.A47A.CYRUS@ntt-at.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Cc: problem-statement@alvestrand.no Subject: Re: Re[2]: English (was Re: A few hums) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit On donderdag, jul 24, 2003, at 17:10 Europe/Amsterdam, Cyrus Shaoul wrote: > In rejoining the thread, I wanted to note that there are parts of the > world that have much less exposure to American English as compared to > the Netherlands or other countries in Western Europe. The fact that movies and tv are subtitled and not dubbed here in NL seems to make a difference as well. This certainly explains why my English has improved since high school while my German has only gotten worse, as I found out last week... But I can't imagine being involved in one of the areas of interest of the IETF and not at least reading a lot of English. > I talked to a > small number of people from India, Korea, China and Japan at the last > IETF meeting in Vienna (about 10 people), and they all told me that > they > felt left out and frustrated at some of the WG meetings. Do you mean that there are also people who don't feel frustrated and left out during wg meetings, not counting the inner circle with 25 IETF meetings down their belts? Did they tell you why they feel this way? > I don't think the situation is black-or-white with the all the European > participants either. There may be a significant minority of European > attendees who would have a much better understanding of what is going > on > if speakers spoke slower and more clearly, in plainer language. I don't think speaking slow in itself is of much value. It's just that many people try to speak too fast for reasons I can only imagine and this tends to get in the way of clear articulation. This is especially problematic if the speaker diverts from "generic" (American?) English. > I do agree with you that we need more information about the scale of > the > problem before deciding whether or not it is significant enought to act > on. I have lots of anecdotal evidence, but no hard data. I would love > to know how many people have already stopped attending IETF meetings > because of this problem. Unfortunately, it is hard to find out from > within the IETF who is no longer involved in the IETF, but we could > send > out a survey to all non-native English speakers currently subscribed to > all WG mailing lists (should this be done?). Why not contact people who used to come to the IETF meetings but don't anymore? > How large a number of > people complaining would you say would be needed to justify action? 100 > people? More? Less? I'd say that if less than 10% of all people who respond didn't stop coming because of language-related problems there is no reason to do anything. Above 35% we absolutely need to do something. From problem-statement-bounces@alvestrand.no Thu Jul 24 15:45:47 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26962 for ; Thu, 24 Jul 2003 15:45:46 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 54C4061BB9; Thu, 24 Jul 2003 21:45:18 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7A1D461BB8 for ; Thu, 24 Jul 2003 21:45:15 +0200 (CEST) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h6OJnCF20710; Thu, 24 Jul 2003 12:49:12 -0700 Date: Thu, 24 Jul 2003 12:45:07 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/11) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <19999391287.20030724124507@brandenburg.com> To: Randy Bush In-Reply-To: References: <0D45FC35-BDB0-11D7-B006-00039388672E@muada.com> MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: English (was Re: A few hums) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list Reply-To: Dave Crocker List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Randy, RB> if we think we can solve the global multi-language/culture problem, RB> why the heck don't we get real and work on world hunger and peace? 1. No one said "solve". 2. Thanks. Your responding with insulting hyperbole provides an excellent demonstration of one of the "cultural" concerns that needs to be worked on within the IETF. It is especially helpful to see that sort of supportive contribution from an Area Director. RB> let's face it, we live in a multi-lingual world, embarrassingly, RB> american has become the lingua franca of our technology. there RB> are some simple (but hard) things folk can do to make themselves RB> easier to understand, speak slowly and clearly, use no idioms, RB> have clear slides which help folk read along, etc. Oh. Nice of you to acknowledge that perhaps some things can be done. If everyone had your prior knowledge and distinctive sensitivity to linguistic and cultural issues, then the topic would not have come up. I guess it is ok to remind people to turn off mobile phones and pagers, but not to provide them with guidance about a speaking style that might be helpful to non-native English listeners. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Thu Jul 24 16:22:30 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28496 for ; Thu, 24 Jul 2003 16:22:29 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7BD3D61BB8; Thu, 24 Jul 2003 22:22:01 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by eikenes.alvestrand.no (Postfix) with ESMTP id C2EC561BB4 for ; Thu, 24 Jul 2003 22:21:59 +0200 (CEST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h6OKKYJ17276; Thu, 24 Jul 2003 16:20:36 -0400 (EDT) Date: Thu, 24 Jul 2003 16:20:34 -0400 From: Keith Moore To: Dave Crocker Message-Id: <20030724162034.3d550e32.moore@cs.utk.edu> In-Reply-To: <19999391287.20030724124507@brandenburg.com> References: <0D45FC35-BDB0-11D7-B006-00039388672E@muada.com> <19999391287.20030724124507@brandenburg.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: randy@psg.com, problem-statement@alvestrand.no, dhc@dcrocker.net, moore@cs.utk.edu Subject: Re: English (was Re: A few hums) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit > I guess it is ok to remind people to turn off mobile phones and > pagers, but not to provide them with guidance about a speaking style > that might be helpful to non-native English listeners. To me it seems perfectly appropriate and consistent with the goals of this WG to include in our list of problems a mention that non-native English speakers/listeners have difficulties participating in IETF. Since we are not working on solutions in this WG, we don't need to agree on the mechanism by which the problem is solved, or even whether the problem can be solved. For now, it is enough to recognize it as a problem. We are constructing this list of problems because we wish to understand the breadth of difficulties we face. By making ourselves aware of this breadth we hope to avoid crafting "solutions" which address some problems while making other problems worse. But we also need to keep in mind that many problems are inherently difficult to solve - and those related to differences in human language are far from the only difficult problems we face. So we should not expect that we can completely solve every problem on our list. Therefore, placing a problem on our list should not create an expectation that we will completely solve it. Neither should we avoid listing problems merely because we do not believe we can completely solve them. We will always have difficult problems. We will solve the ones we can, especially those that most impede our work. Hopefully we will still be able to accomplish useful work in spite of those that remain. From problem-statement-bounces@alvestrand.no Thu Jul 24 17:20:12 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01409 for ; Thu, 24 Jul 2003 17:20:11 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8BEBB61BAD; Thu, 24 Jul 2003 23:19:43 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from ran.psg.com (ip166.usw12.rb1.bel.nwlink.com [209.20.253.166]) by eikenes.alvestrand.no (Postfix) with ESMTP id F0F7461BAD for ; Thu, 24 Jul 2003 23:19:41 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19fnUy-00066P-6Y; Thu, 24 Jul 2003 14:19:40 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 24 Jul 2003 14:19:39 -0700 To: Dave Crocker References: <0D45FC35-BDB0-11D7-B006-00039388672E@muada.com> <19999391287.20030724124507@brandenburg.com> Message-Id: Cc: problem-statement@alvestrand.no Subject: Re: English (was Re: A few hums) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit glad to provide a soapbox for your ongoing demagoguery, dave. but do you have anything actually constructive to contribute? randy > RB> if we think we can solve the global multi-language/culture problem, > RB> why the heck don't we get real and work on world hunger and peace? > > 1. No one said "solve". > > 2. Thanks. Your responding with insulting hyperbole provides an > excellent demonstration of one of the "cultural" concerns that needs to > be worked on within the IETF. It is especially helpful to see that sort > of supportive contribution from an Area Director. > > > RB> let's face it, we live in a multi-lingual world, embarrassingly, > RB> american has become the lingua franca of our technology. there > RB> are some simple (but hard) things folk can do to make themselves > RB> easier to understand, speak slowly and clearly, use no idioms, > RB> have clear slides which help folk read along, etc. > > Oh. Nice of you to acknowledge that perhaps some things can be done. > > If everyone had your prior knowledge and distinctive sensitivity to > linguistic and cultural issues, then the topic would not have come up. > > I guess it is ok to remind people to turn off mobile phones and pagers, > but not to provide them with guidance about a speaking style that might > be helpful to non-native English listeners. > > d/ From problem-statement-bounces@alvestrand.no Thu Jul 24 18:20:34 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04470 for ; Thu, 24 Jul 2003 18:20:33 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5A66561BB4; Fri, 25 Jul 2003 00:20:06 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from seahorse.shentel.net (seahorse.shentel.net [204.111.11.44]) by eikenes.alvestrand.no (Postfix) with ESMTP id 81DAF61BAD for ; Fri, 25 Jul 2003 00:20:04 +0200 (CEST) Received: from Steve (ha96s289.d.shentel.net [204.111.97.33]) by seahorse.shentel.net (8.11.7/8.11.7) with SMTP id h6OMJH406367; Thu, 24 Jul 2003 18:19:19 -0400 From: "Steve Silverman" To: "Randy Bush" , "Dave Crocker" Date: Thu, 24 Jul 2003 18:20:38 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Cc: problem-statement@alvestrand.no Subject: RE: English (was Re: A few hums) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit A few steps that might help: All speakers to put the substance of what they are saying in words on the slides. People try to speak a little slower. (This is hard to remember especially when the chair says 1 minute more!) A distinction between questions for clarification (asking what is being said) versus comments on the material. The former should be taken first, preferably immediately. Some sort of signal (holding up a paper? or blue index cards?) might be used to signify a question of clarification. Steve Silverman > -----Original Message----- > From: problem-statement-bounces@alvestrand.no > [mailto:problem-statement-bounces@alvestrand.no]On Behalf > Of Randy Bush > Sent: Thursday, July 24, 2003 5:20 PM > To: Dave Crocker > Cc: problem-statement@alvestrand.no > Subject: Re: English (was Re: A few hums) > > > glad to provide a soapbox for your ongoing demagoguery, dave. but > do you have anything actually constructive to contribute? > > randy > > > RB> if we think we can solve the global > multi-language/culture problem, > > RB> why the heck don't we get real and work on world > hunger and peace? > > > > 1. No one said "solve". > > > > 2. Thanks. Your responding with insulting hyperbole provides an > > excellent demonstration of one of the "cultural" concerns > that needs to > > be worked on within the IETF. It is especially helpful to > see that sort > > of supportive contribution from an Area Director. > > > > > > RB> let's face it, we live in a multi-lingual world, > embarrassingly, > > RB> american has become the lingua franca of our > technology. there > > RB> are some simple (but hard) things folk can do to make > themselves > > RB> easier to understand, speak slowly and clearly, use no idioms, > > RB> have clear slides which help folk read along, etc. > > > > Oh. Nice of you to acknowledge that perhaps some things > can be done. > > > > If everyone had your prior knowledge and distinctive > sensitivity to > > linguistic and cultural issues, then the topic would not > have come up. > > > > I guess it is ok to remind people to turn off mobile > phones and pagers, > > but not to provide them with guidance about a speaking > style that might > > be helpful to non-native English listeners. > > > > d/ > > From problem-statement-bounces@alvestrand.no Thu Jul 24 18:58:19 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05252 for ; Thu, 24 Jul 2003 18:58:18 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C0A6661BB9; Fri, 25 Jul 2003 00:57:50 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from ran.psg.com (ip166.usw12.rb1.bel.nwlink.com [209.20.253.166]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9325B61BAD for ; Fri, 25 Jul 2003 00:57:49 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19fp1v-000AhH-Vm; Thu, 24 Jul 2003 15:57:48 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 24 Jul 2003 15:57:47 -0700 To: "Steve Silverman" References: Message-Id: Cc: problem-statement@alvestrand.no Subject: RE: English (was Re: A few hums) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit > All speakers to put the substance of what they are saying in words on > the slides. > People try to speak a little slower. (This is hard to remember > especially when the chair says 1 minute more!) > A distinction between questions for clarification (asking what is > being said) versus > comments on the material. The former should be taken first, > preferably immediately. > Some sort of signal (holding up a paper? or blue index cards?) might > be used to signify a question of clarification. yep. thanks for helping expand on my over-terseness. RB>> there are some simple (but hard) things folk can do to make RB>> themselves easier to understand, speak slowly and clearly, use RB>> no idioms, have clear slides which help folk read along, etc. but this issue is not at all unique to the ietf, computing, etc. so i still wonder if RB>> i would wager that there is some nice web page on this if we RB>> googled correctly. randy From problem-statement-bounces@alvestrand.no Thu Jul 24 21:18:19 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07651 for ; Thu, 24 Jul 2003 21:18:18 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1A3C461B9F; Fri, 25 Jul 2003 03:17:49 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from relay.cosmoweb.net (relay.cosmoweb.net [66.234.224.17]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9EA4F61B9C for ; Thu, 24 Jul 2003 17:11:05 +0200 (CEST) Received: from [127.0.0.1] (181-234-234-66.cosmoweb.net [66.234.234.181]) by relay.cosmoweb.net (8.11.6/8.11.6) with ESMTP id h6OGgeO18806; Thu, 24 Jul 2003 12:42:40 -0400 Date: Thu, 24 Jul 2003 11:10:13 -0400 From: Cyrus Shaoul To: Iljitsch van Beijnum , Scott W Brim , problem-statement@alvestrand.no In-Reply-To: <0D45FC35-BDB0-11D7-B006-00039388672E@muada.com> References: <20030723185739.E2568@sbrim-w2k01> <0D45FC35-BDB0-11D7-B006-00039388672E@muada.com> Message-Id: <20030724102852.A47A.CYRUS@ntt-at.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.05.11 X-Mailman-Approved-At: Fri, 25 Jul 2003 03:17:48 +0200 Subject: Re[2]: English (was Re: A few hums) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Iljitsch, In rejoining the thread, I wanted to note that there are parts of the world that have much less exposure to American English as compared to the Netherlands or other countries in Western Europe. I talked to a small number of people from India, Korea, China and Japan at the last IETF meeting in Vienna (about 10 people), and they all told me that they felt left out and frustrated at some of the WG meetings. (There are some Asian attendees who have no difficulties participating, but I feel that they are the exception, not the rule). I don't think the situation is black-or-white with the all the European participants either. There may be a significant minority of European attendees who would have a much better understanding of what is going on if speakers spoke slower and more clearly, in plainer language. I do agree with you that we need more information about the scale of the problem before deciding whether or not it is significant enought to act on. I have lots of anecdotal evidence, but no hard data. I would love to know how many people have already stopped attending IETF meetings because of this problem. Unfortunately, it is hard to find out from within the IETF who is no longer involved in the IETF, but we could send out a survey to all non-native English speakers currently subscribed to all WG mailing lists (should this be done?). How large a number of people complaining would you say would be needed to justify action? 100 people? More? Less? (I should finally note there there are other barriers besides language that may prevent people from participating, among them: money for travel and lodging, registration fees and visa difficulties. I think that they should be addressed as well, but for now let's focus on language.) Thanks, Cyrus On Thu, 24 Jul 2003 10:23:06 +0200 Iljitsch van Beijnum wrote: IvB> On donderdag, jul 24, 2003, at 00:57 Europe/Amsterdam, Scott W Brim IvB> wrote: IvB> IvB> > Since I can't find any text at all right now, how about: IvB> IvB> > The IETF has never decided to do anything about the known problems IvB> > with language and verbal communication despite its increasing IvB> > international participation. At this point there are serious IvB> > difficulties for those who are not native speakers of English, in IvB> > understanding presentations and arguments, in reading and IvB> > understanding colloquial text, and in formulating responses in order IvB> > to participate in the usual lively IETF discussion. There are also IvB> > problems for those who speak English natively but are not used to the IvB> > accent or dialect of another participant. The IETF needs to decide, IvB> > explicitly, what it will or will not do about these issues. IvB> IvB> This here is dangerously close to blowing the whole thing way out of IvB> proportion. Yes, it would be nicer to if I could use my native IvB> language, but I'm not waiting for all you guys to learn Dutch. I IvB> haven't worked with interpretation, but from what I see (UN, european IvB> parliament) it sucks. And the IETF can't afford it anyway. So I'll IvB> manage to get by in English. And guess what: most of your IvB> colloquialisms aren't that difficult to understand. (Now spelling, IvB> that's another matter.) IvB> IvB> There is enough evidence that non-native English speakers can function IvB> just fine within the IETF. Unfortunately, there are also examples to IvB> the contrary, at least to some degree, as some participants can be hard IvB> to understand. I do maintain that this has very likely something to do IvB> with the speed at which is spoken, so it should be possible to gain IvB> improvement here with some one-on-one feedback. IvB> IvB> What I'd really like to know is how many people would like to IvB> participate in the IETF but don't because of language issues. If this IvB> turns out to be a large number, more effort in this area is justified. IvB> But it could also be a negligible number, so no action is warranted. Cyrus Shaoul NTT Advanced Technology Corp. cyrus@ntt-at.com http://www.ntt-at.com/ From problem-statement-bounces@alvestrand.no Thu Jul 24 21:18:22 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07666 for ; Thu, 24 Jul 2003 21:18:21 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D41CF61BB8; Fri, 25 Jul 2003 03:17:49 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from relay.cosmoweb.net (relay.cosmoweb.net [66.234.224.17]) by eikenes.alvestrand.no (Postfix) with ESMTP id BC82461BB8 for ; Thu, 24 Jul 2003 22:03:11 +0200 (CEST) Received: from [127.0.0.1] (181-234-234-66.cosmoweb.net [66.234.234.181]) by relay.cosmoweb.net (8.11.6/8.11.6) with ESMTP id h6OLZeO03452; Thu, 24 Jul 2003 17:35:40 -0400 Date: Thu, 24 Jul 2003 16:03:08 -0400 From: Cyrus Shaoul To: Iljitsch van Beijnum , problem-statement@alvestrand.no In-Reply-To: References: <20030724102852.A47A.CYRUS@ntt-at.com> Message-Id: <20030724153531.A495.CYRUS@ntt-at.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.05.11 X-Mailman-Approved-At: Fri, 25 Jul 2003 03:17:48 +0200 Subject: Re[4]: English (was Re: A few hums) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit On Thu, 24 Jul 2003 20:30:03 +0200 Iljitsch van Beijnum wrote: IvB> But I can't imagine being involved in one of the areas of interest of IvB> the IETF and not at least reading a lot of English. True, but I think that reading and writing is much easier to learn from hearing and speaking. As hard to believe as it may seem, some people at IETF meetings are fluent readers and writers of English (even authors of Internet Drafts that contain no errors of English grammar or usage), but can't speak or understand spoken English well at all. IvB> Do you mean that there are also people who don't feel frustrated and IvB> left out during wg meetings, not counting the inner circle with 25 IETF IvB> meetings down their belts? Touche. Perhaps there are different degrees of frustration. Perhaps everybody would benefit, including native English speaking IETF first-timers, if awareness of this problem could be raised. IvB> Did they tell you why they feel this way? The overlapping parts of their comments were that some speakers spoke too quickly, some answered questions at native-speed to oblivious non-native English speaking questioners, some speakers rushed through their slides so fast that they could only read one or two lines because they read slower than native-readers, and many other issues. The point is that they were having language-related problems, and they felt that speakers and questioners were oblivious to this. Some of them told me that they have studied written English for 10 years or more, and are working hard to improve their English hearing and speaking, but that it takes many years of practice to master the fluency needed to fully participate in an IETF-meeting-level discussion. (Remember, most Asian languages share no roots, vocabulary or writing system with English). [Side note: With packed agendas, most presenters get 10-15 minutes at WG meetings. For some reason, many people decide to pack as much content into those 10 minutes as possible, and then are forced to rush through their presentations. Is this a related problem?] IvB> > I don't think the situation is black-or-white with the all the European IvB> > participants either. There may be a significant minority of European IvB> > attendees who would have a much better understanding of what is going IvB> > on IvB> > if speakers spoke slower and more clearly, in plainer language. IvB> IvB> I don't think speaking slow in itself is of much value. It's just that IvB> many people try to speak too fast for reasons I can only imagine and IvB> this tends to get in the way of clear articulation. This is especially IvB> problematic if the speaker diverts from "generic" (American?) English. Agreed. IvB> > I do agree with you that we need more information about the scale of IvB> > the IvB> > problem before deciding whether or not it is significant enought to act IvB> > on. I have lots of anecdotal evidence, but no hard data. I would love IvB> > to know how many people have already stopped attending IETF meetings IvB> > because of this problem. Unfortunately, it is hard to find out from IvB> > within the IETF who is no longer involved in the IETF, but we could IvB> > send IvB> > out a survey to all non-native English speakers currently subscribed to IvB> > all WG mailing lists (should this be done?). IvB> IvB> Why not contact people who used to come to the IETF meetings but don't IvB> anymore? Would the IETF registrar have this information? Just knowing the non-native English speaker attrition rate could be interesting (again, they could be leaving for other reasons, so we would need to ask them directly). IvB> IvB> > How large a number of IvB> > people complaining would you say would be needed to justify action? 100 IvB> > people? More? Less? IvB> IvB> I'd say that if less than 10% of all people who respond didn't stop IvB> coming because of language-related problems there is no reason to do IvB> anything. Above 35% we absolutely need to do something. Perhaps those are good guidelines. I need to think about the metrics a little more before I can give my opinion. To the Chairs: Is there enough interest to do such a survey? Are there other items that would go on this survey? Are surveys out of scope? Thanks, Cyrus Cyrus Shaoul NTT Advanced Technology Corp. cyrus@ntt-at.com http://www.ntt-at.com/ From problem-statement-bounces@alvestrand.no Fri Jul 25 10:01:11 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05260 for ; Fri, 25 Jul 2003 10:01:04 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6168961BB0; Fri, 25 Jul 2003 16:00:34 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5B74F61BAD for ; Fri, 25 Jul 2003 16:00:32 +0200 (CEST) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h6PE4TF32312; Fri, 25 Jul 2003 07:04:29 -0700 Date: Fri, 25 Jul 2003 07:00:22 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/11) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <133165103486.20030725070022@brandenburg.com> To: Randy Bush In-Reply-To: References: <0D45FC35-BDB0-11D7-B006-00039388672E@muada.com> <19999391287.20030724124507@brandenburg.com> MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Cc: problem-statement@alvestrand.no, Dave Crocker Subject: Re: English (was Re: A few hums) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list Reply-To: Dave Crocker List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Randy, RB> glad to provide a soapbox for your ongoing demagoguery, dave. but RB> do you have anything actually constructive to contribute? Changing your postings from a) misrepresenting what is said and then invoking hyperbole to dismiss what was not actually said, to b) "thanks for helping expand on my over-terseness" is significantly constructive for everyone else. However you need to review the definition of 'demagogue' Randy. You are the AD, not ID. And you started with an attack on a serious issue, not I. And if you find the words "hyperbole" and "insult" to be emotional, then you need to look more closely at their definitions and your posting style. As to "ongoing", Randy, you really are inviting a review of *both* our posting histories, aren't you? d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Sun Jul 27 13:13:01 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19734 for ; Sun, 27 Jul 2003 13:13:00 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 187A361B8E; Sun, 27 Jul 2003 19:11:58 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by eikenes.alvestrand.no (Postfix) with ESMTP id B7E4761B8A for ; Sun, 27 Jul 2003 19:11:55 +0200 (CEST) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h6RHFua31107 for ; Sun, 27 Jul 2003 10:15:56 -0700 Date: Sun, 27 Jul 2003 10:11:48 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/11) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1597458608.20030727101148@brandenburg.com> To: problem-statement@alvestrand.no In-Reply-To: <5364132.1058519874@localhost> References: <5364132.1058519874@localhost> MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Subject: Re: Straw process outline for dealing with structural and practices problems X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list Reply-To: Dave Crocker List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Folks, JCK> And that brings me back to my Thursday evening comment. I JCK> think it is time to _do_ something, not design structures for JCK> talking about what to do. I think we should go through the John and others have raised a number of concerns about a number of proposals, notably the one coming from a subset of the problem-statement editors' team. I was/am part of that team, but did not contribute to the proposal, except for a quick, late-stage review. I think we need to pursue some very separate lines of discussion, to give this whole topic proper consideration. What follows separates discussion of the timing of change, the source of proposals for change, and the authority for making decisions about change. 1. TIMING OF CHANGE I keep pointing out how long it has been since Yokohama, because this much passage of time, with no change, suggests that the actual operation of the IETF is proving to be more interested in discussing process than in improving our work... by making changes that will have real and useful effect. (No, I don't believe anyone actually intends this to be true, but so far, our actions show the truth of that fact.) I also point it out because it means that we are suffering the same problem with timeliness in our change effort as we do in our protocol development: loss of market window. In other words, loss of opportunity and relevance. In this case, the "market window" has to do with the attitudes of participants. When folks feel a deep sense of frustration and the frustration does not get resolved anytime soon, folks will typically give up. This fact plays heavily on the interpretations and validity we can assert, about "feedback" we are getting during our continuing process. (For the statistically inclined, think of this as biasing the sample.) So, the calls from a number of folks to start making changes, rather than to continue talking about the process of change, seems is entirely appropriate. The fact that it is coming from a number of independent participants -- and I continue to be amused when John K. and I agree on a topic's recommendation phase, not just its analysis phase -- should carry some weight. 2. SOURCE OF CHANGE PROPOSALS At this point, quite a few people/groups are suggesting that the source of useful proposals for change need to come from... The IETF populace and not from specially "authorized" representatives. There is an key, implicit message here, folks. Ultimately, this is "our" organization and we call for the specifics of change, not just the concept of change. Yokohama made clear that change is needed, but it did not specify the details. The details are in the specifics of careful proposals. They must come from us. The fact that this perspective seems to be coming from a number of very independent sources suggests that it is not all that controversial. At the least, I haven't seen a serious alternative to it proposed recently. The bottom line from this is that we need concrete, detailed proposals for concrete, specific changes, backed by their rationale. Some are starting to emerge. What is essential is that anyone having an idea that is not yet written down and available for review needs to do that work. Anyone. As in, not just our "leaders" and not just some designated committee. Anyone and Everyone. 3. AUTHORITY TO ADOPT SPECIFIC CHANGES So, given a panoply of concrete, detailed, serious proposals, how does the IETF choose ones to implement? Here lies the divergence of views. (And frankly, I was getting tired of agreeing with John so much.) Some suggest the IESG. Some suggest a blue-ribbon committee. Some suggest the IETF Plenary. I now believe all those ideas are fundamentally flawed, though I remain somewhat biased towards the last of these, though it too is flawed. The universal flaw is that all of them ignore the real need for real, broad, community support. Whatever is chosen, the community has to embrace it. This being a community of rather independent personalities, embracing does not occur because someone dictates it. The IESG has no history deciding what process changes are best for the IETF. Further, its members have no special expertise in such design and selection. Choosing some decision mechanism other than the IESG does not imply that we are in melt-down or that the IESG is incompetent. It suggests that that is a body with different skills and perspective than is appropriate for this category of decision-making. A select, "blue-ribbon" committee is always an appealing idea, and always suspect. It, too, has no track record of success for the decision it is making. Unfortunately, there is no existing IETF-related body that does have that track record or that even obviously has the necessary skills about organizational design and change. The Elwyn-et-al proposal invokes an multi-source sampling mechanism for populating the committee. I've come to cherish the benefit of ANY diverse sampling technique, for populating a decision-making group that is intended to represent a larger community, as long as it has any reasonable basis. In particular, there needs to be some assurance that the folks being chosen are likely to be clueful. Its key strength is that it ensures a real diversity of views (and agendas.) Hence, it works on independent contributions. This forces a negotiation and compromise process. The problem with using an IETF Plenary session as the decision-making body is that it may well be too highly biased (limited) a sample of the population. Ultimately, however, I believe that the real decision-making needs to be done by garnering strong support from the community. I won't go as far as invoking the usual "rough consensus" criterion, because we now have quite a bit of experience showing how difficult that can be to acquire or gauge, for "social" decisions. And let's be clear that that is the realm we are in. This is human and group stuff, not technical. So, few if any of us have any real skills in this. Worse, finding folks who *do* have those skills does not solve the problem. In fact, there is no way to guarantee that any proposal will work as intended or even that it will work well. That is the sad fact of life about this type of organizational change, especially for a group this diverse and diffuse. To me, that means the only thing we can do is to make sure that the decision is as broadly-shared as we can make it. This begins by developing a constituency of support for a candidate proposal. The nice things about such a direction of effort is that it lessens the import of choosing the best group to make the "final" decision. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Sun Jul 27 15:22:40 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22599 for ; Sun, 27 Jul 2003 15:22:39 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7008C61B8E; Sun, 27 Jul 2003 21:22:10 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by eikenes.alvestrand.no (Postfix) with ESMTP id 813B761B8A for ; Sun, 27 Jul 2003 21:22:08 +0200 (CEST) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h6RJQAa03973 for ; Sun, 27 Jul 2003 12:26:10 -0700 Date: Sun, 27 Jul 2003 12:22:03 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/11) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <50105274126.20030727122203@brandenburg.com> To: problem-statement@alvestrand.no MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-15 Content-transfer-encoding: 8bit Subject: Sampling X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list Reply-To: Dave Crocker List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 8bit Folks, The latter part of a posting by John cites statistic issues. I'd like to explore that issue separately and carefully: JCK> I think it is interesting, and _very_ important, to try to JCK> understand why the impression of the sentiment of the Problem WG JCK> and the response from the Plenary were so different. JCK> (1) Regardless of the _authority_ of the plenary, significantly JCK> more IETF participants were sitting there, raising hands, and JCK> generally expressing opinions than have been participating JCK> actively and observably in the Problem WG. Unless there is JCK> evidence that the plenary was somehow "packed" --and I saw I believe that both the working group participation and the IETF Vienna plenary presentation represent very, very highly biased samples of the IETF population. Sampling bias does not require intentional "packing". It requires selection methods that make the group unrepresentative of the total population. In this case, we had a smaller-than-expected total IETF meeting attendance, in a venue that prevented significant numbers of regular participants from attending. And not all of the meeting attendees were Plenary attendees. Notably, we have not paid much enough attention to just how small the participation in the Problems working group has been. And the recent Plenary had all sorts of confusion to this discussion. Overall, we need to be very circumspect in making decisions based on either bits of input. So it is not in the least surprising that the two, differently biased samples would produce different results. JCK> This has created a statistical bias between the composition and JCK> opinions of the self-selected WG and that of the community. yes, but... JCK> In other words, the WG has become an island, having discussions and JCK> reaching conclusions that are out of touch with the IETF universe. In all likelihood, so was the Plenary. At the least, the discussion was confused and confusing. JCK> Sometimes, because of its composition, a ... Overall, a nicely assessed and written statement, I think. However the call for Last Call review can (and does) lead to re-synchronization far too late, I believe. We need to make sure that there are ways of doing synchronization with the community early and often. Even waiting for a Plenary presentation might be too infrequently. Perhaps we need tight, summary "presentations" on the Announce-list, occasionally. We might think of these as "phase" Last Calls, or somesuch. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Mon Jul 28 03:39:28 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21542 for ; Mon, 28 Jul 2003 03:39:27 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2E6F261BB1; Mon, 28 Jul 2003 09:38:58 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [194.196.100.234]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4F74F61B92 for ; Mon, 28 Jul 2003 09:38:56 +0200 (CEST) Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by d12lmsgate.de.ibm.com (8.12.9/8.12.8) with ESMTP id h6S7csEN086690 for ; Mon, 28 Jul 2003 09:38:54 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h6S7csfZ283320 for ; Mon, 28 Jul 2003 09:38:54 +0200 Received: from zurich.ibm.com (dhcp22-107.zurich.ibm.com [9.4.22.107]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id JAA20068 for ; Mon, 28 Jul 2003 09:38:53 +0200 Message-ID: <3F24D30F.1718B639@zurich.ibm.com> Date: Mon, 28 Jul 2003 09:38:55 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: problem-statement@alvestrand.no References: <200307222202.AJW87618@mira-sjc5-c.cisco.com> <20030723155159.B2568@sbrim-w2k01> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Scope (was Re: values etc. (was Re: A few hums)) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Scott W Brim wrote: > > On Tue, Jul 22, 2003 06:02:57PM -0400, Melinda Shore allegedly wrote: > > We took a hum to see if those present felt that we need to > > define a process to identify values, mission, scope, and > > goals. The hum was split. > > I'm against. I'm split. I have believed for years that we need a definition of what is in or out of scope (even if the definition cannot be rigid). But values, mission, goals are in RFC 3160. Brian - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM NEW ADDRESS PLEASE UPDATE ADDRESS BOOK From problem-statement-bounces@alvestrand.no Mon Jul 28 05:22:36 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25053 for ; Mon, 28 Jul 2003 05:22:35 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7B34061BB1; Mon, 28 Jul 2003 11:22:06 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from znsgs01r.nortelnetworks.com (h35s128a211n47.user.nortelnetworks.com [47.211.128.35]) by eikenes.alvestrand.no (Postfix) with ESMTP id BCE0761B92 for ; Mon, 28 Jul 2003 11:22:04 +0200 (CEST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.160.46.124]) by znsgs01r.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h6S9LsT28290; Mon, 28 Jul 2003 10:21:54 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Jul 2003 10:21:55 +0100 Message-ID: <4103264BC8D3D51180B7002048400C45016235B6@zhard0jd.europe.nortel.com> From: "Elwyn Davies" To: "'Dave Crocker'" , problem-statement@alvestrand.no Date: Mon, 28 Jul 2003 10:21:51 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C354E9.AD97858C" Subject: RE: Straw process outline for dealing with structural and practic es problems X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C354E9.AD97858C Content-Type: text/plain; charset="iso-8859-1" Hi. Perhaps we should have reversed the order of the text of the proposals: I agree that we need to start producing ideas for solutions NOW, and that was part of the straw process although it was said late on. The exact mechanics of the selection/compromise/synthesis process are moot until it has something to work on. So let this be a call to arms! Whether you think the problem statement, as it is, is right or not, if you (singular or a group) have ideas for a fix or a way forwards for some part of the problem as you perceive it, get it written down and put it in front of the community as soon as possible. We can work on an acceptance process in parallel. Regards, Elwyn > -----Original Message----- > From: Dave Crocker [mailto:dhc@dcrocker.net] > Sent: 27 July 2003 18:12 > To: problem-statement@alvestrand.no > Subject: Re: Straw process outline for dealing with structural and > practices problems > > > Folks, > > JCK> And that brings me back to my Thursday evening comment. I > JCK> think it is time to _do_ something, not design structures for > JCK> talking about what to do. I think we should go through the > > John and others have raised a number of concerns about a number of > proposals, notably the one coming from a subset of the > problem-statement > editors' team. I was/am part of that team, but did not > contribute to the > proposal, except for a quick, late-stage review. > > I think we need to pursue some very separate lines of discussion, to > give this whole topic proper consideration. What follows separates > discussion of the timing of change, the source of proposals > for change, > and the authority for making decisions about change. > > > 1. TIMING OF CHANGE > > I keep pointing out how long it has been since Yokohama, because this > much passage of time, with no change, suggests that the > actual operation > of the IETF is proving to be more interested in discussing > process than > in improving our work... by making changes that will have real and > useful effect. (No, I don't believe anyone actually intends this to be > true, but so far, our actions show the truth of that fact.) > > I also point it out because it means that we are suffering the same > problem with timeliness in our change effort as we do in our protocol > development: loss of market window. In other words, loss of > opportunity > and relevance. > > In this case, the "market window" has to do with the attitudes of > participants. When folks feel a deep sense of frustration and the > frustration does not get resolved anytime soon, folks will typically > give up. This fact plays heavily on the interpretations and > validity we > can assert, about "feedback" we are getting during our continuing > process. (For the statistically inclined, think of this as biasing the > sample.) > > So, the calls from a number of folks to start making changes, rather > than to continue talking about the process of change, seems > is entirely > appropriate. The fact that it is coming from a number of independent > participants -- and I continue to be amused when John K. and > I agree on > a topic's recommendation phase, not just its analysis phase -- should > carry some weight. > > > 2. SOURCE OF CHANGE PROPOSALS > > At this point, quite a few people/groups are suggesting that > the source > of useful proposals for change need to come from... The IETF populace > and not from specially "authorized" representatives. > > There is an key, implicit message here, folks. Ultimately, this is > "our" organization and we call for the specifics of change, > not just the > concept of change. Yokohama made clear that change is needed, but it > did not specify the details. The details are in the specifics of > careful proposals. They must come from us. > > The fact that this perspective seems to be coming from a > number of very > independent sources suggests that it is not all that controversial. At > the least, I haven't seen a serious alternative to it > proposed recently. > > The bottom line from this is that we need concrete, detailed proposals > for concrete, specific changes, backed by their rationale. Some are > starting to emerge. > > What is essential is that anyone having an idea that is not > yet written > down and available for review needs to do that work. > > Anyone. > > As in, not just our "leaders" and not just some designated committee. > > Anyone and Everyone. > > > 3. AUTHORITY TO ADOPT SPECIFIC CHANGES > > So, given a panoply of concrete, detailed, serious proposals, how does > the IETF choose ones to implement? Here lies the divergence of views. > (And frankly, I was getting tired of agreeing with John so much.) > > Some suggest the IESG. Some suggest a blue-ribbon committee. Some > suggest the IETF Plenary. > > I now believe all those ideas are fundamentally flawed, > though I remain > somewhat biased towards the last of these, though it too is flawed. > > The universal flaw is that all of them ignore the real need for real, > broad, community support. Whatever is chosen, the community has to > embrace it. This being a community of rather independent > personalities, > embracing does not occur because someone dictates it. > > The IESG has no history deciding what process changes are best for the > IETF. Further, its members have no special expertise in such > design and > selection. Choosing some decision mechanism other than the > IESG does not > imply that we are in melt-down or that the IESG is incompetent. It > suggests that that is a body with different skills and > perspective than > is appropriate for this category of decision-making. > > A select, "blue-ribbon" committee is always an appealing idea, and > always suspect. It, too, has no track record of success for the > decision it is making. Unfortunately, there is no existing > IETF-related body that does have that track record or that even > obviously has the necessary skills about organizational design and > change. > > The Elwyn-et-al proposal invokes an multi-source sampling > mechanism for > populating the committee. I've come to cherish the benefit of ANY > diverse sampling technique, for populating a decision-making > group that > is intended to represent a larger community, as long as it has any > reasonable basis. In particular, there needs to be some assurance that > the folks being chosen are likely to be clueful. Its key strength is > that it ensures a real diversity of views (and agendas.) > Hence, it works > on independent contributions. This forces a negotiation and compromise > process. > > The problem with using an IETF Plenary session as the decision-making > body is that it may well be too highly biased (limited) a > sample of the > population. > > Ultimately, however, I believe that the real decision-making > needs to be > done by garnering strong support from the community. I won't go as far > as invoking the usual "rough consensus" criterion, because we now have > quite a bit of experience showing how difficult that can be to acquire > or gauge, for "social" decisions. > > And let's be clear that that is the realm we are in. This is human and > group stuff, not technical. So, few if any of us have any > real skills in > this. Worse, finding folks who *do* have those skills does > not solve the > problem. In fact, there is no way to guarantee that any proposal will > work as intended or even that it will work well. That is the > sad fact of > life about this type of organizational change, especially for a group > this diverse and diffuse. > > To me, that means the only thing we can do is to make sure that the > decision is as broadly-shared as we can make it. This begins by > developing a constituency of support for a candidate proposal. > > The nice things about such a direction of effort is that it > lessens the > import of choosing the best group to make the "final" decision. > > d/ > -- > Dave Crocker > Brandenburg InternetWorking > Sunnyvale, CA USA , > > ------_=_NextPart_001_01C354E9.AD97858C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Straw process outline for dealing with structural and = practices problems

Hi.

Perhaps we should have reversed the order of the text = of the proposals:
I agree that we need to start producing ideas for = solutions NOW, and that was part of the straw process although it was = said late on.  The exact mechanics of the = selection/compromise/synthesis process are moot until it has something = to work on.

So let this be a call to arms!

Whether you think the problem statement, as it is, is = right or not, if you (singular or a group) have ideas for a fix or a = way forwards for some part of the problem as you perceive it, get it = written down and put it in front of the community as soon as = possible.

We can work on an acceptance process in = parallel.

Regards,
Elwyn

> -----Original Message-----
> From: Dave Crocker [mailto:dhc@dcrocker.net]
> Sent: 27 July 2003 18:12
> To: problem-statement@alvestrand.no
> Subject: Re: Straw process outline for dealing = with structural and
> practices problems
>
>
> Folks,
>
> JCK> And that brings me back to my Thursday = evening comment.  I
> JCK> think it is time to _do_ something, not = design structures for
> JCK> talking about what to = do.    I think we should go through the
>
> John and others have raised a number of = concerns about a number of
> proposals, notably the one coming from a subset = of the
> problem-statement
> editors' team. I was/am part of that team, but = did not
> contribute to the
> proposal, except for a quick, late-stage = review.
>
> I think we need to pursue some very separate = lines of discussion, to
> give this whole topic proper = consideration.  What follows separates
> discussion of the timing of change, the source = of proposals
> for change,
> and the authority for making decisions about = change.
>
>
> 1.  TIMING OF CHANGE
>
> I keep pointing out how long it has been since = Yokohama, because this
> much passage of time, with no change, suggests = that the
> actual operation
> of the IETF is proving to be more interested in = discussing
> process than
> in improving our work... by making changes that = will have real and
> useful effect. (No, I don't believe anyone = actually intends this to be
> true, but so far, our actions show the truth of = that fact.)
>
> I also point it out because it means that we = are suffering the same
> problem with timeliness in our change effort as = we do in our protocol
> development: loss of market window. In other = words, loss of
> opportunity
> and relevance.
>
> In this case, the "market window" has = to do with the attitudes of
> participants. When folks feel a deep sense of = frustration and the
> frustration does not get resolved anytime soon, = folks will typically
> give up. This fact plays heavily on the = interpretations and
> validity we
> can assert, about "feedback" we are = getting during our continuing
> process. (For the statistically inclined, think = of this as biasing the
> sample.)
>
> So, the calls from a number of folks to start = making changes, rather
> than to continue talking about the process of = change, seems
> is entirely
> appropriate. The fact that it is coming from a = number of independent
> participants -- and I continue to be amused = when John K. and
> I agree on
> a topic's recommendation phase, not just its = analysis phase -- should
> carry some weight.
>
>
> 2.  SOURCE OF CHANGE PROPOSALS
>
> At this point, quite a few people/groups are = suggesting that
> the source
> of useful proposals for change need to come = from... The IETF populace
> and not from specially "authorized" = representatives.
>
> There is an key, implicit message here, = folks.  Ultimately, this is
> "our" organization and we call for = the specifics of change,
> not just the
> concept of change.  Yokohama made clear = that change is needed, but it
> did not specify the details.  The details = are in the specifics of
> careful proposals.  They must come from = us.
>
> The fact that this perspective seems to be = coming from a
> number of very
> independent sources suggests that it is not all = that controversial. At
> the least, I haven't seen a serious alternative = to it
> proposed recently.
>
> The bottom line from this is that we need = concrete, detailed proposals
> for concrete, specific changes, backed by their = rationale.  Some are
> starting to emerge.
>
> What is essential is that anyone having an idea = that is not
> yet written
> down and available for review needs to do that = work.
>
> Anyone.
>
> As in, not just our "leaders" and not = just some designated committee.
>
> Anyone and Everyone.
>
>
> 3.  AUTHORITY TO ADOPT SPECIFIC = CHANGES
>
> So, given a panoply of concrete, detailed, = serious proposals, how does
> the IETF choose ones to implement?  Here = lies the divergence of views.
> (And frankly, I was getting tired of agreeing = with John so much.)
>
> Some suggest the IESG.  Some suggest a = blue-ribbon committee.  Some
> suggest the IETF Plenary.
>
> I now believe all those ideas are fundamentally = flawed,
> though I remain
> somewhat biased towards the last of these, = though it too is flawed.
>
> The universal flaw is that all of them ignore = the real need for real,
> broad, community support. Whatever is chosen, = the community has to
> embrace it. This being a community of rather = independent
> personalities,
> embracing does not occur because someone = dictates it.
>
> The IESG has no history deciding what process = changes are best for the
> IETF. Further, its members have no special = expertise in such
> design and
> selection. Choosing some decision mechanism = other than the
> IESG does not
> imply that we are in melt-down or that the IESG = is incompetent. It
> suggests that that is a body with different = skills and
> perspective than
> is appropriate for this category of = decision-making.
>
> A select, "blue-ribbon" committee is = always an appealing idea, and
> always suspect.  It, too, has no track = record of success for the
> decision it is making.   = Unfortunately, there is no existing
> IETF-related body that does have that track = record or that even
> obviously has the necessary skills about = organizational design and
> change.
>
> The Elwyn-et-al proposal invokes an = multi-source sampling
> mechanism for
> populating the committee. I've come to cherish = the benefit of ANY
> diverse sampling technique, for populating a = decision-making
> group that
> is intended to represent a larger community, as = long as it has any
> reasonable basis. In particular, there needs to = be some assurance that
> the folks being chosen are likely to be = clueful. Its key strength is
> that it ensures a real diversity of views (and = agendas.)
> Hence, it works
> on independent contributions. This forces a = negotiation and compromise
> process.
>
> The problem with using an IETF Plenary session = as the decision-making
> body is that it may well be too highly biased = (limited) a
> sample of the
> population.
>
> Ultimately, however, I believe that the real = decision-making
> needs to be
> done by garnering strong support from the = community. I won't go as far
> as invoking the usual "rough = consensus" criterion, because we now have
> quite a bit of experience showing how difficult = that can be to acquire
> or gauge, for "social" = decisions.
>
> And let's be clear that that is the realm we = are in. This is human and
> group stuff, not technical. So, few if any of = us have any
> real skills in
> this. Worse, finding folks who *do* have those = skills does
> not solve the
> problem. In fact, there is no way to guarantee = that any proposal will
> work as intended or even that it will work = well. That is the
> sad fact of
> life about this type of organizational change, = especially for a group
> this diverse and diffuse.
>
> To me, that means the only thing we can do is = to make sure that the
> decision is as broadly-shared as we can make = it. This begins by
> developing a constituency of support for a = candidate proposal.
>
> The nice things about such a direction of = effort is that it
> lessens the
> import of choosing the best group to make the = "final" decision.
>
> d/
> --
>  Dave Crocker <mailto:dcrocker@brandenburg.com= >
>  Brandenburg InternetWorking <http://www.brandenburg.com>
>  Sunnyvale, CA  USA = <tel:+1.408.246.8253>, <fax:+1.866.358.5301>
>
>

------_=_NextPart_001_01C354E9.AD97858C-- From problem-statement-bounces@alvestrand.no Mon Jul 28 12:29:08 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11443 for ; Mon, 28 Jul 2003 12:29:07 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 60C2B61BD6; Mon, 28 Jul 2003 18:28:39 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from HALVESTR-W2K1.cisco.com (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8773061BB1; Mon, 28 Jul 2003 18:28:37 +0200 (CEST) Date: Mon, 28 Jul 2003 09:01:55 -0700 From: Harald Tveit Alvestrand To: Randy Bush , problem-statement@alvestrand.no Message-ID: <309025535.1059382915@localhost> In-Reply-To: References: <0D45FC35-BDB0-11D7-B006-00039388672E@muada.com> X-Mailer: Mulberry/3.0.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: English (was Re: A few hums) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit RFC 3184, " --On 24. juli 2003 06:54 -0700 Randy Bush wrote: > if we think we can solve the global multi-language/culture problem, > why the heck don't we get real and work on world hunger and peace? > > let's face it, we live in a multi-lingual world, embarrassingly, > american has become the lingua franca of our technology. there > are some simple (but hard) things folk can do to make themselves > easier to understand, speak slowly and clearly, use no idioms, > have clear slides which help folk read along, etc. i would wager > that there is some nice web page on this if we googled correctly. > > beyond that, yes it's a problem, but we ain't gonna fix it. > > randy RFC 3184, "IETF guidelines for conduct". > 1. IETF participants extend respect and courtesy to their colleagues > at all times. > > IETF participants come from diverse origins and backgrounds and > are equipped with multiple capabilities and ideals. Regardless of > these individual differences, participants treat their colleagues > with respect as persons--especially when it is difficult to agree > with them. Seeing from another's point of view is often > revealing, even when it fails to be compelling. > > English is the de facto language of the IETF, but it is not the > native language of many IETF participants. Native English > speakers attempt to speak clearly and a bit slowly and to limit > the use of slang in order to accommodate the needs of all > listeners. The EDU team (result of the EDU BOF) is taking up the issue of making guidelines available - both for non-North American people to participate in the IETF and for North American people to make it easier for non-North American to participate. Both are needed, I think :-) From problem-statement-bounces@alvestrand.no Mon Jul 28 12:29:17 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11470 for ; Mon, 28 Jul 2003 12:29:16 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D539761BB3; Mon, 28 Jul 2003 18:28:49 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from HALVESTR-W2K1.cisco.com (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 080A361B92; Mon, 28 Jul 2003 18:28:39 +0200 (CEST) Date: Mon, 28 Jul 2003 09:22:04 -0700 From: Harald Tveit Alvestrand To: Dave Crocker , problem-statement@alvestrand.no Message-ID: <310233702.1059384124@localhost> In-Reply-To: <50105274126.20030727122203@brandenburg.com> References: <50105274126.20030727122203@brandenburg.com> X-Mailer: Mulberry/3.0.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: Sampling X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit --On 27. juli 2003 12:22 -0700 Dave Crocker wrote: > Folks, > > The latter part of a posting by John cites statistic issues. I'd like > to explore that issue separately and carefully: > > I believe that both the working group participation and the IETF Vienna > plenary presentation represent very, very highly biased samples of the > IETF population. Yes. In both cases, they consist of the people that show up. > Sampling bias does not require intentional "packing". It requires > selection methods that make the group unrepresentative of the total > population. > > In this case, we had a smaller-than-expected total IETF meeting > attendance, in a venue that prevented significant numbers of regular > participants from attending. And not all of the meeting attendees were > Plenary attendees. > > Notably, we have not paid much enough attention to just how small the > participation in the Problems working group has been. And the recent > Plenary had all sorts of confusion to this discussion. Overall, we need > to be very circumspect in making decisions based on either bits of > input. Actually I was pleasantly surprised that about a quarter of the plenary actually claimed to have read the problem drafts. This is significantly higher than many working groups, and indicates that the part of the community that shows up at plenaries outside the US *does* care about the issues, enough to do prep work. We trust WG meetings with less prepwork made with decisions, too. > > However the call for Last Call review can (and does) lead to > re-synchronization far too late, I believe. We need to make sure that > there are ways of doing synchronization with the community early and > often. > > Even waiting for a Plenary presentation might be too infrequently. > Perhaps we need tight, summary "presentations" on the Announce-list, > occasionally. We might think of these as "phase" Last Calls, or > somesuch. actually the participants on ietf-announce (about 2500 of them) are a *third* statistically skewed sample of our participants - and the probably smaller number who actually read and think about responding to Last Calls (of any sort) is even more statistically skewed. I think of this as a problem, in general..... Harald From problem-statement-bounces@alvestrand.no Mon Jul 28 12:33:59 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11642 for ; Mon, 28 Jul 2003 12:33:58 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9631B61BB1; Mon, 28 Jul 2003 18:33:30 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from ran.psg.com (ip166.usw12.rb1.bel.nwlink.com [209.20.253.166]) by eikenes.alvestrand.no (Postfix) with ESMTP id A871C61AA5; Mon, 28 Jul 2003 18:33:28 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19hAw4-0009j6-88; Mon, 28 Jul 2003 09:33:20 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 28 Jul 2003 09:33:19 -0700 To: Harald Tveit Alvestrand References: <50105274126.20030727122203@brandenburg.com> <310233702.1059384124@localhost> Message-Id: Cc: Dave Crocker , problem-statement@alvestrand.no Subject: Re: Sampling X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit >> I believe that both the working group participation and the IETF Vienna >> plenary presentation represent very, very highly biased samples of the >> IETF population. > > Yes. In both cases, they consist of the people that show up. as was yokohama. as was ... as will be ... all samples are biased. we just don't like the ones that have results which disagree with our own perceptions. funny monkeys we are. randy From problem-statement-bounces@alvestrand.no Mon Jul 28 13:17:08 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13180 for ; Mon, 28 Jul 2003 13:17:07 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9B64661BB1; Mon, 28 Jul 2003 19:16:39 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by eikenes.alvestrand.no (Postfix) with ESMTP id 42A1561B92 for ; Mon, 28 Jul 2003 19:16:37 +0200 (CEST) Received: from cisco.com (171.68.223.137) by sj-iport-3.cisco.com with ESMTP; 28 Jul 2003 10:16:37 -0700 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h6SHGXuG010646; Mon, 28 Jul 2003 10:16:34 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AKC80417; Mon, 28 Jul 2003 10:16:32 -0700 (PDT) Message-Id: <200307281716.AKC80417@mira-sjc5-c.cisco.com> To: problem-statement@alvestrand.no From: Melinda Shore Date: Mon, 28 Jul 2003 13:16:31 -0400 Cc: avri@apocalypse.org Subject: Closing the hums X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no There's been relatively little discussion of the hums that were taken at the meeting. We've got consensus on most of them (appended). The two exceptions are 4), where we still need more text, and 7), where we've got significant dissent but significant agreement. However we do have consensus on 1), 2), 3), 5), 6), and 8). Melinda -------- 1) In the discussion of timeliness, we asked for a hum whether or not the current text in section 2.1 of the problem statement document is adequate. The hum was positive (the text is adequate). 2) In the discussion of ADs who function as WG chairs, we asked whether this was adequately covered in section 2.6.6 of the problem statement document. The hum indicated that those present feel that it is. 3) In the discussion of the IETF's scope, the question was whether or not the existing text in the problem statement document sufficiently addressed the issue. The hum indicated that those present felt it does. 4) In the discussion of whether or not there's a problem accomodating ESL speakers, the discussion broadened a bit to cover cultural issues, the hum indicated that those present felt that we needed more text on this issue. 5) In the discussion of whether or not the existing IETF document format is a problem, the hum indicated that those present felt that it is not. 6) We took a hum to see if those present felt that the process document is headed in the right direction. The hum indicated that they do. 7) We took a hum to see if those present felt that we need to define a process to identify values, mission, scope, and goals. The hum was split. 8) We took a hum to see when work should start on the short-term solutions proposals in the process document. The options were 1) when the problem statement is approved, 2) when the process document is approved, and 3) now. The hum was overwhelmingly in favor of "now." From problem-statement-bounces@alvestrand.no Wed Jul 30 18:00:55 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20032 for ; Wed, 30 Jul 2003 18:00:55 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3BA0961B90; Thu, 31 Jul 2003 00:00:28 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by eikenes.alvestrand.no (Postfix) with ESMTP id 69EE361B8F for ; Thu, 31 Jul 2003 00:00:26 +0200 (CEST) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h6UM4Va12771 for ; Wed, 30 Jul 2003 15:04:31 -0700 Date: Wed, 30 Jul 2003 15:00:20 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/11) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <6616211280.20030730150020@brandenburg.com> To: problem-statement@alvestrand.no In-Reply-To: <310233702.1059384124@localhost> References: <50105274126.20030727122203@brandenburg.com> <310233702.1059384124@localhost> MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: base64 Subject: Re: Sampling X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list Reply-To: Dave Crocker List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: base64 Rm9sa3MsDQoNCj4+IEkgYmVsaWV2ZSB0aGF0IGJvdGggdGhlIHdvcmtpbmcgZ3JvdXAgcGFy dGljaXBhdGlvbiBhbmQgdGhlIElFVEYgVmllbm5hDQo+PiBwbGVuYXJ5IHByZXNlbnRhdGlv biByZXByZXNlbnQgdmVyeSwgdmVyeSBoaWdobHkgYmlhc2VkIHNhbXBsZXMgb2YgdGhlDQo+ PiBJRVRGIHBvcHVsYXRpb24uDQoNCkhUQT4gWWVzLiBJbiBib3RoIGNhc2VzLCB0aGV5IGNv bnNpc3Qgb2YgdGhlIHBlb3BsZSB0aGF0IHNob3cgdXAuDQphbmQNClJCPiBhbGwgc2FtcGxl cyBhcmUgYmlhc2VkLiAgd2UganVzdCBkb24ndCBsaWtlIHRoZSBvbmVzIHRoYXQgaGF2ZQ0K UkI+IHJlc3VsdHMgd2hpY2ggZGlzYWdyZWUgd2l0aCBvdXIgb3duIHBlcmNlcHRpb25zLiAg ZnVubnkgbW9ua2V5cw0KUkI+IHdlIGFyZS4NCg0KVHdvIHBvaW50cyBmcm9tIHRoaXMgYnJp ZWYgdGhyZWFkOg0KDQoNCjEuIFR3byBtZW1iZXJzIG9mIHRoZSBJRVNHIGFyZSBjbGVhciB0 aGF0IHdlIG5lZWQgbm90IGJlIGNvbmNlcm5lZCB3aXRoDQp0aGUgYmFzaXMgb24gd2hpY2gg d2UgaW50ZXJwcmV0IGEgbWVldGluZydzIHJlc3VsdHMuDQoNCkxpdGVyYWxseSB0aGUgb25s eSB0aGluZyB0aGF0IG1hdHRlcnMgaXMgd2hvIHNob3dzIHVwLg0KDQpJbiBzb2NpYWwgcmVz ZWFyY2ggbWV0aG9kb2xvZ3kgZGlzY3Vzc2lvbnMgYWJvdXQgdGhlIHRvcGljIG9mIHNhbXBs aW5nDQpiaWFzLCB0aGVyZSBpcyBhIGNhcmVmdWwgZGlzdGluY3Rpb24gYmV0d2VlbiAicG9w dWxhdGlvbiIgYW5kICJzYW1wbGUiLg0KVGhlcmUgYXJlIHNvbWUgdXNlZnVsIGRlY2FkZXMg b2YgZXhwZXJpZW5jZSB3aXRoIHRoaXMgZGlzdGluY3Rpb24uICBUaGUNCnNhbWUgdXNlZnVs IGhpc3RvcnkgY29uY2VybnMgYmlhc2luZyBhc3BlY3RzIG9mIHRoZSB3YXlzIHF1ZXN0aW9u cyBhcmUNCmFza2VkLg0KDQpGcm9tIHRoZSB0d28gcG9zdGluZ3Mgb24gdGhpcyB0aHJlYWQs IGl0IGFwcGVhcnMgdGhhdCB3ZSBhcmUgc2ltcGx5IHRvDQp0cmVhdCBzYW1wbGUgYW5kIHBv cHVsYXRpb24gYXMgdGhlIHNhbWUsIGFuZCB3ZSBuZWVkIG5vdCB3b3JyeSBhYm91dCB0aGUN CnBhcnRpY3VsYXIgZm9ybSBvZiBxdWVzdGlvbnMgdG8gdGhlIGdyb3VwLg0KDQpPcmlnaW5h bGx5LCB0aGUgSUVURiB3b3JyaWVkIHF1aXRlIGEgYml0IGFib3V0IGJlaW5nIGluY2x1c2l2 ZSwgaW4gaXRzDQpmb3JtdWxhdGlvbiBvZiBtZWV0aW5nIGxvZ2lzdGljcywgaXRzIGFzc2Vz c21lbnQgYW5kIHVzZSBvZiBjb25zZW5zdXMNCnN0YXRlbWVudHMgYXQgbWVldGluZ3MsIGFu ZCBpdHMgZ2VuZXJhbCBhdHRlbnRpb24gdG8gdGhlIHByZWZlcmVuY2VzIG9mDQp0aGUgZ2Vu ZXJhbCBjb21tdW5pdHkuIEFsbCBvZiB0aGlzIGlzIGRpZmZpY3VsdCBhbmQgdW5wbGVhc2Fu dC4NCg0KSSBoYXZlIGFsd2F5cyBmZWx0IHRoYXQgdGhhdCBjYXJlZnVsIGF0dGVudGlvbiB0 byByZWFsIGluY2x1c2l2ZW5lc3Mgd2FzDQphIHByaW1hcnkgc291cmNlIG9mIGxlZ2l0aW1h Y3kgZm9yIHRoZSBJRVRGLiBJdCB3YXMgaW4gdGhpcyBjb250ZXh0LCBvZg0KYmVuZGluZyBv dmVyIGJhY2t3YXJkcyB0byBiZSBpbmNsdXNpdmUsIHRoYXQgdGhlIGZvY3VzIG9uIHRob3Nl IHdobw0Kc2hvd2VkIHVwIGFuZCBwYXJ0aWNpcGF0ZWQgcmFuZyB0cnVlLg0KDQpBcHBhcmVu dGx5IHRoaW5ncyBoYXZlIGNoYW5nZWQuIEl0IGFwcGVhcnMgdGhhdCB3ZSBubyBsb25nZXIg aGF2ZSB0bw0Kd29ycnkgd2hldGhlciBtZWV0aW5nIGxvZ2lzdGljcyBzZXJ2ZSB0byBleGNs dWRlIHBlb3BsZSBvciB3aGV0aGVyIElFVEYNCnByb2Nlc3Mgc2VydmVzIHRvIGRpc2VuZnJh bmNoaXNlIGZvbGtzLiBXZSBqdXN0IHRhbGx5IHdobyBzaG93cyB1cCAtLSBvcg0KcmF0aGVy LCB3aG8gc3BlYWtzIHVwIC0tIGFuZCB0aGF0J3MgdGhhdC4NCg0KSSdtIGd1ZXNzaW5nIHRo YXQgc29tZSBmb2xrcyBtaWdodCBkaXNhZ3JlZSB3aXRoIG15IGFzc2Vzc21lbnQuDQpDbGFy aWZpY2F0aW9ucyBhbmQgY29ycmVjdGlvbnMgd291bGQgYmUgZ3JlYXRseSBhcHByZWNpYXRl ZC4NCg0KDQoyLiBObyBvbmUgZWxzZSBoYXMgY29udHJpYnV0ZWQgdG8gdGhpcyB0aHJlYWQu DQoNCkhlbmNlIHRoZXkgaGF2ZSBub3QgInNob3duIHVwIi4gQnkgZGVmaW5pdGlvbiB0aGlz IG1lYW5zIHRoYXQgdGhlIHR3bw0KSUVTRyBtZW1iZXJzIGFyZSBjb3JyZWN0IGFuZCB0aGF0 IEkgYW0gd3JvbmcgYWJvdXQgbXkgY29uY2VybnMuDQoNCkx1Y2tpbHksIHdlIGRvIG5vdCBu ZWVkIHRvIHdvcnJ5IHdoZXRoZXIgZm9sa3MgaGF2ZSwgaW4gZmFjdCwgZ2l2ZW4gdXANCm9u IHRoaXMgZm9ydW0gb3IgdGhpcyB0b3BpYy4gVGhleSBoYXZlbid0IGNvbnRyaWJ1dGVkLCBz byB0aGVpciB2aWV3cw0KYXJlIG5vdCByZWxldmFudC4NCg0KZC8NCi0tDQogRGF2ZSBDcm9j a2VyIDxtYWlsdG86ZGNyb2NrZXJAYnJhbmRlbmJ1cmcuY29tPg0KIEJyYW5kZW5idXJnIElu dGVybmV0V29ya2luZyA8aHR0cDovL3d3dy5icmFuZGVuYnVyZy5jb20+DQogU3Vubnl2YWxl LCBDQSAgVVNBIDx0ZWw6KzEuNDA4LjI0Ni44MjUzPiwgPGZheDorMS44NjYuMzU4LjUzMDE+ DQo= From problem-statement-bounces@alvestrand.no Wed Jul 30 18:15:40 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21572 for ; Wed, 30 Jul 2003 18:15:39 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D98D661BAF; Thu, 31 Jul 2003 00:15:12 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from ran.psg.com (ip166.usw12.rb1.bel.nwlink.com [209.20.253.166]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4A13D61B90 for ; Thu, 31 Jul 2003 00:15:11 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19hzDu-000Gc4-TP; Wed, 30 Jul 2003 15:15:07 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 30 Jul 2003 15:15:06 -0700 To: Dave Crocker References: <50105274126.20030727122203@brandenburg.com> <310233702.1059384124@localhost> <6616211280.20030730150020@brandenburg.com> Message-Id: Cc: problem-statement@alvestrand.no Subject: Re: Sampling X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit > 1. Two members of the IESG are clear that we need not be concerned with > the basis on which we interpret a meeting's results. no. two members are clear that we have no good way to interpret the results other than taking them on face value, as opposed to your appproach of discounting that and those with whom you disagree. randy From problem-statement-bounces@alvestrand.no Wed Jul 30 19:42:09 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23611 for ; Wed, 30 Jul 2003 19:42:08 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 78B2761BAD; Thu, 31 Jul 2003 01:41:40 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9DDCE61B90 for ; Thu, 31 Jul 2003 01:41:38 +0200 (CEST) Received: from [209.187.148.215] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.10) id 19i0Zd-0004Rq-00; Wed, 30 Jul 2003 18:41:37 -0500 Date: Wed, 30 Jul 2003 19:41:37 -0400 From: John C Klensin To: Dave Crocker , "problem-statement@alvestrand.no" Message-ID: <626443598.1059594097@p3.JCK.COM> In-Reply-To: <6616211280.20030730150020@brandenburg.com> References: <50105274126.20030727122203@brandenburg.com> <310233702.1059384124@localhost> <6616211280.20030730150020@brandenburg.com> X-Mailer: Mulberry/3.1.0b4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: How we decide that we have decided (was: Re: Sampling) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Dave, I don't want to put words into your mouth, or that of any of the IESG, so I'm going to try to go up a half-level of abstraction... (1) It had better be possible to talk about, and question, the quality of a claimed consensus. "Quality" must be able to include bias* -- in the narrow statistical sense, not, in itself, implying that anything evil is happening -- of whatever convenience samples* happen to have been surveyed relative to the whole population of participants in some WG, the (usually larger) population of people interested in the WG but not participating for some reason, the (usually larger) population of IETF participants, and even the (larger yet) population of (to use ANSI's term) "materially concerned" Internet users and suppliers. If we can't do that, then we have absolutely no protection against some individual or group generating so much noise (or hostility, or other unpleasantnesses) that they drive everyone who disagrees with them away and then claim consensus for their position. Our protection against that sort of attack is, primarily, the judgment of WG Chairs, Area Directors, and the whole IESG, backed up, if necessary, by appeals processes to force additional scrutiny on what occurred. Those judgments are, ultimately, extremely subjective, which is too bad, but there is no other way. In particular, we will not get any protection from discussions of sampling theory, since we don't have good models or descriptions of either the convenience* or self-selection* samples involved or of the underlying presumed populations. In addition, our oft-repeated claim that we rely more on mailing list discussions and conclusions than on the group of people who happen to show up and a meeting and talk or wave their arms becomes completely bogus if we can't evaluate the quality of a claimed consensus. I hope we are not headed in that direction. (2) Why has there been little or no response other than from a few IESG members? I suggest that every participant in the IETF, including the IESG and those few for whom IETF participation is a full-time job, must regularly, perhaps continually, make decisions about what is important and what isn't. The criteria for importance will differ from one or another of us, but might rationally include - "will my putting energy into this make any difference at the end of the day" and/or - "will this effort make any real difference when examined from the perspective of a few years from now", and/or - "is my following this and contributing to it likely to be of enough value to overcome the irritation costs and increased blood pressure it will probably involve", as well as the traditional opportunity cost question of "if I don't spend time on this, what else could I be doing that would be more useful or productive?". In my own case, my original use of the term "bias" was, I believe, statistically correct. It didn't take very many transactions on this thread for me to conclude that, given the personal criteria I'm applying these days, getting drawn into a discussion about sampling terminology and theory and its relationship to IETF meetings was not an investment I felt like making. So I have been sampling* the thread**, but not responding. I changed that policy/ strategy (and changed the subject line) when the thread turned into what appear to be a set of assertions about agreements/ conclusions/ consensus that do and do not exist based on other responses and where they come from. (3) Once a WG, or set of discussion threads, starts being taken over by a relatively small number of passionate people who are generating a lot of often-repetitive postings, we need to be, IMO, _extremely_ careful about how we interpret whatever polls and consensus calls we make and even more careful about traffic analysis. It is very easy to confuse "consensus among those who haven't given up on the effort" and "consensus among the group who are concerned about the issues". Those two groups are often different and the reasons for the differences may be very important. They are also often different from "the group who happens to be gathered together in a given place" or "the group who showed up at a meeting (or plenary)" or "the group that is actively participating in a WG at a particular time". Analysis, whether by statistical or other means, of those differences may be quite instructive but, normally, only if it moves beyond repeated assertions of personal belief (or about beliefs or claims about what others mean by their silence). (4) In the absence of analysis good enough to project from a subset (whether it is strictly a sample or not and whether that sample is biased or not) of some population to the opinions of that population, just about the only thing one can safely do is to accept the opinions (or measurements) as expressed, while being cautious about their interpretation based on an understanding of threats to validity*. (5) Let me conclude with a personally-troubling example of how some of this works. Melinda has sent out two messages to try to validate the meeting "hums". That is a legitimate thing for a WG Chair to do in the process of trying to determine consensus. I've read both messages, thought about responding on the several issues in which my personal opinions are different from the consensus she has identified, and decided to not do so. Why? Because in my personal opinion, this WG has been extremely helpful in discussing and focusing on the issues, but has now passed sufficiently far into the range of diminishing returns to have outlived its usefulness. If I were the AD, I'd be trying to deliver a "wrap this up before I shut it down; it shouldn't drag out much longer" message. I've said that before in different ways, including at the plenary where, independent of how one interprets it, my "lets get on with it and do so without setting up more apparatus" comments appeared to get more support than most of the specifics from this WG or the process of which it is a part. A corollary of that personal conclusion of mine is that it would be useful to publish the issues list, as it exists today, as a snapshot of some very serious and thoughtful community analysis, but without either worrying a great deal about whether it represents consensus (and of what) or about getting every statement exactly right. Were we to follow that path, the one thing that would be important to get right in the document would be a clear statement about what it does, and does not, represent. So, just as I challenged Harald at the plenary about the questions he did (or didn't) ask, I should probably challenge Melissa to ask for input on who actually thinks the charge of this WG is worth more time and, if so, how much more and what we should use as a stopping rule. The latter is especially important given the subject matter of the WG: it would be _lots_ better if we reached consensus to shut ourselves down than if we wait long enough for it to be obvious that the AD should do it. Is it beneficial to the WG, or to the IETF, for me to repeat those conclusions three or four --or a few dozen-- more times? I doubt it. I think I've been heard and that those who are going to agree have agreed already and that those who haven't won't change their minds if I repeat myself. So I'm trying to move on, even if the WG is not. What is the relationship between those conclusions and Melissa's "hum closure" calls? Well, I don't agree with several of her conclusions and, especially since there has mostly been silence, she is on thin ice if she concludes that everyone who hasn't expressed disagreement agrees with her. But I don't disagree enough --relative to my assessment of importance and what else I could be doing with my time-- to want to stand up and say "I disagree, and here is my analysis and my reasons". Bad investment of time: I personally believe that the document today is close enough for any real, viewed-from-five-years-hence purpose which it is likely to leverage and I think we should get on with it. john Footnotes: * The term "sample" and "sampling" have very precise meanings in statistics. They involve systematic mechanisms for determining or describing the relationship between the sample and some population or universe that it is supposed to represent, so that inferences from the sample can be projected (or translated) into inferences about the population. If it is not possible to describe either the population or the relationship of the "sampled" subpopulation to it, then "sample" belongs in quotes. The term "convenience sample" refers to a subpopulation that is selected, not by some formal or systematic means, but on the basis of, e.g., whomever happens to be handy or most easily accessed. The term "self-selected sample" refers to what is usually considered a special sort of convenience sample in which the members of the selected subpopulation select themselves, often based on their particular positions on whatever is being measured. Among the people who do sample design for a living, both "convenience sample" and "self-selected sample" are terms of abuse or, sometimes, derision. "Bias", technically, refers to the difference, or lack thereof, between a sample (selected under some sampling model) and the relevant population. If the population parameters, other than size, are different from the equivalent parameters of the presumed sample, then the sample is biased and --and this is the important issue-- one cannot safely make direct inferences from findings or conclusions about the sample to findings or inferences of the population. Convenience samples can be unbiased, but that doesn't happen by accident and, in statistical sampling circles, the burden of proof is on whomever makes that claim and the burden is pretty high. And, finally, "threat to validity" is another technical term, referring to the whole collection of things (hidden systematic bias is only one) that can make projection of an inference from a sample onto a population incorrect, even if "sample statistics", "confidence intervals", etc., indicate that things should be ok. ** Yes, I have a sampling model for the list that determines what I read and what I don't. I don't feel like describing it, partially because my doing so might possibly introduce additional biases. Finally, an observation on the footnotes: By most reasonable definitions of the term, I'm a card-carrying statistician or at least a card-carrying data analyst (but I am not a sampling expert and have never had any desire to be one). It has been a while, but I've taught this stuff and made a day-job living doing some of it. And I find it more than mildly interesting that the other folks in the IETF whom I'm aware of having similar backgrounds have, unlike myself, been smart enough to not waste their time speaking up on this issue. ---------- --On Wednesday, 30 July, 2003 15:00 -0700 Dave Crocker wrote: > Folks, > >>> I believe that both the working group participation and the >>> IETF Vienna plenary presentation represent very, very highly >>> biased samples of the IETF population. > > HTA> Yes. In both cases, they consist of the people that show > up. and > RB> all samples are biased. we just don't like the ones that > have RB> results which disagree with our own perceptions. > funny monkeys RB> we are. > > Two points from this brief thread: > > > 1. Two members of the IESG are clear that we need not be > concerned with the basis on which we interpret a meeting's > results. > > Literally the only thing that matters is who shows up. > > In social research methodology discussions about the topic of > sampling bias, there is a careful distinction between > "population" and "sample". There are some useful decades of > experience with this distinction. The same useful history > concerns biasing aspects of the ways questions are asked. > > From the two postings on this thread, it appears that we are > simply to treat sample and population as the same, and we need > not worry about the particular form of questions to the group. > > Originally, the IETF worried quite a bit about being > inclusive, in its formulation of meeting logistics, its > assessment and use of consensus statements at meetings, and > its general attention to the preferences of the general > community. All of this is difficult and unpleasant. > > I have always felt that that careful attention to real > inclusiveness was a primary source of legitimacy for the IETF. > It was in this context, of bending over backwards to be > inclusive, that the focus on those who showed up and > participated rang true. > > Apparently things have changed. It appears that we no longer > have to worry whether meeting logistics serve to exclude > people or whether IETF process serves to disenfranchise folks. > We just tally who shows up -- or rather, who speaks up -- and > that's that. > > I'm guessing that some folks might disagree with my assessment. > Clarifications and corrections would be greatly appreciated. > > > 2. No one else has contributed to this thread. > > Hence they have not "shown up". By definition this means that > the two IESG members are correct and that I am wrong about my > concerns. > > Luckily, we do not need to worry whether folks have, in fact, > given up on this forum or this topic. They haven't > contributed, so their views are not relevant. > > d/ > -- > Dave Crocker > Brandenburg InternetWorking > Sunnyvale, CA USA , > From problem-statement-bounces@alvestrand.no Wed Jul 30 21:12:52 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25708 for ; Wed, 30 Jul 2003 21:12:51 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C2B7C61BAF; Thu, 31 Jul 2003 03:10:26 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3C20E61BAD for ; Thu, 31 Jul 2003 03:10:24 +0200 (CEST) Received: from dfnjgl21 (12-237-229-250.client.attbi.com[12.237.229.250](untrusted sender)) by comcast.net (rwcrmhc13) with SMTP id <2003073101102201500qp3pie> (Authid: sdawkins@comcast.net); Thu, 31 Jul 2003 01:10:22 +0000 Message-ID: <0e8101c35700$86398940$0400a8c0@DFNJGL21> From: "Spencer Dawkins" To: "Problem Statement Mailing List" References: <50105274126.20030727122203@brandenburg.com><310233702.1059384124@localhost><6616211280.20030730150020@brandenburg.com> <626443598.1059594097@p3.JCK.COM> Date: Wed, 30 Jul 2003 20:10:21 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: Re: How we decide that we have decided (was: Re: Sampling) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list Reply-To: Spencer Dawkins List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Dear John, I wanted to thank you particularly for two points in your note: - I have been telling myself since January that the problem statement editorial team needed to put together the best problem statement we could *without* trying to figure out whether the problems being reported to us were "real", but I wasn't sure that we were doing the right thing until you explained why we were doing the right thing in your note. Thanks! - When the thread title was "sampling" - well, I have some formal training in that direction, and I was troubled because normally "population" is better-defined than it is in the IETF - Dave was asking about bias between a sample and a population when I didn't have a good definition of the "population" (since we have no formal membership, etc. - it's almost like our population is a sample of a larger population). Your reference to those with a "material interest" was helpful to me in thinking about the difference between consensus and voting. Again, thanks! I'm glad we've done the problem statement work that we've done so far, and I've noted a couple of times that we've only added one (IIRC) "root problem" since IETF 56, so I agree that we're on the diminshing returns part of the power curve. Maybe part of assuming that we're all adults is letting people read the problem statement and each figure out how to respond as individuals - there are opportunities for structural change, but there are an awful lot of opportunities that one or two people can start a trend to take advantage of. Spencer From problem-statement-bounces@alvestrand.no Wed Jul 30 21:26:14 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25995 for ; Wed, 30 Jul 2003 21:26:13 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D0CE461BAF; Thu, 31 Jul 2003 03:25:45 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by eikenes.alvestrand.no (Postfix) with ESMTP id 568E361BAD for ; Thu, 31 Jul 2003 03:25:44 +0200 (CEST) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h6V1Tna22290; Wed, 30 Jul 2003 18:29:49 -0700 Date: Wed, 30 Jul 2003 18:25:41 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/11) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1828530664.20030730182541@brandenburg.com> To: "Spencer Dawkins" In-Reply-To: <0e8101c35700$86398940$0400a8c0@DFNJGL21> References: <50105274126.20030727122203@brandenburg.com><310233702.1059384124@localhost><6616211280.20030730150020@brandenburg.com> <626443598.1059594097@p3.JCK.COM> <0e8101c35700$86398940$0400a8c0@DFNJGL21> MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Cc: Problem Statement Mailing List Subject: Re: How we decide that we have decided (was: Re: Sampling) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Spencer, SD> Dave was asking about bias between a sample and a population SD> when I didn't have a good definition of the "population" (since Exactly. It is the fluidity and informality of the *real* population's boundary that should make us particularly diligent about whether we are being adequately inclusive and whether our samples are adequately representative. We used to do that. Now, apparently, we just say "we have no good way to interpret the results other than taking them on face value". SD> we have no formal membership, etc. - it's almost like our SD> population is a sample of a larger population). yup! d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Wed Jul 30 23:06:58 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27652 for ; Wed, 30 Jul 2003 23:06:57 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B2B9A61BF5; Thu, 31 Jul 2003 05:06:28 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from HALVESTR-W2K1.cisco.com (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 19FF361B95; Thu, 31 Jul 2003 05:06:22 +0200 (CEST) Date: Wed, 30 Jul 2003 19:58:36 -0700 From: Harald Tveit Alvestrand To: Dave Crocker , problem-statement@alvestrand.no Message-ID: <521226123.1059595116@localhost> In-Reply-To: <6616211280.20030730150020@brandenburg.com> References: <50105274126.20030727122203@brandenburg.com> <310233702.1059384124@localhost> <6616211280.20030730150020@brandenburg.com> X-Mailer: Mulberry/3.0.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: Sampling X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Dave, --On 30. juli 2003 15:00 -0700 Dave Crocker wrote: > 1. Two members of the IESG are clear that we need not be concerned with > the basis on which we interpret a meeting's results. > > Literally the only thing that matters is who shows up. I never said anything resembling this. The keywords of what I said in my message of Mon, 28 Jul 2003 09:22:04 -0700 were: > Yes. In both cases, they consist of the people that show up. > We trust WG meetings with less prepwork made with decisions, too. > I think of this as a problem, in general..... I do not see any logical connection between this message and "we need not be concerned with the basis on which we interpret a meeting's results". Harald From problem-statement-bounces@alvestrand.no Thu Jul 31 00:44:03 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29247 for ; Thu, 31 Jul 2003 00:44:03 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A5A3C61BE9; Thu, 31 Jul 2003 06:43:35 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1CAA961BAF; Thu, 31 Jul 2003 06:43:33 +0200 (CEST) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h6V4lda31236; Wed, 30 Jul 2003 21:47:39 -0700 Date: Wed, 30 Jul 2003 21:43:28 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/11) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <15940397558.20030730214328@brandenburg.com> To: Harald Tveit Alvestrand In-Reply-To: <521226123.1059595116@localhost> References: <50105274126.20030727122203@brandenburg.com> <310233702.1059384124@localhost> <6616211280.20030730150020@brandenburg.com> <521226123.1059595116@localhost> MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: Sampling X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list Reply-To: Dave Crocker List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Harald, >> 1. Two members of the IESG are clear that we need not be concerned with >> the basis on which we interpret a meeting's results. >> >> Literally the only thing that matters is who shows up. HTA> I never said anything resembling this. Let's see: I post a note calling for careful exploration of an issue and include the statement: DC> Notably, we have not paid much enough attention to just how small the DC> participation in the Problems working group has been. And the recent DC> Plenary had all sorts of confusion to this discussion. Overall, we need DC> to be very circumspect in making decisions based on either bits of DC> input. You post a note saying we have the people who show up, and Randy posts a note saying all samples are biased. Neither of you offers any additional, substantive response to my query, nor any indication of interest in pursuing it further. No doubt there is a way of reading your responses as showing that concern I failed find, and as providing useful insight to the topic, so I apologize for having missed it entirely. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Thu Jul 31 05:05:35 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16953 for ; Thu, 31 Jul 2003 05:05:34 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C15AC61BD8; Thu, 31 Jul 2003 11:05:06 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [194.196.100.235]) by eikenes.alvestrand.no (Postfix) with ESMTP id C0C5C61BB9 for ; Thu, 31 Jul 2003 11:05:04 +0200 (CEST) Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by d12lmsgate-2.de.ibm.com (8.12.9/8.12.8) with ESMTP id h6V953si150044 for ; Thu, 31 Jul 2003 11:05:03 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h6V951kA271538 for ; Thu, 31 Jul 2003 11:05:02 +0200 Received: from zurich.ibm.com (dhcp22-107.zurich.ibm.com [9.4.22.107]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA39260 for ; Thu, 31 Jul 2003 11:05:01 +0200 Message-ID: <3F28DBBD.C08C48A6@zurich.ibm.com> Date: Thu, 31 Jul 2003 11:05:01 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Problem Statement Mailing List References: <50105274126.20030727122203@brandenburg.com><310233702.1059384124@localhost><6616211280.20030730150020@brandenburg.com> <626443598.1059594097@p3.JCK.COM> <0e8101c35700$86398940$0400a8c0@DFNJGL21> <1828530664.20030730182541@brandenburg.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: How we decide that we have decided (was: Re: Sampling) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit In technical WGs we generally assume that the people who show up and hum/raise hands/send email are by definition the set of people with an active interest in the topic, and (modulo IESG review and Last Call) that is considered the appropriate constituency. It's essentially self-selected, and we seem to be fine with that. In non-technical topics (such as ipr) we have had to deal with non-technical people self-selecting themselves for the WG. And in some political topics (RFC 1984, RFC 2804) we have been happy to accept a hum from the people who self-select themselves to attend the Thursday plenary. For process topics, there's a built in self-reference in any consensus mechanism. But personally, I think the self-selection for the Thursday plenary is much less suspect than the self-selection for this WG. The people (including me of course) who have strong feelings about process issues are not automatically the people who should decide. Self-selection for the Thursday plenary is probably indicative of interest in general IETF issues, given that the alternatives are going out for a leisurely dinner or leaving early for home. So there are good reasons to listen to the Thursday night hum for general issues. After that, the ball is clearly in the IESG's court. Brian - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM NEW ADDRESS PLEASE UPDATE ADDRESS BOOK Dave Crocker wrote: > > Spencer, > > SD> Dave was asking about bias between a sample and a population > SD> when I didn't have a good definition of the "population" (since > > Exactly. > > It is the fluidity and informality of the *real* population's boundary > that should make us particularly diligent about whether we are being > adequately inclusive and whether our samples are adequately > representative. > > We used to do that. > > Now, apparently, we just say "we have no good way to interpret the > results other than taking them on face value". > > SD> we have no formal membership, etc. - it's almost like our > SD> population is a sample of a larger population). > > yup! > > d/ > -- > Dave Crocker > Brandenburg InternetWorking > Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Thu Jul 31 08:33:07 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22595 for ; Thu, 31 Jul 2003 08:33:07 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E036961BDB; Thu, 31 Jul 2003 14:32:37 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6B42161B97 for ; Thu, 31 Jul 2003 14:32:36 +0200 (CEST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h6VCWXLH028078; Thu, 31 Jul 2003 05:32:34 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AKG80938; Thu, 31 Jul 2003 05:32:32 -0700 (PDT) Message-Id: <200307311232.AKG80938@mira-sjc5-c.cisco.com> To: John C Klensin From: Melinda Shore In-Reply-To: Message from john-ietf@jck.com of "Wed, 30 Jul 2003 19:41:37 EDT." <626443598.1059594097@p3.JCK.COM> Date: Thu, 31 Jul 2003 08:32:32 -0400 Cc: "problem-statement@alvestrand.no" Subject: Re: How we decide that we have decided (was: Re: Sampling) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no > (1) It had better be possible to talk about, and question, the > quality of a claimed consensus. Sampling is an awful way to determine consensus (indeed, it's nearly antithetical to consensus process) and while I think it's clearly appropriate to talk about problems inherent in having a self-selected group of individual determine organizational direction I'm going to quibble and say that the issue here is participation bias, not sampling bias. That said, I'm also somewhat concerned to see people saying that at the plenary there was consensus to ask the IESG to handle the reform process. There was a very large minority who didn't agree, and from where I sat it didn't look very much like even a very, very rough consensus. However I don't think we're going to be able to come to consensus on how to move forward and that we need to think about alternatives to consensus to come to a decision. I think I'm comfortable with the sort of votes that were taken at the plenary - they're certainly better than the alternatives I can think of. > (5) Let me conclude with a personally-troubling example of how > some of this works. Melinda has sent out two messages to try to > validate the meeting "hums". That is a legitimate thing for a > WG Chair to do in the process of trying to determine consensus. > I've read both messages, thought about responding on the several > issues in which my personal opinions are different from the > consensus she has identified, and decided to not do so. Why? > Because in my personal opinion, this WG has been extremely > helpful in discussing and focusing on the issues, but has now > passed sufficiently far into the range of diminishing returns to > have outlived its usefulness. If I were the AD, I'd be trying > to deliver a "wrap this up before I shut it down; it shouldn't > drag out much longer" message. Working groups are not asked to go out, kick around a few ideas, and come to agreement on them. They're asked to produce documents. We've been through the kick-around-a- few-ideas phase and we're now in the process of trying to finalize our documents. It's our intention that the next version of the problem-statement document will go into last call, so I should *certainly* hope that we're now producing diminishing returns. Melinda