Re: As Promised, an attempt at 2026bis
On Oct 3, 2006, at 4:00 AM, Brian E Carpenter wrote: Brian Carpenter has written draft-carpenter-rfc2026- critique-02.txt which does exactly that, and he has repeatedly solicited comments on it. If you think that it would be helpful to have it published as an informational RFC before undertaking to make normative changes to our standards procedures, please say so. Thanks for the plug, Mike :-) Quite seriously - am I to conclude from the absence of comments on that draft that everyone agrees that it correctly describes current practice? If so, I'll look for an AD to sponsor it. Please do. -Doug ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: As Promised, an attempt at 2026bis
Eliot, The goal of draft-carpenter-rfc2026-critique-02 is rather different from the goal of the two previous versions, and it might have been better to change the file name as well as removing 'critique' from the document title. The intent of the -02 version is to document, for information only, how actual practice interprets the formal rules. I'm not sure you've read it in that spirit. Brian Eliot Lear wrote: Brian E Carpenter wrote: Quite seriously - am I to conclude from the absence of comments on that draft that everyone agrees that it correctly describes current practice? If so, I'll look for an AD to sponsor it. You asked. Your critique itself has its pluses and minuses. On the plus side you've at least identified some of the issues that have made the document a little long in the tooth, like ASes, RFC Editor text, standard levels, interoperability reports, IPR etc. However, you have missed the forest from the trees. The fundamental description of how we behave as an organization is lost in a section by section critique. It would have been better for you to update RFC 2026 with an appendix explaining the changes and why they are necessary to reflect reality. Oh wait. I've done (or at least begun) that. Here are specific comments about your section by section critique: I think you've misinterpreted section 3.3, which discusses levels of requirements for standards themselves, not individual components of TS documents. But beyond this one has to question the whole notion of requirement levels such as those in that section. Why should they be there at all? The IETF has no force of authority other than moral, and people are not going to write code -- or support it -- for the sake of the IETF's moral authority. Similarly the discussion regarding Independent RFCs. We don't need to critique the words since the IAB RFC Editor are working on an update. Let's go critique THOSE words. You document the broken rather than fix it. See, for instance, your commentary about PS. You yourself call out confusion regarding STDs only being assigned at PS. However, at least RFC2026 is self consistent. In addition, I would actually affirm some of the general intent that A Technical Specification is any description of a protocol, service, procedure, convention, or format. I think implementable and testable are laudable goals (;-) but the way we test both is through operational experience, which is why we had the standards levels in the first place. IN PRACTICE, many standards are implemented well before they get through the IESG process, and so Internet-Drafts are largely serving the purpose of PS. Although STD1 is rarely updated it should still be so. One reason is that the web is a horrible historical medium for determining what the status of a standard WAS at in a particular time period. Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: As Promised, an attempt at 2026bis
If that's indeed the case, the first order of business needs to be to document current practice. I see no chance of making forward progress on actual changes without first having a consensus as to what our current state is. Brian Carpenter has written draft-carpenter-rfc2026-critique-02.txt which does exactly that, and he has repeatedly solicited comments on it. If you think that it would be helpful to have it published as an informational RFC before undertaking to make normative changes to our standards procedures, please say so. Thanks for the plug, Mike :-) Quite seriously - am I to conclude from the absence of comments on that draft that everyone agrees that it correctly describes current practice? If so, I'll look for an AD to sponsor it. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: As Promised, an attempt at 2026bis
On Tue, Oct 03, 2006 at 01:00:14PM +0200, Brian E Carpenter wrote: If that's indeed the case, the first order of business needs to be to document current practice. I see no chance of making forward progress on actual changes without first having a consensus as to what our current state is. Brian Carpenter has written draft-carpenter-rfc2026-critique-02.txt which does exactly that, and he has repeatedly solicited comments on it. If you think that it would be helpful to have it published as an informational RFC before undertaking to make normative changes to our standards procedures, please say so. Thanks for the plug, Mike :-) Quite seriously - am I to conclude from the absence of comments on that draft that everyone agrees that it correctly describes current practice? If so, I'll look for an AD to sponsor it. silence is NOT consent. Its silence. to be SURE, i'd wait till you had actually expressions of support. but, i'm not you am i? :) --bill Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: As Promised, an attempt at 2026bis
Brian E Carpenter wrote: Quite seriously - am I to conclude from the absence of comments on that draft that everyone agrees that it correctly describes current practice? If so, I'll look for an AD to sponsor it. You asked. Your critique itself has its pluses and minuses. On the plus side you've at least identified some of the issues that have made the document a little long in the tooth, like ASes, RFC Editor text, standard levels, interoperability reports, IPR etc. However, you have missed the forest from the trees. The fundamental description of how we behave as an organization is lost in a section by section critique. It would have been better for you to update RFC 2026 with an appendix explaining the changes and why they are necessary to reflect reality. Oh wait. I've done (or at least begun) that. Here are specific comments about your section by section critique: I think you've misinterpreted section 3.3, which discusses levels of requirements for standards themselves, not individual components of TS documents. But beyond this one has to question the whole notion of requirement levels such as those in that section. Why should they be there at all? The IETF has no force of authority other than moral, and people are not going to write code -- or support it -- for the sake of the IETF's moral authority. Similarly the discussion regarding Independent RFCs. We don't need to critique the words since the IAB RFC Editor are working on an update. Let's go critique THOSE words. You document the broken rather than fix it. See, for instance, your commentary about PS. You yourself call out confusion regarding STDs only being assigned at PS. However, at least RFC2026 is self consistent. In addition, I would actually affirm some of the general intent that A Technical Specification is any description of a protocol, service, procedure, convention, or format. I think implementable and testable are laudable goals (;-) but the way we test both is through operational experience, which is why we had the standards levels in the first place. IN PRACTICE, many standards are implemented well before they get through the IESG process, and so Internet-Drafts are largely serving the purpose of PS. Although STD1 is rarely updated it should still be so. One reason is that the web is a horrible historical medium for determining what the status of a standard WAS at in a particular time period. Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
draft-carpenter-rfc2026-critique-02.txt (was: As Promised, an attempt at 2026bis)
On Tue, 3 Oct 2006, Brian E Carpenter wrote: Quite seriously - am I to conclude from the absence of comments on that draft that everyone agrees that it correctly describes current practice? If so, I'll look for an AD to sponsor it. I've read the document a couple of times, and it appears to me to be reasonably accurate. On Tue, 3 Oct 2006, Eliot Lear wrote: However, you have missed the forest from the trees. The fundamental description of how we behave as an organization is lost in a section by section critique. It would have been better for you to update RFC 2026 with an appendix explaining the changes and why they are necessary to reflect reality. Oh wait. I've done (or at least begun) that. I, too, would prefer to see an update to 2026 that brings it into conformance to current practice. However, Eliot's draft goes well beyond that by proposing substantive changes to current practice, and those proposed changes seem to be quite controversial. In the absence of an update proposal that has community consensus, I think it would be useful to have a description of how 2026 diverges from current practice. So I would encourage Brian to attempt to publish draft-carpenter-rfc2026-critique-02.txt as an information RFC. Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: As Promised, an attempt at 2026bis
--On Tuesday, 03 October, 2006 13:00 +0200 Brian E Carpenter [EMAIL PROTECTED] wrote: Quite seriously - am I to conclude from the absence of comments on that draft that everyone agrees that it correctly describes current practice? If so, I'll look for an AD to sponsor it. Brian, As I suggested at the Montreal plenary, I believe that the majority of the community has reached a state of exhaustion on all but the most critical and pressing process issues (and maybe on those). If that hypothesis is correct, real consensus (positive or negative) about such proposals is likely to be impossible. The folks who still care about process issues and are not burned out will speak up and the folks who are afraid of unintended consequences despite being exhausted will speak up (but perhaps only on Last Call). The vast majority of the community will be silent, not because they are not impacted or don't care (although some will fall into both of those categoris) but, for the rest, because of general exhaustion with one process battle after another. The reactions to both Eliot's and Scott's 2026bis draft (in-depth comments and discussion from the usual process activists, plus comments from others when something they consider outrageous is said) and to your 2026 critique (mostly silence) could be attributed, not to agreement by everyone else, but to that exhaustion factor. Or, perhaps I'm completely wrong about the sense of the community. But I would suggest and ask that, before any more of these documents are pushed or Last Called, you try to determine the degree to which the community just does not want to deal with these issues for a while. regards, john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: As Promised, an attempt at 2026bis
John, Or, perhaps I'm completely wrong about the sense of the community. But I would suggest and ask that, before any more of these documents are pushed or Last Called, you try to determine the degree to which the community just does not want to deal with these issues for a while. As said in my note sent on 2006-08-10, my conclusion after Montreal was essentially the same as yours: 1.1. There is insufficient pressure and energy in the community to justify the effort of reaching consensus on formal changes to the standards process at this time. My intention is to use the current list discussion to confirm or refute this conclusion. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: As Promised, an attempt at 2026bis
--On Tuesday, 03 October, 2006 17:21 +0200 Brian E Carpenter [EMAIL PROTECTED] wrote: John, Or, perhaps I'm completely wrong about the sense of the community. But I would suggest and ask that, before any more of these documents are pushed or Last Called, you try to determine the degree to which the community just does not want to deal with these issues for a while. As said in my note sent on 2006-08-10, my conclusion after Montreal was essentially the same as yours: 1.1. There is insufficient pressure and energy in the community to justify the effort of reaching consensus on formal changes to the standards process at this time. And that was why I was a bit surprised to see you suggesting finding an AD to sponsor, and presumably Last Call, your draft. My intention is to use the current list discussion to confirm or refute this conclusion. Good. If we disagree, it is only on what a formal change constitutes. I would consider an in-depth summary of what is wrong with 2026 (at least on any basis other than a personal informational opinion piece) and any attempt to replace 2026 with a version that reflects current practice to be such formal changes, if only because they would require almost the same level of effort in review and consensus-finding as actually changing the process. But some might disagree. thanks, john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: As Promised, an attempt at 2026bis
On Tuesday, October 03, 2006 11:27:36 AM -0400 John C Klensin [EMAIL PROTECTED] wrote: Good. If we disagree, it is only on what a formal change constitutes. I would consider an in-depth summary of what is wrong with 2026 (at least on any basis other than a personal informational opinion piece) and any attempt to replace 2026 with a version that reflects current practice to be such formal changes, if only because they would require almost the same level of effort in review and consensus-finding as actually changing the process. But some might disagree. As I start to write this, I've read through a little more than half of Brian's draft; I stopped when I found something to comment on. What I'm seeing is descriptive, not prescriptive - it describes ways in which RFC2026 differs from what we actually do, offers interpretation based on current practice, and so on. I think a document like that, taken as a non-normative description rather than a specification, could be useful operationally. People who read RFC2026 without being familiar with current practice are likely to be rather confused, and Brian's draft clears up many of the possible confusions and offers additional commentary that may be useful in understanding what goes on. I assume that a document like this would be published as an informational document, without the benefit of IETF consensus and possibly without even a Last Call (there is _nothing_ that says Informational documents need a last call, and they are frequently published without one). I wouldn't have a problem with that, and in fact, it's probably best that this _not_ be an IETF consensus document if it is to serve a useful purpose. Now, the thing I found to comment on. Brian writes the following about the last paragraph of section 4.2.2: This presumably means outside of the IETF process not outside of the Internet community. As part of this year's RFC Editor RFP process, clarity is being sought about the independent submissions track, which should probably not be discussed at all in the basic definition of the standards process. See [I-D.klensin-rfc-independent] for a more current description. Actually, I think the section means what it says, and is referring _not_ to independent submissions but to cases where a specification developed elsewhere is republished as an RFC to make it more readily available to the Internet community. For example, we do this on a fairly regular basis with the specifications of cryptographic hash functions. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: As Promised, an attempt at 2026bis
John, But a two-step process with new words and threshold conditions isn't current practice; it is a new idea with all of the difficulties in getting consensus that Keith identified and all of the risks of inadvertent change that Sam identified. Trying to do that as a current practice, except we ignore some things that are not and slip a few new ideas in document seems to me to be a recipe for disaster or at least for endless wandering in the weeds. What it requires is that people who want all their pet changes to go into a draft to simply show some discipline and accept that not everything will be fixed at once. Current practice is a ONE STEP process that is NOT documented. Your and others' obstruction brings us to a place where nothing moves forward and we are left in an ossified state. Rough consensus and running code. Well running code requires that we document what works. Rough consensus requires that people come to agreements, likely through compromises. Right now we have neither. Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: As Promised, an attempt at 2026bis
I wrote Your and others' obstruction brings us to a place where nothing moves forward and we are left in an ossified state. This is an overstatement. I don't think John has obstructed the process. Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: As Promised, an attempt at 2026bis
But a two-step process with new words and threshold conditions isn't current practice; it is a new idea with all of the difficulties in getting consensus that Keith identified and all of the risks of inadvertent change that Sam identified. Trying to do that as a current practice, except we ignore some things that are not and slip a few new ideas in document seems to me to be a recipe for disaster or at least for endless wandering in the weeds. What it requires is that people who want all their pet changes to go into a draft to simply show some discipline and accept that not everything will be fixed at once. wtf? no, you can't make incremental changes and expect the result to work better than what we have now. in all probability it will work worse, much worse. the standards process has to balance various factors (e.g quality vs. timeliness). if you change one aspect at a time without changing the others you throw the thing out of balance. John's right - it's a recipe for disaster, and it's completely unacceptable as a means of moving forward. Current practice is a ONE STEP process that is NOT documented. Your and others' obstruction brings us to a place where nothing moves forward and we are left in an ossified state. who gets to decide what is progress and what is obstruction? Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: As Promised, an attempt at 2026bis
Keith, wtf? no, you can't make incremental changes and expect the result to work better than what we have now. in all probability it will work worse, much worse. the standards process has to balance various factors (e.g quality vs. timeliness). if you change one aspect at a time without changing the others you throw the thing out of balance. John's right - it's a recipe for disaster, and it's completely unacceptable as a means of moving forward. And this is fear mongering with a complete lack of specifics. Send text, not fear. Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: As Promised, an attempt at 2026bis
On Fri Sep 29 07:20:34 2006, Eliot Lear wrote: What it requires is that people who want all their pet changes to go into a draft to simply show some discipline and accept that not everything will be fixed at once. Current practice is a ONE STEP process that is NOT documented. I'm not actually sure that our current standardization process *is* one step. In fact, I'm pretty sure that it is very far from one step. I readily agree that it's not documented, though. Consider this: RFC3501 is a Proposed Standard. RFC2244 is, however, merely a Proposed Standard. One is considered mature and stable by the community, and is widely used. The other is very rarely used, and is a considerably less mature specification. Neither, of course, is considered as stable, mature, and provenly interoperable as RFC2821, which, befitting its status, is at Proposed Standard. None of this is documented, and a reader might be led to believe that they are all, in fact, at the same stage in the standardization process. This is a ludicrous idea, of course, and anyone familiar with email with correct them rapidly, knowing the actual status of these specifications. What *is* one step is that there is only one step of our formal standardization process that usually gets used, in no small part because is has effectively been replaced by an entirely different standards track which operates by word of mouth. I firmly believe that we should have documents whose status adequately describes the reality of their status, rather than trying to simplify the existing status until it happens to fit. Otherwise we might as well abandon the document status entirely, since it becomes more and more meaningless. Dave. -- Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED] - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: As Promised, an attempt at 2026bis
wtf? no, you can't make incremental changes and expect the result to work better than what we have now. in all probability it will work worse, much worse. the standards process has to balance various factors (e.g quality vs. timeliness). if you change one aspect at a time without changing the others you throw the thing out of balance. John's right - it's a recipe for disaster, and it's completely unacceptable as a means of moving forward. And this is fear mongering with a complete lack of specifics. Send text, not fear. And again, if we get into arguments about how to change things then we lose the opportunity to document current practice. I am not sure how bad that is in this particular case. If we were talking about a computer-to-computer protocol that was in widespread use, that would be a considerable loss. In this case I suspect (though I could be wrong) that both 2026 and the reality that is practiced are fairly well understood here, so as long as we can describe new proposals in terms of how they would change things from 2026, people in IETF will be able to understand them and evaluate how much better or worse they will work than current practice. It's much more difficult to read an entirely new proposal that states things in different terms, and evaluate how it will work against an organizational culture that is very much steeped in 2026. Note that there's an important difference between describing a new process in relation to 2026 - but describing all of those changes at once - and trying to make one change at a time. I thought you were proposing the latter, but I may have misunderstood. Keith p.s. As an aside, I do not believe that standards - be they process or computer protocol standards - should document current practice. I believe they should document realistic and desirable practice. the standard should be a benchmark that real world implementations strive to meet. Sometimes they will fail. That's not by itself a justification for degrading the standard. Of course if the standard is unrealistic or infeasible, or if it doesn't reflect desirable practice, that's an argument to change the standard. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: As Promised, an attempt at 2026bis
Keith Moore wrote: Note that there's an important difference between describing a new process in relation to 2026 - but describing all of those changes at once - and trying to make one change at a time. I thought you were proposing the latter, but I may have misunderstood. I was not proposing the latter but perhaps I was not clear ;-) Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: As Promised, an attempt at 2026bis
Eliot, Ignoring most of the hyperbole and all of the accusations for the moment... --On Friday, 29 September, 2006 08:20 +0200 Eliot Lear [EMAIL PROTECTED] wrote: ... Current practice is a ONE STEP process that is NOT documented. ... That assertion is part of the problem that prompted my earlier note. It simply is not true. While we don't do periodic reviews and don't time documents out to historic (see my earlier suggestion about documenting that as current practice), and, as Dave Cridland points out, we've got documents at all sort of practical maturity levels in Proposed, we do, periodically, have documents advancing to Draft and even to Full Standard. You may conclude that there aren't enough of those to count and hence that they can be ignored. I am not sure you would get consensus about that conclusion. But you cannot deny that they exist, and exist in fairly recent practice (a quick scan shows RFC 4502 going to Draft and RFC 4506 going to Standard as recently as May). From my point of view --and this is intended to be constructive, not obstructionist-- hyperbole like the above assertion about current practice is one of the things that causes fears about unintended changes.If you had said, e.g., current practice is that we use the second and third levels of the process so little that we need to adjust their descriptions to match, I'd assume that the resulting document would be structured to deal with them fairly, to contain a plan about any needed transitions, etc. But, when you assert that there is really a one-step process now, I worry that whatever document is produced will treat the current maturity levels in a fashion that would have undesirable side-effects and would take multiple rounds of straightening out. The solution to this is not for you to say send text. That is a reasonable comment if one is, e.g., a document editor appointed by a WG whose effort has become an IETF community effort by virtue of chartering, etc. Without that support structure, your pushing this draft in the way you are doing seems to me to be a way to force the rest of the community to do work in order to prevent you from doing damage. That is unattractive, especially in the presence of an hypothesis that the community needs a break from major process work for a while and that, without such a break, the quality of reviews is not likely to meet the standard we need. I don't claim that hypothesis has consensus, but it has received some explicit support and there are several symptoms that could be interpreted as reinforcing it. Those symptoms could be interpreted in other ways as well, including that the IETF is dying before our eyes, but... john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: As Promised, an attempt at 2026bis
Eliot Lear [EMAIL PROTECTED] writes: What it requires is that people who want all their pet changes to go into a draft to simply show some discipline and accept that not everything will be fixed at once. Current practice is a ONE STEP process that is NOT documented. Your and others' obstruction brings us to a place where nothing moves forward and we are left in an ossified state. Rough consensus and running code. Well running code requires that we document what works. Rough consensus requires that people come to agreements, likely through compromises. Right now we have neither. Let me just observe that the above sort of you're with us or against us language is deeply poisoning to making progress on this overall topic. It's divisive, and it is a cheap substitute for real discussion of substance/issues. I can tell you that I personally am very interested/concerned about process improvements. But since I was once part of the big bad self-serving IESG, who are regularly blamed by some for all the failures to make progress here, I have been loath to get involved. I know that it is pretty much inevitable that I will be tarred with the same brush at some point. When I ask myself do I really want to deal with this?, the answer so far has been no, I have plenty of other things I'd rather do. That does not mean I don't care deeply about the topic, however. Thomas ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: As Promised, an attempt at 2026bis
On the issue of whether we have a de facto one-step process, the real question is not whether subsequent steps are ever invoked, but whether the subsequent steps actually have any practical impact on the Internet. One can certainly point to a handful of cases where the subsequent steps are invoked, but the point is that it makes no difference to the Internet whether the subsequent steps are invoked or not. So I think it is quite accurate to say that we have a de facto one-step process. It is thus logical for advocates of the one-step process to argue that we in fact have more or less what we need, and to be skeptical of anything that might result in giving more credence to (or even calling more attention to) the subsequent steps. The real problem with the process is that a protocol can be widely deployed in multiple interoperable implementations for six or seven years before its specification even achieves this one step. This can happen because the WG gets inundated with idiots, and/or because companies are using the IETF as a marketing battleground, and/or because the IESG deliberately tries to obstruct progress, and/or because the security ADs require you to figure out the insanely complicated endsystem-oriented security architecture so you can explain why you don't need to adhere to it. I'm pretty sure there is no IESG-wide consensus on how to address these issues, but if one has suffered through any of these multiple year delays, one is likely to oppose anything that reeks of more process. This can lead one to be suspicious even of writeups that claim to be descriptive, as the writeups may (whether intended to do so or not) serve to extend the life of various problematical processes that might wither away faster if they were never written down. Sometimes it's just better to leave well enough alone. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: As Promised, an attempt at 2026bis
John, Rather than discuss what's hyperbole and what's not, I direct your attention to http://www.ofcourseimright.com/pages/lear/spy.jpg. One could argue that things worked about as one would have expected perhaps through 1996 for draft standard. Beyond that it's clear that things went off the rail. For full, it's hard to argue they were ever really on the rail. Either that or we're truly producing a lot of schlock. I don't believe the latter. I think in general we're doing good work, and decruft hinted at that (although it couldn't conclusively demonstrate it because of the bounds of the experiment). For what it's worth, the methodology used was gluing bibliographical lines together from rfc-index.txt and then grepping $YEAR. and each standard level out, followed by a word count for the result. This might possibly under-report PS documents that have been marked Historic through the decruft experiment. I haven't checked. Code available upon request. My point here is that the three step process is not used as intended. Existing practice clearly demonstrates that the vast majority of our work - far more than intended - never reaches beyond PS. This is reality. Simply documenting that fact in a new RFC2026bis would be to say, Our standards are broken and we know they're broken. That's not what motivated me to write a draft. What motivated me to write a draft was that it's important that we say what we do and we do what we say. The 2nd step for me is a compromise, on the off chance someone really wants to demonstrate a higher level of interoperability, but the economic motivations not to mention the headaches involved with getting there do not lead me to have a lot of faith that it will be used either. But that didn't stop me from including it. Finally, I have no vote on the IESG, nor does my co-author. Our work carries only the moral authority you and others believe it should. The phrase send text is an invitation to the community to make it and our current state of affairs better, and by no means a threat. Rough consensus prevents most dumb ideas from getting through, but not all. I share your concerns that it is possible to make things worse, and I trust you'll be vocal as you have been if you believe that we're moving in the wrong direction. Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: As Promised, an attempt at 2026bis
With respect to documenting current practices, it strikes me that the IETF has sort of a worked example in the Host Requirements RFCs. Maybe something maps from technical to administrative specs? Bob Braden ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: As Promised, an attempt at 2026bis
On Friday, September 29, 2006 11:28:56 PM +0200 Eliot Lear [EMAIL PROTECTED] wrote: My point here is that the three step process is not used as intended. Existing practice clearly demonstrates that the vast majority of our work - far more than intended - never reaches beyond PS. This is reality. Simply documenting that fact in a new RFC2026bis would be to say, Our standards are broken and we know they're broken. That's not what motivated me to write a draft. What motivated me to write a draft was that it's important that we say what we do and we do what we say. Then write that. We have a process which defines three stages and what has to happen to progress to each stage. Where reality diverges from RFC2026 is that 2026 specifies particular timelines for reviewing documents and progressing them along the standards track, while what actually happens is that documents are progressed only when someone cares enough about them to make it happen. As your graph shows, we published documents at all three levels last year. We could eliminate one or both of the extra steps entirely, or become more agressive about actually making them happen, or do any of a wide variety of other things to make them happen. But none of those would be consistent with current practice, which is to progress documents beyond PS if and only if someone cares enough to make it happen. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: As Promised, an attempt at 2026bis
--On Wednesday, 27 September, 2006 23:22 -0400 Sam Hartman [EMAIL PROTECTED] wrote: I support the textual descriptions of the changes Eliot made. However I'm concerned that as with any effort to revise RFC 2026, there will llikely be changes in wording that have unintended consequences. I am not personally convinced that the value of revising RFC 2026 justifies the risk of problems in these changes. I share this concern. See below. I'm quite convinced that if we choose to revise RFC 2026 we should do so with a small set of goal changes--probably no more than Eliot and Scott have proposed. I will resist adding my pet improvements to 2026 to the list. I encourage others who don't want this effort to drown under its own weight to do the same. While I agree with that, I suggest that we are in something of a conundrum. Right now, 2026 is badly out of date in a number of areas. It reflects procedures and modes that we no longer follow, only a fraction of which are addressed by Eliot's draft. There is general community understanding and acceptance that we are operating, not by the letter of 2026, but by the combination of 2026 and a certain amount of, largely undocumented, oral tradition (I expect to hear from the usual suspects on that assertion, but it is the way it is). To make things worse, we have some BCPs that effectively amend 2026 but that are not referenced in Eliot's draft -- I've pointed out some of them to him, which I assume will be fixed, but may have missed others. If we produce a 2026bis that does not address some of those changes in procedure, we risk getting ourselves into a royal mess in which it isn't clear whether the authority for unchanged sections is 2026-as-modified, 2026-plus-oral-tradition, or whether the new document reinstates the long-abandoned procedures. That situation could easily bury us in procedural lawyers (probably the usual amateurs) and dickering... and we have enough of those problems already, at least IMO. I suggest, that if we are going to try to replace 2026 with this sort of incremental change, the new document needs to be organized in one of two ways: (1) Every single section or subsection that is unchanged, and most of those that are not completely rewritten to conform exactly to current practice or deliberately changed to create a new authority contain an explicit disclaimer that indicates that the document does not change, reinstate, or ratify the historical combination of 2026, formal and informal updates, and contemporary practice and that the text is included merely for convenience. That would be ugly. It would also be something we have never done before and it is not clear to me that starting it with 2026bis would be a good idea. But it might do the job. (2) 2026bis, itself, is reduced to nothing more than a list of section headings, each one pointing to the document where the authoritative material for that section can be found, probably with appropriate disclaimers about some portions of 2026. Such a document would not update any section of 2026, deliberately or accidentally, that it did not intend to update and would not drop us into the conundrum. It would make the procedures manual into a lot more documents, but that has advantages as well as disadvantages. It would also have the small advantage that the substantive changes Eliot proposes --such as the move to a two-step standards process-- could be processed, and consensus demonstrated, separately, on their own rather than entangled with each other and with the 2026 revision. I don't see how we can get real consensus any other way, especially in the presence of community burnout with process issues (my perception) and the fears that many of us share about inadvertent changes to sections that don't get careful attention. Just my opinion. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: As Promised, an attempt at 2026bis
While I agree with that, I suggest that we are in something of a conundrum. Right now, 2026 is badly out of date in a number of areas. It reflects procedures and modes that we no longer follow, only a fraction of which are addressed by Eliot's draft. There is general community understanding and acceptance that we are operating, not by the letter of 2026, but by the combination of 2026 and a certain amount of, largely undocumented, oral tradition (I expect to hear from the usual suspects on that assertion, but it is the way it is). To make things worse, we have some BCPs that effectively amend 2026 but that are not referenced in Eliot's draft -- I've pointed out some of them to him, which I assume will be fixed, but may have missed others. If that's indeed the case, the first order of business needs to be to document current practice. I see no chance of making forward progress on actual changes without first having a consensus as to what our current state is. We've been in this position many times before when we've taken up protocol specifications that have lain fallow for some period of time. In several of these cases the exercise of getting agreement on what's actually being used uncovered basic disagreements about the state of play of things in the world that would have made forward progress very difficult. I think it is reasonable to believe that this is even more important when things shift away from the technical and towards the poltical. Ned ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: As Promised, an attempt at 2026bis
While I agree with that, I suggest that we are in something of a conundrum. Right now, 2026 is badly out of date in a number of areas. It reflects procedures and modes that we no longer follow, only a fraction of which are addressed by Eliot's draft. There is general community understanding and acceptance that we are operating, not by the letter of 2026, but by the combination of 2026 and a certain amount of, largely undocumented, oral tradition (I expect to hear from the usual suspects on that assertion, but it is the way it is). To make things worse, we have some BCPs that effectively amend 2026 but that are not referenced in Eliot's draft -- I've pointed out some of them to him, which I assume will be fixed, but may have missed others. If that's indeed the case, the first order of business needs to be to document current practice. I see no chance of making forward progress on actual changes without first having a consensus as to what our current state is. I was just about to reply to John's message saying exactly the same thing. My belief is that any attempt to revise 2026 is likely to introduce a kind of second-system effect - there is so much pent-up demand for changes to our process that everyone has his own idea about how to do it. The only way we have any hope of getting real consensus on a path forward is to first get a shared understanding of where we are now. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: As Promised, an attempt at 2026bis
Hi Keith, If that's indeed the case, the first order of business needs to be to document current practice. I see no chance of making forward progress on actual changes without first having a consensus as to what our current state is. I was just about to reply to John's message saying exactly the same thing. My belief is that any attempt to revise 2026 is likely to introduce a kind of second-system effect - there is so much pent-up demand for changes to our process that everyone has his own idea about how to do it. The only way we have any hope of getting real consensus on a path forward is to first get a shared understanding of where we are now. As I replied to Ned privately, our intent is to go in that direction in general. I believe in Brian Kantor's mantra: document existing practices. Furthermore, an Internet-Draft without rough consensus of the community is just two opinions. To that end, I'm putting aside my own opinion on a bunch of issues in favor of trying to find that consensus. I think we should make additional changes to this document that reflect reality. Several of John's suggestions meet that criteria. I could also imagine VERY incremental changes that are agreed to be non-controversial. My suggestion is that we first start by getting agreement on the changes in the draft that are there, including two-step process Scott I have proposed, which I believe is a compromise between the reality of a one step process and some peoples' desires. I then propose that we address other issues that have been raised individually. If there is consensus for a change we make it. If not, we don't. I want to be that robotic in the hopes that what we end up with will be an improvement over what we have today but with the frank understanding that each of us would have probably wanted something just a bit more (but in differing ways). I also think we should also be VERY mindful of Sam Hartman's concerns about unintended changes. Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: As Promised, an attempt at 2026bis
Propose your own. I'm not stopping you. And I think you're being presumptuous about whether or not I'd like it or that we couldn't come to some agreement. you and I could probably agree substantially within a few days or weeks. what I'm worried about is trying to get pairwise agreement or even rough consensus among several dozen people. and the devil is in the details. also, I'm a bit reluctant to offer my own proposal at this point out of concern that discussion of the relative merits of proposals to do new things would distract from the worthwhile effort of documenting current practice - especially if the discussion got heated. but I will attempt to write down what is in my head and then decide whether it's something I want to make public at this time. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: As Promised, an attempt at 2026bis
I appreciate Eliot announcing his I-D here, and I am hopeful it can lead to a better understanding of what we're facing here. OTOH, I find myself in agreement with John Klensin about the difficulty of the task; and I find myself very much in agreement with Brian Carpenter that the commitment by a broad selection of IETF folks to tackle the issue is lacking. I most strongly urge Eliot to move the discussion of this draft to another mailing-list. IN the absence of Eliot specifying otherwise, I suggest the NEWTRK list: http://darkwing.uoregon.edu/~llynch/newtrk.html -- John Leslie [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: As Promised, an attempt at 2026bis
On Wed, 27 Sep 2006, Eliot Lear wrote: Please find in draft-lear-ietf-rfc2026bis-00.txt a preliminary revision of, well, RFC 2026. It contains the following changes: 1. A new two step process for standardization where the second step is optional. In other words, you get an STD # at the first step. This is a bit of compromise position. The idea is to reflect reality of the existing ONE STEP process but allow that some might wish to indicate that a standard is indeed more mature. 2. A suggested mapping from PS/DS/IS is included. 3. A request is made for appropriate relabelling. 4. There is no mandatory timeline for the IESG to reconsider standards on that first step, but they may do so in a manner of their choosing after the two year mark. I could get behind this proposal. However, for me the key parts are that you get a STD number upon entry to the standards track and that advancement is encouraged but optional. Indeed, I would be just as happy with a proposal that did this but retained PS/DS/IS, since that would be sufficient to bring the process document into alignment with current practice. On Thu, 28 Sep 2006, Ned Freed wrote: [John Klensin wrote:] While I agree with that, I suggest that we are in something of a conundrum. Right now, 2026 is badly out of date in a number of areas. It reflects procedures and modes that we no longer follow, only a fraction of which are addressed by Eliot's draft. There is general community understanding and acceptance that we are operating, not by the letter of 2026, but by the combination of 2026 and a certain amount of, largely undocumented, oral tradition (I expect to hear from the usual suspects on that assertion, but it is the way it is). To make things worse, we have some BCPs that effectively amend 2026 but that are not referenced in Eliot's draft -- I've pointed out some of them to him, which I assume will be fixed, but may have missed others. If that's indeed the case, the first order of business needs to be to document current practice. I see no chance of making forward progress on actual changes without first having a consensus as to what our current state is. Brian Carpenter has written draft-carpenter-rfc2026-critique-02.txt which does exactly that, and he has repeatedly solicited comments on it. If you think that it would be helpful to have it published as an informational RFC before undertaking to make normative changes to our standards procedures, please say so. On Thu, 28 Sep 2006, John C Klensin wrote: The current practice version of the three-step standards process would be, IMO, to leave the three steps there (we clearly have them and use them, even if not often) but either remove the periodic review and timeout provisions or replace them with some words that indicate that regular review and advancement/demotion still reflect community desire but that, in practice, we never do it. Speaking personally, I could live with either of those as a description of current status, even though they seem contradictory, so I see some hope of getting agreement on some very careful wording. As I noted above, I would be OK with an update to 2026 that did just that and nothing else. It would be a big improvement on the current situation. Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: As Promised, an attempt at 2026bis
John == John C Klensin [EMAIL PROTECTED] writes: John --On Wednesday, 27 September, 2006 23:22 -0400 Sam Hartman John [EMAIL PROTECTED] wrote: I support the textual descriptions of the changes Eliot made. However I'm concerned that as with any effort to revise RFC 2026, there will llikely be changes in wording that have unintended consequences. I am not personally convinced that the value of revising RFC 2026 justifies the risk of problems in these changes. John I share this concern. See below. I'm quite convinced that if we choose to revise RFC 2026 we should do so with a small set of goal changes--probably no more than Eliot and Scott have proposed. I will resist adding my pet improvements to 2026 to the list. I encourage others who don't want this effort to drown under its own weight to do the same. John While I agree with that, I suggest that we are in something John of a conundrum. Right now, 2026 is badly out of date in a John number of areas. It reflects procedures and modes that we John no longer follow, only a fraction of which are addressed by John Eliot's draft. There is general community understanding and John acceptance that we are operating, not by the letter of 2026, John but by the combination of 2026 and a certain amount of, John largely undocumented, oral tradition (I expect to hear from John the usual suspects on that assertion, but it is the way it John is). To make things worse, we have some BCPs that John effectively amend 2026 but that are not referenced in John Eliot's draft -- I've pointed out some of them to him, which John I assume will be fixed, but may have missed others. John If we produce a 2026bis that does not address some of those John changes in procedure, we risk getting ourselves into a royal John mess in which it isn't clear whether the authority for John unchanged sections is 2026-as-modified, John 2026-plus-oral-tradition, or whether the new document John reinstates the long-abandoned procedures. That situation John could easily bury us in procedural lawyers (probably the John usual amateurs) and dickering... and we have enough of those John problems already, at least IMO. This is exactly my concern. Trying to revise 2026 and getting it partially wrong could be more expensive than living with oral tradition. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: As Promised, an attempt at 2026bis
John C Klensin wrote: Just my opinion. +1 Deprecating RFC 2026 section by section until nothing is left, or the rest is simple, is a good strategy. Brian's dispute I-D would eliminate another big part of RFC 2026. Paul's updates of RFC 1738 together with RFCs 3986 and 2396 are an example how this might finally work, about six more URI schemes, and RFC 1738 can be buried with all honours. This could be also a strategy for RFC 2821. I'm firmly in the getting it right in less than three steps is inhuman camp, but for say RFC 4234, what's missing ? There are no pending errata I'm aware of, one CrLf objection has merits, but it would be a huge mistake in practice, and the other objection wrt sticky ABNF comments is nice to have, but no fundamental issue. Can I now just send a mail to the IESG asking them to move RFC 4234 to STD, or does this require a dummy I-D to create a tracker token ? Frank ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: As Promised, an attempt at 2026bis
I support the textual descriptions of the changes Eliot made. However I'm concerned that as with any effort to revise RFC 2026, there will llikely be changes in wording that have unintended consequences. I am not personally convinced that the value of revising RFC 2026 justifies the risk of problems in these changes. I'm quite convinced that if we choose to revise RFC 2026 we should do so with a small set of goal changes--probably no more than Eliot and Scott have proposed. I will resist adding my pet improvements to 2026 to the list. I encourage others who don't want this effort to drown under its own weight to do the same. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: As Promised, an attempt at 2026bis
Eliot Lear wrote: we will find another list for this purpose. Please consider to pick an existing list like pesci or newtrk or similar, creating new lists for everything is just bad. 2026 must be revised and not merely updated Your points (4) to (7) sound good, but not (1) to (3). I've not yet read it, is your draft based on a state after Brian's IETF dispute draft extracted the appeals stuff ? Take for example RFCs 82[12] and 28[12]. A 2822bis DS shouldn't be too difficult, unless it's the big one integrating MIME (Bruce proposed this IIRC). Matter of taste, many small steps can be confusing, and one giant step could take years (and fail). http://www.ofcourseimright.com/pages/lear/2026bisdiffs.txt Thanks, that helps. Frank ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
