Re: Clarification of my comment on giving up on process issues
Frank == Frank Ellermann [EMAIL PROTECTED] writes: Frank IMHO Sam's proposal was meant to help Randy and Harald (as Frank the list-moms of two affected lists), and the IESG with a Frank certain situation (RfC 3934 not good enough, 3683 too Frank disruptive) - as it turned out the IESG didn't need this Frank and went with 3683. My proposal was meant to give the community some room to hash out the mailing list issue and to try and encourage more positive discussion. I've been swamped by day job issues and by some technical work within the IESG and have not gotten back to it. I will try and get the necessary consensus. I do strongly support my proposal and/or something more targeted at a BCP. I'm quite sure I'd resign rather than go through another non-trivial PR-action under the current procedures. --Sam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Clarification of my comment on giving up on process issues
At 16:23 15/04/2006, Frank Ellermann wrote: IMHO Sam's proposal was meant to help Randy and Harald (as the list-moms of two affected lists), and the IESG with a certain situation (RfC 3934 not good enough, 3683 too disruptive) - as it turned out the IESG didn't need this and went with 3683. Dear Frank, having won and completed everything I needed (except two appeals to come), familly priorities, the desire to give time to time, and some calendar timing made me neither comment nor appeal yet. I explained this to the IESG. Everything will be carried in due time. The real problems (IETF ethic, IANA registry nature, deny of consensus, respect of people, minority status, IETF user representation, IETF legitimacy, IESG legal responsibilities, political nature of IETF under RFC 3935, etc. etc) have not been discussed. Without this debate I think Sam's Draft is premature and will be fruitless for the IETF. It is also of a certain importance to the interest of such a debate to identify if the IETF wants to continue being an acknowledged SSDO, or if it wants to become an RFC 3744 afinity group driven lobby. The way the IESG respects the WG-LTRU RFC 3066 Bis consensus will help evaluating this. The way the IAB will address my appeal will also teach us about the way RFC 3869 is to be understood by non-commercial RD entities. jfc ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Clarification of my comment on giving up on process issues
John C Klensin wrote: generally, what those types of proposal need, independent of the process-change model we use, is enough community discussion to permit making a determination that people care and that there is sufficient consensus to move forward. FWIW, I read these drafts up to the point where you wrote NomCom. Because that's only about the paying members I didn't look further. I'd agree that it's odd that some folks, in the recall example IESG members, are excluded from an otherwise simple procedure - but apparently it's never used, so fixing the procedure might be pointless (?) The broader community shows little signs of caring When I read articles on lists like newtrk / pesci / techspec where I'm not subscribed (see my other article about the list management oddities wrt IMA and TOOLS), and all I've to say is excellent idea (e.g. about the decruft experiment), then I won't bother to subscribe only to post an add me. In one newtrk case (auto-demotion from PS to historic) I sent my two cents as PM, and got a reply that this doesn't really help, therefore I didn't try that approach again. (i) Do nothing, on the ground that, if enough people don't care, nothing is severely enough broken. (ii) Go ahead and made the change, partially on the theory that, if it turns out to be significantly worse, _that_ will bring the community out to comment. (iii) Continue thrashing. Thrashing differs from (i) in that (i) doesn't use up community cycles and raise the frustration level. Thrashing does both. Obviously (iii) isn't ideal, but for some newtrk proposals the outcome (zero) is fine from my POV. The three steps can make sense (e.g. STD 66). It's against human nature to get it right in less steps. Three is a minimum - seriously, who cares what I might think about this point ? It's irrelevant. One radical idea could be to weight proposals by RFCs published (you'd end up with a kind of veto right then :-), but probably that's what all folks do silently for themselves, so we need no RFC for it. if we can't even move forward smoothly with 3933 experiments where there seems to be some interest, may be better than (ii).But it is, IMO, a fairly sad state of affairs. IMHO Sam's proposal was meant to help Randy and Harald (as the list-moms of two affected lists), and the IESG with a certain situation (RfC 3934 not good enough, 3683 too disruptive) - as it turned out the IESG didn't need this and went with 3683. The IESG is working like the Holy See, that's no new invention. At least it's mostly transparent (thanks to the tracker). The experiment with public transcriptions was less useful, critical topics were blanked out, the rest only reflected what's already visible - thanks to the tracker and the minutes. Bye, Frank ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Clarification of my comment on giving up on process issues
I'm confused on a minor point... The IESG is working like the Holy See, that's no new invention. At least it's mostly transparent (thanks to the tracker). The experiment with public transcriptions was less useful, critical topics were blanked out, the rest only reflected what's already visible - thanks to the tracker and the minutes. If public transcriptions means IESG telechat narrative minutes (http://www.ietf.org/IESG/iesg-narrative.html), I am one of the people who records them, joining Marshall Eubanks sometime after US Thanksgiving last year. I can remember three times when I was asked to stop typing; twice for discussions about what to do with working groups that are years late on their milestones with WG chairs who aren't answering e-mail, and once on discussions about an appeal. I have gotten corrections from two or three ADs (Bert most often, Ted less often, maybe a couple of ADs who have sent corrections once), and usually these have taken the form of providing background so that someone doesn't have to review previous minutes and mailing list discussions in order to understand what was said in the meeting. There are still things I wish IESG was more transparent about, but the narrative minutes aren't like the US Congress where people insert speeches they never made, at least in my opinion (and the scribes actually send in the final version to be posted, so no one is dorking with the text after we've seen it). Both IESG and the scribes listen very seriously to feedback about how to improve them (current discussions have been about how to get them posted as quickly as possible), so - Frank and others - please continue to tell us what is, and is not, useful. Thanks, Spencer the scribe ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Clarification of my comment on giving up on process issues
Spencer Dawkins wrote: If public transcriptions means IESG telechat narrative minutes (http://www.ietf.org/IESG/iesg-narrative.html) Yes, that's what I meant. I looked into this because I was interested in some then pending appeals (3066bis + SenderID). I can remember three times when I was asked to stop typing; twice for discussions about what to do with working groups that are years late on their milestones with WG chairs who aren't answering e-mail [...] Either I missed that, or I confused it with the appeals: and once on discussions about an appeal. IESG and the scribes listen very seriously to feedback about how to improve them (current discussions have been about how to get them posted as quickly as possible) Quickly is fine, but with some patience the later published terse minutes are very similar - if I know precisely what they are talking about I can guess what's missing, and otherwise I probably have no business to understand what was going on. :-) Bye, Frank ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Clarification of my comment on giving up on process issues
Sam Hartman wrote: Ed == Ed Juskevicius [EMAIL PROTECTED] writes: Ed I wonder if part of the reason is we often resort to a modus Ed operandi of let a thousand flowers bloom and let the market Ed decide for contentious issues. While that *might* work for a Ed technology spec, it clearly is not a workable means of Ed progressing process change proposals. My argument is that proliferation of competing process change proposals may well be an appropriate mechanism for RFC 3933 experiments--even when these are significant process experiments. I think recruiting the stakeholders will provide enough of a gate. But this is only true if the community buys into the approach . There could be simultaneous proposals of course. There could certainly be simultaneous process experiments. However, I guess there couldn't be simultaneous process experiments that are inconsistent with each other. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Clarification of my comment on giving up on process issues
--On Wednesday, 22 March, 2006 13:43 -0500 Sam Hartman [EMAIL PROTECTED] wrote: ... However I don't think we're building the sort of community consensus behind RFC 3933 as an approach to breaking process reform deadlock that it will actually be useful to us. What happens when John submits his nomcom proposal as an RFC 3933 experiment? Would there be any plausable way he could move forward on that proposal using RFC 3933? Not that I can find, which, if you are referring to the Nomcom proposal I think you are, is why I haven't done it. For those who don't remember, it suggested using a different model for first-time appointments to the IESG or IAB than for renewals and building an assumption into the renewal model that two terms were normally good but that more than that probably indicated a problem in progress or likely to occur down the line -- draft-klensin-nomcom-term-00.txt (expired) for the curious. draft-klensin-recall-rev-00.txt is another example of the same thing. There have been an informal in-the-hall discussion or two, but no focused discussion that could be used to move the proposal forward. Unlike the nomcom one, it could presumably be implemented as a process experiment although, extrapolating from the number of recall efforts we've had, the experiment would need to run a rather long time. But, especially without clear community support, the IESG would need to be mildly crazy to adopt it as a process experiment -- it would just seem too self-serving. But, more generally, what those types of proposal need, independent of the process-change model we use, is enough community discussion to permit making a determination that people care and that there is sufficient consensus to move forward. What concerns me most of all these days is that, if one can get a process proposal onto the agenda of some WG, or can introduce it via a meeting convened by some senior member of the Leadership, then it draws a handful of process-weenies and generates comments (perhaps many comments) _from them_. The broader community shows little signs of caring, which leaves us with three alternatives: (i) Do nothing, on the ground that, if enough people don't care, nothing is severely enough broken. (ii) Go ahead and made the change, partially on the theory that, if it turns out to be significantly worse, _that_ will bring the community out to comment. (iii) Continue thrashing. Thrashing differs from (i) in that (i) doesn't use up community cycles and raise the frustration level. Thrashing does both. In that light, 3933 was intended to make (ii) less painful and risky. But it is not useful for changes we don't know how to back out. And, even for those we can back out, the question of whether we should try an experiment to fix a problem that almost no one seems to care about is a challenging one. ... So, I'm close to concluding that we don't have mechanisms for getting consensus on larger process changes and that perhaps the right approach is to just move on with our existing processes. They mostly work after all. This, of course, is a variation on (i) above. It is certainly more efficient than (iii) and, if we can't even move forward smoothly with 3933 experiments where there seems to be some interest, may be better than (ii).But it is, IMO, a fairly sad state of affairs. My argument is that proliferation of competing process change proposals may well be an appropriate mechanism for RFC 3933 experiments--even when these are significant process experiments. I think recruiting the stakeholders will provide enough of a gate. But this is only true if the community buys into the approach . Agree completely. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Clarification of my comment on giving up on process issues
Ed == Ed Juskevicius [EMAIL PROTECTED] writes: Ed I wonder if part of the reason is we often resort to a modus Ed operandi of let a thousand flowers bloom and let the market Ed decide for contentious issues. While that *might* work for a Ed technology spec, it clearly is not a workable means of Ed progressing process change proposals. My argument is that proliferation of competing process change proposals may well be an appropriate mechanism for RFC 3933 experiments--even when these are significant process experiments. I think recruiting the stakeholders will provide enough of a gate. But this is only true if the community buys into the approach . ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Clarification of my comment on giving up on process issues
I have a growing feeling that part of the problem here is that many Working Groups are in effect maintenance activities. The three tier PROPOSED-DRAFT-STANDARD scheme has many accepted flaws, not least the fact that grandfathered specs aside practically nothing ever makes the final step from DRAFT to STANDARD. I think that a bigger problem may well be the fact that RFC 822 is officially THE standard while for all meaningful purposes the real standard is RFC 2822. I think that one of the flaws in the scheme is that the original proposal was designed for specs like IPv4/TCP etc which are effectively fixed for all time on deployment. Most specs are not like that, continuous maintenance is required. If the spec does not require any maintenance it probably indicates that it should probably be shuffled off to HISTORIC. I would like to see a two tier scheme for standards (i.e. eliminate the illogical and misleading status 'DRAFT') but on the understanding that standards require periodic review. By periodic I mean that there should be fixed windows that are scheduled in advance when the standard will be reviewed. There would be a fixed interval in which defect reports could be submitted. One of the topics of the general session for each area would be a report on the defect reports and discussion of whether a new revision WG was required. It might be easier to close WGs down if this was not quite so final. Allowing a 'fast track' for defect reports would encourage proposers to come to the IETF with complete proposals with a substantial degree of consensus in the user and developer communities. If the defect report is justified the need should be widely felt, if as is likely the report is describing existing field practice addressing that need there should not be a need for substantial discussion. In some cases it would be appropriate to reactivate the working group concerned, in others a mini-WG might address multiple protocols. The need is most common in the security area where crypto practices need to be revised every 5 years or so. An area wide activity describing use of SHA-256 would be an example. smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Clarification of my comment on giving up on process issues
On Wed, Mar 22, 2006 05:00:14PM -0800, Hallam-Baker, Phillip allegedly wrote: I would like to see a two tier scheme for standards (i.e. eliminate the illogical and misleading status 'DRAFT') but on the understanding that standards require periodic review. By periodic I mean that there should be fixed windows that are scheduled in advance when the standard will be reviewed. There would be a fixed interval in which defect reports could be submitted. One of the topics of the general session for each area would be a report on the defect reports and discussion of whether a new revision WG was required. It might be easier to close WGs down if this was not quite so final. Allowing a 'fast track' for defect reports would encourage proposers to come to the IETF with complete proposals with a substantial degree of consensus in the user and developer communities. If the defect report is justified the need should be widely felt, if as is likely the report is describing existing field practice addressing that need there should not be a need for substantial discussion. In some cases it would be appropriate to reactivate the working group concerned, in others a mini-WG might address multiple protocols. The need is most common in the security area where crypto practices need to be revised every 5 years or so. An area wide activity describing use of SHA-256 would be an example. It seems to me that if we can't motivate people to review/evaluate/fix a proposed|draft standard once, how can we motivate them to commit to doing so periodically? Are you saying that if we allow them to slap a standard together and declare it done more easily, that they will be more willing to come back and fix it later? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
