Re: IESG Success Stories
On 2007-01-05 20:55, John C Klensin wrote: ... I have two questions... (1) Do you have evidence of actual situations in which an AD behaved in this way, kept concerns to him or herself, and then raised them only, and for the first time, via a DISCUSS after Last Call? How about a case where an AD had decided, before being an AD, not to fight against something s/he thought was misguided, and then found it on the IESG agenda two or three years later? I could give you an example of that. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IESG Success Stories
--On Monday, January 08, 2007 11:21 +0100 Brian E Carpenter [EMAIL PROTECTED] wrote: On 2007-01-05 20:55, John C Klensin wrote: ... I have two questions... (1) Do you have evidence of actual situations in which an AD behaved in this way, kept concerns to him or herself, and then raised them only, and for the first time, via a DISCUSS after Last Call? How about a case where an AD had decided, before being an AD, not to fight against something s/he thought was misguided, and then found it on the IESG agenda two or three years later? I could give you an example of that. In case it wasn't clear, my comment was intended to try to separate what I consider the egregiously bad behavior of deliberately causing late surprises (an activity I have referred to in the past as the IESG, or some ADs, playing gotcha with the community) and situations in which late surprises occur through no one's particular fault. The latter can happen because something is just discovered late in the game (an overall system failure which we should try to avoid or at least minimize, but that will sometimes happen) or for other reasons, but don't involve deliberate bad acts on the part of an AD. The situation you describe is one that, I hope, would be flagged and identified to the WG as early as possible, but I can imagine an AD forgetting about the earlier concerns until the issue popped onto the IESG agenda and then feeling an obligation to object. Too bad, but not, IMO, something that is sufficiently disastrous, or likely to be sufficiently frequent, that we should shape policy around it. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IESG Success Stories
From: Brian E Carpenter [mailto:[EMAIL PROTECTED] On 2007-01-05 20:55, John C Klensin wrote: ... I have two questions... (1) Do you have evidence of actual situations in which an AD behaved in this way, kept concerns to him or herself, and then raised them only, and for the first time, via a DISCUSS after Last Call? How about a case where an AD had decided, before being an AD, not to fight against something s/he thought was misguided, and then found it on the IESG agenda two or three years later? If you want ADs to take on that type of role they have to have a mandate. The NOMCOM process is intentionally designed to eliminate accountability and in the process eliminates any mandate. ADs have the same rights to bring up issues in IETF last call. They should not use their ability to raise objections in private in preference to raising them in public. Clearly there is always the potential for someone to re-read a draft and suddenly realize that there is an issue that they had not seen before. The problem I am having is with the term 'misguided'. This can mean two things: 1) The objector believes that the WG has overlooked an issue or treated it inadequately. 2) The WG looked into an issue in depth and decided to take an opposite approach. This is quite an important issue in the security area. The success rate is not good. We have a serious problem with Internet crime. The way that we have been doing security in the past has clearly not worked. We cannot necessarily wait until everyone in the security area accepts that risk and accountability based schemes are more useful than end-to-end security. Looking at the proposals made for BGPSEC it is very clear to me that our approach is still a minority one within the IETF even though it is arguably now the consensus amongst security protocol designers. DKIM is not designed to do the same set of things that S/MIME and PGP are designed to do. DKIM is not designed to provide non-repudiation, contractual binding or end-to-end security. I think we need to remember here that the IETF began as an institution to facilitate research. There will always be Kuhn type processes underway in some part of the field. And the IAB and IESG will always be filled with people who represent the old view rather than the new. There is a big difference between an individual contributor peddling an anti-gravity machine and a Working Group with ten active members that has both a design and a working model. The risk in allowing type 2 objections to fester is that either the organization splits a second time or we have another case of an aggrieved party making a demonstration. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IESG Success Stories
From: Robert Sayre [mailto:[EMAIL PROTECTED] A few interesting side cases on this. Some ADs (more than one actually) recently suggested to a WG that something there were doing was likely to result in in a DISCUSS when it reached the IESG. One of the WG members appealed the IESG trying to manipulate WG consensus. That's completely inaccurate. It was appealed because the IESG engaged in the behavior I'll quote yet again: I have noticed that often when the IESG card is played the party playing it is not an AD and has absolutely no knowledge of what they speak. In other words it's a bogus recourse to authority, Unless you do everything my way then you will get in trouble. It is a particularly corrosive maneuver. The best way to counter it is for someone in the group to make a direct enquiry to the AD responsible for the WG whenever the card is played. It soon stops. One other point in this debate that seems to have been lost. Somethimes it is necessary to create a spec just to prove that the approach is fundamentally broken and will fail in the real world. There are certain aspects of PKIX that I think are woefully misguided but this does not mean that I would fillibuster them or even sell product based on them if the market was to choose to adopt them. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IESG Success Stories
Cullen Jennings schrieb: On Jan 5, 2007, at 10:03 AM, Michael Thomas wrote: My gripe is when an outside AD takes an interest in the work, goes to the f2f meetings, maybe reads the drafts but then waits to IESG evaluation time to DISCUSS their issues. If they know they have a problem(s), it would be *far* better to air that sooner rather than later for all parties concerned. I agree with the earlier is better than later for comments from anyone, AD or not. A few interesting side cases on this. Some ADs (more than one actually) recently suggested to a WG that something there were doing was likely to result in in a DISCUSS when it reached the IESG. One of the WG members appealed the IESG trying to manipulate WG consensus. Sort of left me scratching my head on why the WG would not want to know that early but evidently some folks don't. ... Cullen, in case you're talking about APP and HTTP authentication...: my recollection is that that WG member in fact tried to *defend* the WG consensus. The new (rough) WG consensus (after the announcement of a forthcoming DISCUSS) IMHO clearly falls into the category we don't care enough to pursue the discussion. And that is really A Bad Thing. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IESG Success Stories
Brian E Carpenter wrote: Michael, 1. ADs physically don't have time to read intermediate drafts oustide their own Area. So while they may suspect that a WG is heading in a worrisome direction, they aren't in a position to do much about it. 2. ADs are collectively instructed by our rules to act as the reviewers of last resort - it's the IESG that takes the final responsibility to say a document is good enough. 3. Unfortunately, WGs do sometimes agree on drafts that prove to have signifcant defects when critically reviewed outside the WG. Put these facts together and you *will* get a reasonable rate of significant (i.e. hard to resolve) DISCUSSes, and in the nature of things they will come from ADs outside the Area concerned. Brian -- My focus was actually a lot more narrow: I wasn't trying to insist that AD's be super-human, and I honestly believe that the job they do is extremely difficult. My gripe is when an outside AD takes an interest in the work, goes to the f2f meetings, maybe reads the drafts but then waits to IESG evaluation time to DISCUSS their issues. If they know they have a problem(s), it would be *far* better to air that sooner rather than later for all parties concerned. Doing this leads to the perception of a imperious and capricious IESG. This is a very different situation where you get a DISCUSS where it's a surprise to all parties from an AD not involved at all; the former should have been resolved before it got to last call, the latter is the process working correctly. IMO. Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IESG Success Stories
--On Friday, 05 January, 2007 10:03 -0800 Michael Thomas [EMAIL PROTECTED] wrote: My focus was actually a lot more narrow: I wasn't trying to insist that AD's be super-human, and I honestly believe that the job they do is extremely difficult. My gripe is when an outside AD takes an interest in the work, goes to the f2f meetings, maybe reads the drafts but then waits to IESG evaluation time to DISCUSS their issues. If they know they have a problem(s), it would be *far* better to air that sooner rather than later for all parties concerned. Doing this leads to the perception of a imperious and capricious IESG. Michael, I have two questions... (1) Do you have evidence of actual situations in which an AD behaved in this way, kept concerns to him or herself, and then raised them only, and for the first time, via a DISCUSS after Last Call? (2) If the answer to (1) is yes, why didn't you, and the other people who were impacted, immediately file recall petitions? The second question is not rhetorical. We all understand that recalls would be painful and destructive, that would they take too long to have much practical impact, and so on. However, the behavior I think you are describing would be such an egregious violation of the ways that the community and the IESG should be interacting with each other that I believe a recall would be appropriate even for someone whose term on the IESG had only a few months remaining: it would be at least as important to establish a clear message that the behavior is unacceptable, ever, as it would be to get the person off the IESG. No one is valuable enough, hard-working enough, or smart enough that the community should put up with the behavior I think you are describing, even for a minute.And that implies to me that there should be no perception that an AD can get away with it. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IESG Success Stories
I strongly agree with John's reasoning here. But please keep reading... From: John C Klensin [EMAIL PROTECTED] I have two questions... (1) Do you have evidence of actual situations in which an AD behaved in this way, kept concerns to him or herself, and then raised them only, and for the first time, via a DISCUSS after Last Call? (2) If the answer to (1) is yes, why didn't you, and the other people who were impacted, immediately file recall petitions? The second question is not rhetorical. We all understand that recalls would be painful and destructive, that would they take too long to have much practical impact, and so on. However, the behavior I think you are describing would be such an egregious violation of the ways that the community and the IESG should be interacting with each other that I believe a recall would be appropriate even for someone whose term on the IESG had only a few months remaining: it would be at least as important to establish a clear message that the behavior is unacceptable, ever, as it would be to get the person off the IESG. No one is valuable enough, hard-working enough, or smart enough that the community should put up with the behavior I think you are describing, even for a minute.And that implies to me that there should be no perception that an AD can get away with it. john Now, backing off a few billion nanometers, When Michael kicked off this thread, his posting began: So what occurs to me is that a reasonable question to ask is whether there are some legitimate success stories where a DISCUSS has actually found big or reasonably big problems with a protocol that would have wreaked havoc had they not been caught. I ask because ... My impression is that drafts that capture experience with IETF working group dynamics are painful and useful (thinking specifically of the case studies in the draft that became http://www.ietf.org/rfc/rfc3669.txt). I think Michael's question is important enough to answer. I think I can think of some examples where the answer is yes, but this isn't about what *I* think, it's about what our experience has been. Do other people think that collecting DISCUSS success stories is helpful? I have two points to add - - Michael asked specifically about SUCCESS stories. The level of cynicism in the circles I run being sufficiently high, I'm asking about the same thing Michael is asking about, where success matches the dictionary definition. - if people want to collect DISCUSS success stories, of the more ironic nature, I ask that we do this, going forward, and not looking backward. Depending on how you count Jon Peterson, we seated new ADs for almost half the IESG last year, and we know that we will pick up at least a few more new ADs this year, because some people have already said they will not return. We don't need to replay 30 years of history, and even going back to the beginning of ID tracker use would be less than helpful. If you have relevant deep dirt from the recent past, please feel free to file recalls and provide NomCom input, of course. But I hope everyone already knows that. Thanks, Spencer ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IESG Success Stories
On Jan 5, 2007, at 10:03 AM, Michael Thomas wrote: My gripe is when an outside AD takes an interest in the work, goes to the f2f meetings, maybe reads the drafts but then waits to IESG evaluation time to DISCUSS their issues. If they know they have a problem(s), it would be *far* better to air that sooner rather than later for all parties concerned. I agree with the earlier is better than later for comments from anyone, AD or not. A few interesting side cases on this. Some ADs (more than one actually) recently suggested to a WG that something there were doing was likely to result in in a DISCUSS when it reached the IESG. One of the WG members appealed the IESG trying to manipulate WG consensus. Sort of left me scratching my head on why the WG would not want to know that early but evidently some folks don't. There have been other working groups where it was very hard to make an argument and get anyone to listen - lots of people just give up and decide to send their comments in IETF LC or not at all. That's really unfortunate but I understand that people have a limited time to go argue about stuff that is not even their work. Cullen ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IESG Success Stories
On Fri, 5 Jan 2007 17:17:33 -0800 Cullen Jennings [EMAIL PROTECTED] wrote: On Jan 5, 2007, at 10:03 AM, Michael Thomas wrote: My gripe is when an outside AD takes an interest in the work, goes to the f2f meetings, maybe reads the drafts but then waits to IESG evaluation time to DISCUSS their issues. If they know they have a problem(s), it would be *far* better to air that sooner rather than later for all parties concerned. I agree with the earlier is better than later for comments from anyone, AD or not. A few interesting side cases on this. Some ADs (more than one actually) recently suggested to a WG that something there were doing was likely to result in in a DISCUSS when it reached the IESG. One of the WG members appealed the IESG trying to manipulate WG consensus. Sort of left me scratching my head on why the WG would not want to know that early but evidently some folks don't. It's a delicate balance. When I was an AD, I'd often post things saying AD hat=off ... /AD and the like; I've seen other ADs do the same thing, both on lists and in person. It's not clear that people always believe the disclaimer. Even more care is necessary when warning of a DISCUSS. Is that an accurate prediction of your own or someone else's liely views, or is it an attempt to get one's way by threatening to block a legitimate choice you don't like? How will it be perceived? On the other hand, I sometimes had long, detailed discussions with WG chairs and document authors, often at the instigation of the responsible AD, trying to convey my concerns ahead of time, trying to get things resolved to my satisfaction. Finally, there was one document I abstained on, because it was terminally broken and not repairable, but was the product of too many years work for me, as a relatively new AD (and hence as one who hadn't seen it before) to block. But I declined to say no objection, because I had very strenuous objections to it. I'm glad there's a document being written to set forth DISCUSS criteria. I had lots of discussions with Harald about the number I issued -- he wanted me to justify some of them with more than the text I wrote. Is this issue serious enough to block publication of the document as is? Obviously, I thought so, but not everyone on the IESG agreed with me on some of those cases. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IESG Success Stories
Folks, as implemented by a WG participant, will not change one whit, but where the implementation by a non-participant changes from improbable to possible, because it's clear what the words were intended to say. Another example of wordsmithing that does not change the mechanics of the protocol, but is nevertheless important, is the IANA considerations Let's be clear: A Discuss blocks the document. It is an exercise of power. It is necessary and appropriate to use a Discuss when there is a fundamental problem with the document, or a strong indication of a fundamental problem. We should all think hard about the word fundamental, because use of a Discuss for anything other than that is an abuse of power; it wastes resources and good will. ADs make comments that do not block the document. Presumably they would not make comments unless they thought they would be heeded. This is good, because my own experience is that working groups tend to be mindful of *all* AD statements, Discuss or Comment, since most working groups really do want a specification to be good quality. The difference is that, as noted by someone else's post, the working group worries about clearing the Discuss. That's different from worrying about quality. Working groups either do or do not worry about (their definition of) quality. Alln exercise in IESG power or a failure to exercise power won't change that. It might salvage a marginal spec, but it won't make any difference for a spec that is solid or one that is garbage. Getting a discuss vs. comment does not change this. Using a Discuss will not make bad work good. Using a Comment will not result in a good working group's ignoring the input. What we are caught in, I believe, is a failure to be careful, as in selective. Working groups are careful or sloppy. So are ADs. We need to get into synch about both the exercise of power and the goal of quality. It needs to have more to do with satisfying real-world need than with bureaucracy or abstract idealism about the purity of architecture. Bureaucracy and idealism can be quite helpful, but only *in the service of* satisfying real-world need. We used to be pretty good at that. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IESG Success Stories
On 1/5/07, Cullen Jennings [EMAIL PROTECTED] wrote: On Jan 5, 2007, at 10:03 AM, Michael Thomas wrote: My gripe is when an outside AD takes an interest in the work, goes to the f2f meetings, maybe reads the drafts but then waits to IESG evaluation time to DISCUSS their issues. If they know they have a problem(s), it would be *far* better to air that sooner rather than later for all parties concerned. I agree with the earlier is better than later for comments from anyone, AD or not. A few interesting side cases on this. Some ADs (more than one actually) recently suggested to a WG that something there were doing was likely to result in in a DISCUSS when it reached the IESG. One of the WG members appealed the IESG trying to manipulate WG consensus. That's completely inaccurate. It was appealed because the IESG engaged in the behavior I'll quote yet again: Dave Crocker wrote: There is often a failure to distinguish between new and peculiar problems created by a particular specification, versus general problems that already exist. A classic example of this is citing basic DNS problems, for specifications that are merely consumers of the DNS and, hence, are not creating any new problems. Another classic example is citing a basic HTTP security trade-off, and requiring implementations to make specific choices about centralization, internationalization, graphic design, scalability, and security in order to remain conformant. But I digress. Sort of left me scratching my head on why the WG would not want to know that early but evidently some folks don't. Knowing early is good. Sometimes, the IESG happens to insist on inaccurate and irrelevant requirements, and argument from authority sometimes results in appeals. There's nothing wrong with that. But let's face it--no one in the WG was worried about a dicussion. They were worried that the document would be blocked for ideological reasons. -- Robert Sayre I would have written a shorter letter, but I did not have the time. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IESG Success Stories
Michael, On 2006-12-31 03:00, Michael Thomas wrote: John C Klensin wrote: If an AD who was responsible for a WG came up with an issue about that WG's work and raised it only during or after Last Call, I'd expect either a really good explanation or a resignation. I certainly would not expect it to happen often. But, IMO, we have an IESG and, indeed, an IETF rather than a collection of different organizations addressing per-area issues precisely to increase the odds of catching serious cross-area and cross-perspective issues before things go out. Like it or not, unless the relevant WG makes an effort to get broad reviews at critical early points, there will always be a risk of late surprises as someone --in the community during Last Call or on the IESG-- suddenly wakes up and says but how does this relate to XYZ. I was obviously not clear enough on my first post because I wasn't referring to the shepherding AD or the poor AD's who have paid no attention at all who are then tapped to do their job. It's really the in between AD's that I think really exasperate the wg participants -- if they've paid enough attention to attend the wg meetings and perhaps even subscribe to the mailing list and registered concerns, I really think they owe it to the working group to either get them out when the working group is in active issue resolving mode, or to... well, just live with it. Or something. Frankly it does a lot of damage to the IESG's reputation when you know that there's likely going to be trouble, but there is nothing you can do to fend it off ahead of time because those AD's have only given vague allusions to their non-amusement. It promotes the vision of the unitary IESG which I think is a bad thing. I think you're overlooking two or three facts that collide at a single point: 1. ADs physically don't have time to read intermediate drafts oustide their own Area. So while they may suspect that a WG is heading in a worrisome direction, they aren't in a position to do much about it. 2. ADs are collectively instructed by our rules to act as the reviewers of last resort - it's the IESG that takes the final responsibility to say a document is good enough. 3. Unfortunately, WGs do sometimes agree on drafts that prove to have signifcant defects when critically reviewed outside the WG. Put these facts together and you *will* get a reasonable rate of significant (i.e. hard to resolve) DISCUSSes, and in the nature of things they will come from ADs outside the Area concerned. However, the DISCUSS non-criteria are specifically intended to exclude capricious I don't like this discusses. BTW, I'm an author (draft-ietf-v6ops-nap-05.txt) trying to resolve a very complex DISCUSS from an AD outside the Area. I believe the document will be much better as a result, even though it's a painful process. And it's largely a result of the WG having a narrower view of the universe than is ideal. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IESG Success Stories
--On 30. desember 2006 18:00 -0800 Michael Thomas [EMAIL PROTECTED] wrote: With regard to textual nit-picking and evaluation of worthiness of prose, I tend to agree with what I think you are saying. However, if a document is too badly written to permit interoperable implementations to be constructed without clarifying conversations among implementers, authors, and/or the WG, then the document is a failure and needs pushback. As with late surprises, somewhat more proactive effort on the part of WGs could prevent many of the problems we see, but... I was using wordsmithing rather broadly. My probably idiosyncratic meaning of wordsmithing here was will this DISCUSS change the mechanics of the protocol or not. If the answer is no, we're really just making the document more ready for publication IMO. Something that does bring that possibility is obviously a lot more serious. It's been my admittedly limited experience that my version of wordsmithing is a lot more common, and the source of a lot of delay to varying degrees of dubiousness. One meaning of wordsmithing resulting from a DISCUSS that I think is an entirely worthwhile activity is where the mechanics of the protocol, as implemented by a WG participant, will not change one whit, but where the implementation by a non-participant changes from improbable to possible, because it's clear what the words were intended to say. Another example of wordsmithing that does not change the mechanics of the protocol, but is nevertheless important, is the IANA considerations stuff - while it does not change the protocol as such, it does change the meta-protocol of extending the protocol later. That's important. Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IESG Success Stories
--On Monday, 01 January, 2007 15:30 +0100 Harald Alvestrand [EMAIL PROTECTED] wrote: I was using wordsmithing rather broadly. My probably idiosyncratic meaning of wordsmithing here was will this DISCUSS change the mechanics of the protocol or not. If the answer is no, we're really just making the document more ready for publication IMO. Something that does bring that possibility is obviously a lot more serious. It's been my admittedly limited experience that my version of wordsmithing is a lot more common, and the source of a lot of delay to varying degrees of dubiousness. One meaning of wordsmithing resulting from a DISCUSS that I think is an entirely worthwhile activity is where the mechanics of the protocol, as implemented by a WG participant, will not change one whit, but where the implementation by a non-participant changes from improbable to possible, because it's clear what the words were intended to say. Another example of wordsmithing that does not change the mechanics of the protocol, but is nevertheless important, is the IANA considerations stuff - while it does not change the protocol as such, it does change the meta-protocol of extending the protocol later. That's important. Harald, I could be wrong, but I believe that, if every instance of a discuss for wordsmithing purposes fell into one of the categories you have described above, we would not be having this discussion. I continue to believe that the document that started the original thread is not the right place to fix the problem. However, I suggest that there is a perception in the community --one that can be fairly well documented with specific episodes-- of long approval and publication delays that started with a discuss about issues of prose or presentation that do not have either significant this is wrong protocol impact or the level of impact you describe above. That, of course, leads to another discussions: when evaluating IESG or RFC Editor performance, we tend to assume that any delay between when the token is passed back to a WG or author and when it returns is a WG or author problem and doesn't count. In some cases, it clearly is a WG or author problem. But, in others, it is at least partially the result of a natural reaction: after all of the work that went into this, we just don't have the energy to deal with that level of nit-picking. And since, unfortunately, there is often no way for an outsider to differentiate the two, we need to better understand and appreciate the costs of discuss positions that do not have a clear, substantive, basis appropriate to the maturity level of the proposal, even ones whose intent is to get additional explanations and understanding, to overall IETF productivity. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IESG Success Stories
John C Klensin wrote: --On Monday, 01 January, 2007 15:30 +0100 Harald Alvestrand [EMAIL PROTECTED] wrote: I was using wordsmithing rather broadly. My probably idiosyncratic meaning of wordsmithing here was will this DISCUSS change the mechanics of the protocol or not. If the answer is no, we're really just making the document more ready for publication IMO. Something that does bring that possibility is obviously a lot more serious. It's been my admittedly limited experience that my version of wordsmithing is a lot more common, and the source of a lot of delay to varying degrees of dubiousness. One meaning of wordsmithing resulting from a DISCUSS that I think is an entirely worthwhile activity is where the mechanics of the protocol, as implemented by a WG participant, will not change one whit, but where the implementation by a non-participant changes from improbable to possible, because it's clear what the words were intended to say. Another example of wordsmithing that does not change the mechanics of the protocol, but is nevertheless important, is the IANA considerations stuff - while it does not change the protocol as such, it does change the meta-protocol of extending the protocol later. That's important. Harald, I could be wrong, but I believe that, if every instance of a discuss for wordsmithing purposes fell into one of the categories you have described above, we would not be having this discussion. I continue to believe that the document that started the original thread is not the right place to fix the problem. However, I suggest that there is a perception in the community --one that can be fairly well documented with specific episodes-- of long approval and publication delays that started with a discuss about issues of prose or presentation that do not have either significant this is wrong protocol impact or the level of impact you describe above. I think we're on the same page (or at least in the same chapter of the book). My note was just intended to say that I don't agree with the reading of Michael's statement that says a DISCUSS is just make-work if it doesn't require a protocol change. I don't think Michael agrees with that reading either, but it was possible to read his note that way. That, of course, leads to another discussions: when evaluating IESG or RFC Editor performance, we tend to assume that any delay between when the token is passed back to a WG or author and when it returns is a WG or author problem and doesn't count. In some cases, it clearly is a WG or author problem. But, in others, it is at least partially the result of a natural reaction: after all of the work that went into this, we just don't have the energy to deal with that level of nit-picking. And since, unfortunately, there is often no way for an outsider to differentiate the two, we need to better understand and appreciate the costs of discuss positions that do not have a clear, substantive, basis appropriate to the maturity level of the proposal, even ones whose intent is to get additional explanations and understanding, to overall IETF productivity. The problem of working groups that emit documents as their last gasp before dying from lack of energy is, in my opinion, a much harder problem to tackle than that of browbeating the IESG into DISCUSS discipline - and one where, if the IESG's energy was suddenly magically to double, I'd definitely advise directing the windfall surplus. Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IESG Success Stories
--On Tuesday, 02 January, 2007 00:12 +0100 Harald Alvestrand [EMAIL PROTECTED] wrote: The problem of working groups that emit documents as their last gasp before dying from lack of energy is, in my opinion, a much harder problem to tackle than that of browbeating the IESG into DISCUSS discipline - and one where, if the IESG's energy was suddenly magically to double, I'd definitely advise directing the windfall surplus. Precisely because this subtopic is a harder one, one clarification. I was not referring to emit as WG last gasp situations, although those would clearly also apply. I was referring to the more common situation in which a WG has reached the exhaustion point on a particular document, possibly because it has been the result of very careful, but tiring, negotiations over language as well as substance. For that class of document, a please engage in fine tuning request, even if that request is accompanied by very specific suggestions, can easily lead to an oh no, we can't revisit _that_ again reaction that can lead to significant delays, even if the WG and editors/authors are otherwise completely healthy and committed. From my parochial point of view as someone who still believes in a multi-step standards process, this is yet another argument as to why the IESG should adopt and strengthen an if it isn't clearly harmful, let it go attitude toward documents moving toward Proposed Standard, regardless of what the current discuss document does or does not permit. It would, IMO, be entirely appropriate for the IESG to include with the approval of a document --possibly even as part of the protocol action notice-- a clear message that there isn't a chance that the document would be approved for advancement to Draft without considerable improvements in editorial quality and that the time to start working on those issues is probably immediately... but not to hold a would-be Proposed Standard document up waiting. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IESG Success Stories (was: Discuss criteria)
That would be a subjective judgement. Until recently the overriding assumption in the security area was that the worst thing we could possibly do is to deploy a broken protocol. That is empirically not true. At this point we have precisely two cryptographic security protocols that can be regarded as a success: SSL and WEP. And the original design of both was botched. If the IESG had stopped SSL 1.0 from going ahead it would clearly have been a success, but what if we had done the usual thing of delaying SSL 2.0 till it provided perfect forward secrecy and we were absolutely convinced that there were no problems of any kind whatsoever? Excessive caution can be worse than suck-it-and-see. Designing a security protocol is the easy part, we can all do that tollerably well. Certainly we can all do it well enough to get to the point where the crypto is not the weakest link in the chain. The typical Internet user assumes that the Internet is secure in ways that it is not. Members of the IESG appear to have a very different view of what it is doing to what I see in the working groups. In every working group I have been a part of the IESG has been generally considered to be a procedural obstacle to be gamed rather than a partner to work with. The Internet is changing the way we view knowledge. The IETF constitution pretty much reflects the logical positivist view that was the norm amongst engineers in the 1980s/1990s. Today we live in the post-modern world of Wikiality. Knowledge claims are viewed as being intrinsically provisional rather than extrinsically authoritative. I think that as with the fear 'don't ever deploy crypto, we might get it wrong' many of the concerns on which the IETF structure are designed to address are actually obsolete. In this case made obsolete by the effects of the technology the organization is helping to create. Does it matter to the organization if a WG produces a baddly written spec? Does it harm anything other than their own chances of success? -Original Message- From: Michael Thomas [mailto:[EMAIL PROTECTED] Sent: Saturday, December 30, 2006 10:09 AM To: Hallam-Baker, Phillip Cc: John C Klensin; [EMAIL PROTECTED]; [EMAIL PROTECTED]; ietf@ietf.org Subject: IESG Success Stories (was: Discuss criteria) So what occurs to me is that a reasonable question to ask is whether there are some legitimate success stories where a DISCUSS has actually found big or reasonably big problems with a protocol that would have wreaked havoc had they not been caught. I ask because it seems to me that the main things that wreak havoc with protocols tend to be rather subtle and not likely to be very visible to someone whose sum experience with the work is their assignment to read the current draft. That's not a slap at the people whose job is to review, only that it seems to me to be asking for super-human abilities. From my limited experience with DISCUSS -- and last call for that matter -- is that the focus is far more geared toward wordsmithing than actual mechanics of the protocol (from relatively disinterested parties, that is). While I have no issue with tightening up drafts for publication, it doesn't seem reasonable to be holding up the works for endless amounts of time _just_ because somebody -- or some faction of bodies -- isn't convinced that a draft is the prose they deign worthy. The other thing that occurs to me -- and I know this has been brought up in many different forms -- is that if an AD _was_ following the working group to some degree, why is it legitimate for them to wait for IESG evaluation to voice comments that affect the protocol's operation? That is, why aren't they held just like anybody else to voice those in WG last call when the WG is far more responsive to dealing with issues? These IESG Surprises really hurt the community by leading to the general perception that the IESG is capricious in a royally anointed kind of way. Mike Hallam-Baker, Phillip wrote: More recalls? How many have we had? I looked into what it would take to engage the recall process. I don't think it is possible to use it without tearing the whole organization appart. With reference to John's recent campaigns I note that we still have a situation where IETF practice is to employ a two stage standards process but the process documents describe a mythical three stage process. The IESG appears to be unwilling to either change the process document to reflect reality or to begin applying the three stage process. And I don't even have visibility into the process to know which individuals are the holdouts. The only response I am ever going to get back is the passive voice 'people on the IESG were not happy with the proposal'. This is a real business issue for me, not a theoretical one. I spend too much time having to counter FUD claims
Re: IESG Success Stories
Michael Thomas schrieb: ... those in WG last call when the WG is far more responsive to dealing with issues? These IESG Surprises really hurt the community by leading to the general perception that the IESG is capricious in a royally anointed kind of way. Mike And things get even worse when the response to the IESG Surprise is: we will fix that during AUTH48. There's absolutely no transparency in that, and no checking by the community. I'd really like to see the IESG stop sending documents with known defects to the RFC Editor. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IESG Success Stories (was: Discuss criteria)
On Sat, 30 Dec 2006 07:09:21 -0800 Michael Thomas [EMAIL PROTECTED] wrote: The other thing that occurs to me -- and I know this has been brought up in many different forms -- is that if an AD _was_ following the working group to some degree, why is it legitimate for them to wait for IESG evaluation to voice comments that affect the protocol's operation? Most ADs don't follow most WGs in any detail -- they can't possibly do so. They should (and generally do) follow their own WGs, possibly the others in their area, plus one or two elsewhere that they're personally interested in. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IESG Success Stories (was: Discuss criteria)
--On Saturday, December 30, 2006 7:09 AM -0800 Michael Thomas [EMAIL PROTECTED] wrote: ... The other thing that occurs to me -- and I know this has been brought up in many different forms -- is that if an AD _was_ following the working group to some degree, why is it legitimate for them to wait for IESG evaluation to voice comments that affect the protocol's operation? That is, why aren't they held just like anybody else to voice those in WG last call when the WG is far more responsive to dealing with issues? These IESG Surprises really hurt the community by leading to the general perception that the IESG is capricious in a royally anointed kind of way. Michael, If an AD who was responsible for a WG came up with an issue about that WG's work and raised it only during or after Last Call, I'd expect either a really good explanation or a resignation. I certainly would not expect it to happen often. But, IMO, we have an IESG and, indeed, an IETF rather than a collection of different organizations addressing per-area issues precisely to increase the odds of catching serious cross-area and cross-perspective issues before things go out. Like it or not, unless the relevant WG makes an effort to get broad reviews at critical early points, there will always be a risk of late surprises as someone --in the community during Last Call or on the IESG-- suddenly wakes up and says but how does this relate to XYZ. With regard to textual nit-picking and evaluation of worthiness of prose, I tend to agree with what I think you are saying. However, if a document is too badly written to permit interoperable implementations to be constructed without clarifying conversations among implementers, authors, and/or the WG, then the document is a failure and needs pushback. As with late surprises, somewhat more proactive effort on the part of WGs could prevent many of the problems we see, but... (1) While I think the worst problems got fixed, RFC 4714 can be seen as an effort to either de-skill the RFC Editor function or to recognize that our expectations of that function a decade ago are no longer consistent with today's realities. If we are not to publish documents that are incomprehensible, then someone has to have the responsibility and authority to either fix them or push back on them. If it is going to be the RFC Editor, then we should be pushing back every time an IESG member complains about an editorial matter smaller than the document is incomprehensible and cannot be evaluated or implemented ... and we should (again) be giving the RFC Editor the authority to refuse to publish an IESG-approved document because it cannot be safely edited into comprehensible form. If it isn't going to be the RFC Editor, then it probably needs to be the IESG --or some significant process changes-- and we should stop complaining. (2) My comments about the expectation of good sense and community willingness to abuse and/or fire those who don't exercise it are very much applicable to the above. I don't have any idea how to write rules that will improve the situation without very high risk of tying ourselves in knots _and_ not solving the underlying problem. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IESG Success Stories
Hallam-Baker, == Hallam-Baker, Phillip [EMAIL PROTECTED] writes: Hallam-Baker, That is empirically not true. At this point we have Hallam-Baker, precisely two cryptographic security protocols that Hallam-Baker, can be regarded as a success: SSL and WEP. And the Hallam-Baker, original design of both was botched. Sorry, I'd say Kerberos is a success as well as ssh. Both of them demonstrate the point you're trying to make though. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IESG Success Stories
Accepted, Though bringing up kerberos illustrates the kind of case where iesg could have been a benefit. The master secret in SSL is 48 bytes, a length that gives no more security than 128 bits would for the ciphers used but which prevents embedding the encrypted master secret in the session Id to create. Kerberos like ticket. THAT is a case where an IESG hanng on a second could have been a real value. It took many years to get a fix out for that. Sent from my GoodLink Wireless Handheld (www.good.com) -Original Message- From: Sam Hartman [mailto:[EMAIL PROTECTED] Sent: Saturday, December 30, 2006 10:28 AM Pacific Standard Time To: Hallam-Baker, Phillip Cc: Michael Thomas; John C Klensin; ietf@ietf.org; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject:Re: IESG Success Stories Hallam-Baker, == Hallam-Baker, Phillip [EMAIL PROTECTED] writes: Hallam-Baker, That is empirically not true. At this point we have Hallam-Baker, precisely two cryptographic security protocols that Hallam-Baker, can be regarded as a success: SSL and WEP. And the Hallam-Baker, original design of both was botched. Sorry, I'd say Kerberos is a success as well as ssh. Both of them demonstrate the point you're trying to make though. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IESG Success Stories
John C Klensin wrote: If an AD who was responsible for a WG came up with an issue about that WG's work and raised it only during or after Last Call, I'd expect either a really good explanation or a resignation. I certainly would not expect it to happen often. But, IMO, we have an IESG and, indeed, an IETF rather than a collection of different organizations addressing per-area issues precisely to increase the odds of catching serious cross-area and cross-perspective issues before things go out. Like it or not, unless the relevant WG makes an effort to get broad reviews at critical early points, there will always be a risk of late surprises as someone --in the community during Last Call or on the IESG-- suddenly wakes up and says but how does this relate to XYZ. I was obviously not clear enough on my first post because I wasn't referring to the shepherding AD or the poor AD's who have paid no attention at all who are then tapped to do their job. It's really the in between AD's that I think really exasperate the wg participants -- if they've paid enough attention to attend the wg meetings and perhaps even subscribe to the mailing list and registered concerns, I really think they owe it to the working group to either get them out when the working group is in active issue resolving mode, or to... well, just live with it. Or something. Frankly it does a lot of damage to the IESG's reputation when you know that there's likely going to be trouble, but there is nothing you can do to fend it off ahead of time because those AD's have only given vague allusions to their non-amusement. It promotes the vision of the unitary IESG which I think is a bad thing. With regard to textual nit-picking and evaluation of worthiness of prose, I tend to agree with what I think you are saying. However, if a document is too badly written to permit interoperable implementations to be constructed without clarifying conversations among implementers, authors, and/or the WG, then the document is a failure and needs pushback. As with late surprises, somewhat more proactive effort on the part of WGs could prevent many of the problems we see, but... I was using wordsmithing rather broadly. My probably idiosyncratic meaning of wordsmithing here was will this DISCUSS change the mechanics of the protocol or not. If the answer is no, we're really just making the document more ready for publication IMO. Something that does bring that possibility is obviously a lot more serious. It's been my admittedly limited experience that my version of wordsmithing is a lot more common, and the source of a lot of delay to varying degrees of dubiousness. Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IESG Success Stories
--On Saturday, December 30, 2006 6:00 PM -0800 Michael Thomas [EMAIL PROTECTED] wrote: I was using wordsmithing rather broadly. My probably idiosyncratic meaning of wordsmithing here was will this DISCUSS change the mechanics of the protocol or not. If the answer is no, we're really just making the document more ready for publication IMO. Something that does bring that possibility is obviously a lot more serious. It's been my admittedly limited experience that my version of wordsmithing is a lot more common, and the source of a lot of delay to varying degrees of dubiousness. My own personal, long-standing view, is that clear enough to implement together with comprehensible, even with some effort ought to be the requirement for Proposed, with anything more than that either after Last Call or immediately before it just being a waste of time and a poor use of resources. Personally, I'd apply a similar standard to what I expect the RFC Editor to do. While the formal procedures say nothing about this particular issue, I've got a much higher threshold for Draft: I think those documents should not require more effort to read than the underlying protocol itself requires. From your comment above, I think that puts us in near-, if not complete, agreement. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IESG Success Stories (was: Discuss criteria)
From: John C Klensin [mailto:[EMAIL PROTECTED] Michael, If an AD who was responsible for a WG came up with an issue about that WG's work and raised it only during or after Last Call, I'd expect either a really good explanation or a resignation. Surely this is going to happen all the time since the DISCUSS might well be the result of comments brought up on the IETF mailing list which the responsible AD might be expected to take notice of. It is an IETF last call, not an IESG affair. Or at least so is the theory. With regard to textual nit-picking and evaluation of worthiness of prose, I tend to agree with what I think you are saying. However, if a document is too badly written to permit interoperable implementations to be constructed without clarifying conversations among implementers, authors, and/or the WG, then the document is a failure and needs pushback. I think it depends on whether we are talking about Proposed or Draft. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
