Re: draft-housley-two-maturity-levels
--On Tuesday, August 02, 2011 20:23 -0400 Joel M. Halpern j...@joelhalpern.com wrote: With mild apologies, I have retained John's text below because, even though I come to a different conclusion, I thought it important to retain for now. If folks choose to follow up on this, significant trimming is recommended. Trimmed :-) John, as far as I can tell there are three problems which various folks have wanted this document or its predecessor to address: 1) That the bar for PS is too high 2) That not enough documents are advancing up the standards track 3) That what we do and what we say we do do not match. I agree with your summary so far. Clearly, these problems are related. That is less clear to me. While I think that (1) is at least part of the cause of (2), both of the following seem almost equally plausible: (i) At the time the current model was assembled, IETF participation was much more heavily weighted toward researchers and others who had the flexibility to be able to concentrate on getting things right with multiple iterations and gradual advancement. As the Internet has evolved toward an environment in which short-term product needs dominate, a larger percentage of IETF participants have needs to get a reasonable spec agreed on so it can be implemented and deployed, but little need to refine and revise unless flaws in the specs cause serious and user- or operator- visible interoperability problems. (ii) At the time the current model was assembled, IETF specifications tended to be for relatively simple protocols with either few options or orthogonal ones without complex interactions. Today, we are seeing far more specs with optional variations, options that interact in complex ways, profiles for different purposes, etc. We have whole working groups whose purpose it is to sort out the operational implications of protocols developed in other WGs (and sometimes still under development. In that environment, having maturity categories that require an entire complex protocol, regardless of profiles or sets of options, to be classified into a small range of mutually-exclusive sets just makes no sense almost independent of how many categories we have. Whether we can remove obstacles or not, we don't have the right incentives in place to get people to do things that make no sense to them (or to their sponsors). Indeed, _increasing_ the number of categories might help: for example, perhaps we need a base spec and 'mandatory to implement' pieces are fine, but we don't know about some of the option sets category. If some combination of those hypotheses is actually the driving force behind few specs getting past Proposed, then nothing we do about getting things into Proposed more easily will make any difference. Nor is fussing with the number of maturity levels likely to have any useful effect. In addition, (3) appears to me almost completely unconnected with the other two. Sure, we don't use annual review and never have. And it is definitely unattractive to have rules around that we don't follow. I would be a lot happier if we removed or clarified _every_ rule in our specs that we don't follow (or if we followed more of them). But I haven't heard even a claim that removing a rule that we haven't followed from 2026 would make it easier to get documents approved as Proposed or that it would increase, even slightly, the number of documents that are advanced. We could try to adopt a change that would address all three. I dobut we would accomplish anything. ok As far as I can tell, this document sensible tries to address one of these, namely item 3. It tries to align what we document with what we do. In order to do so, it also makes a change which may help item 2. It may not. But there is no connection at all. If we wanted to address item 3, then all it would take is a _really_ short RFC that updated 2026 and said that provision has never been used and is now eliminated. As I indicated in my long note, I can't believe there would be any controversy about such a document other than complaints that we were wasting time that could be better spent in other ways. Might it help with item 2? While I can't _prove_ it would not, I don't recall seeing a single argument, either in the document drafts or on the list, that justifies even a strong hypothesis that the existence of a rule that we have never followed has discouraged even a single specification. If one thought there was an interaction of that sort, it would make far more sense logically to try applying the rule to see what effect that would actually have. I'm not suggesting that, if only because I wonder whether moving RFC 3261, RFC
Re: draft-housley-two-maturity-levels
On 7/30/11 11:05 AM, Joel M. Halpern wrote: It seems to me that this does two things, both small but useful. 1) It makes a minor change in the advancement procedures so that they are more reasonable. They may still not be sufficiently reasonable to be used, but it improves them, and thereby improves the odds. Actually, there is no evidence that this is an improvement. I'd agree that it is a minor change, but there has been no serious analysis of whether it is an improvement or not. To the extent to which approving this lowers the odds of considering and making changes that might actually have significant effects (e.g., really sorting out what maturity levels mean in a world of increasingly complex standards), it is harmful. See long discussion below. 2) It is coupled to an intent to actually behave according to what the document says. Such an intent is obviously not feasible without some change. Well, yes and no. My sense of the discussion over the last year is that a significant fraction of the community believes that the critical path change in this area is an adjustment to the threshold for Proposed Standard. That issue is addressed in draft-bradner-restore-proposed, which requires no change to RFC 2026 or other formal procedures at all. It is not addressed in this document. It is useful to have our behavior and our documented description of how we work match because the mismatch causes confusion, at least for new participants, and sometimes even for experienced participants. I agree with this. But this document doesn't make nearly enough of a contribution in that area to justify approving it. It addresses exactly one provision of our processes in which documentation and practice don't align, a provision about which there is no subtlety or confusion within the community at all (even though new participants may be confused). If the issue is important, then let's make a serious effort to update the places where 2026, 2028, 2031, 2360, 3710, 4071, and probably several other documents have fallen at least somewhat out of line with reality. If the particular issue of the annual review is really more important than any of those other issues, I assume that a stand-along document that changed it would rapidly achieve community consensus (albeit with some complaints about wasted time). Certainly it should not be sufficient to justify approving this document... the change is almost irrelevant to it. It might be the case that it will improve the advancement percentage. It might not. I can not imagine that it will make that even worse. I can because the effects of changes like this are actually very hard to predict. It increases the requirements for the second level, however slightly. Since we have trouble getting things to the second level now, that increased requirement might reduce incentives to bring things off Proposed at a least as much as a theoretical just one more level and then you are finished change would increase those incentives. By changing Proposed from 1/3 of the way to 1/2 way or a bit more, it might remove a small incentive to take the additional step. In addition, the publication without a new RFC provision may actually further increase the de facto requirements for Proposed Standards by requiring that those documents be edited to a high standard of clear English and specification precision. While, IMO, we have taken too little advantage of it, the current provisions of RFC 2026 permit publishing a Proposed Standard as soon as the WG understands it, leaving language cleanup (and refined translation from the writing styles of many people in the community whether native speakers of English or not) for Draft Standard versions. More important, for those of us who believe that a maturity system based on rigid named categories that apply to entire documents has outlived its usefulness as our specifications have become more complex, approval of this document is almost certain to cause consideration of such approaches to be postponed by some years as people complain that the changes made in this draft must have time to take effect and be evaluated. --- A more extended analysis of other aspects of the situation with this document follows. Those who don't like extended analyses might want to stop reading at some point. A very long time ago, a then-professor of mine observed that one of the most common sources of failures in engineering, especially computer engineering, was to look at a problem that seemed too large or too intractable, find some easily-changed and tractable part of the problem, do something with it (almost anything), and then claim that significant progress had been made on the original/ real problem because one had started on it. In many cases, the approach actually makes the real problem harder: systems become more complex, applying remedies later turns out to be more complicated, and so on. The narrow solution may also use up
Re: draft-housley-two-maturity-levels
With mild apologies, I have retained John's text below because, even though I come to a different conclusion, I thought it important to retain for now. If folks choose to follow up on this, significant trimming is recommended. John, as far as I can tell there are three problems which various folks have wanted this document or its predecessor to address: 1) That the bar for PS is too high 2) That not enough documents are advancing up the standards track 3) That what we do and what we say we do do not match. Clearly, these problems are related. We could try to adopt a change that would address all three. I dobut we would accomplish anything. As far as I can tell, this document sensible tries to address one of these, namely item 3. It tries to align what we document with what we do. In order to do so, it also makes a change which may help item 2. It may not. Now, you can argue that it is taking up energy that should go to item 1. That is not unreasonable. Except that I consider all the proposals I have seen for item 1 to be failures. They fail in different ways, but they all have appeared to me to be bad ideas. (I think, based on conversations, some folks were supporting the previous version of this document in the mistaken believe that it did more to address that than it actually provided.) As such, we can either do nothing, or take this step that in my personal opinion addresses item 3, might turn out to help item 2, and does not hurt item 1. I believe I understand your point below that without understanding how we ought to address problem 1, it is hard to be confident we are not making it worse rather than better. Yours, Joel On 8/2/2011 6:51 PM, John C Klensin wrote: On 7/30/11 11:05 AM, Joel M. Halpern wrote: It seems to me that this does two things, both small but useful. 1) It makes a minor change in the advancement procedures so that they are more reasonable. They may still not be sufficiently reasonable to be used, but it improves them, and thereby improves the odds. Actually, there is no evidence that this is an improvement. I'd agree that it is a minor change, but there has been no serious analysis of whether it is an improvement or not. To the extent to which approving this lowers the odds of considering and making changes that might actually have significant effects (e.g., really sorting out what maturity levels mean in a world of increasingly complex standards), it is harmful. See long discussion below. 2) It is coupled to an intent to actually behave according to what the document says. Such an intent is obviously not feasible without some change. Well, yes and no. My sense of the discussion over the last year is that a significant fraction of the community believes that the critical path change in this area is an adjustment to the threshold for Proposed Standard. That issue is addressed in draft-bradner-restore-proposed, which requires no change to RFC 2026 or other formal procedures at all. It is not addressed in this document. It is useful to have our behavior and our documented description of how we work match because the mismatch causes confusion, at least for new participants, and sometimes even for experienced participants. I agree with this. But this document doesn't make nearly enough of a contribution in that area to justify approving it. It addresses exactly one provision of our processes in which documentation and practice don't align, a provision about which there is no subtlety or confusion within the community at all (even though new participants may be confused). If the issue is important, then let's make a serious effort to update the places where 2026, 2028, 2031, 2360, 3710, 4071, and probably several other documents have fallen at least somewhat out of line with reality. If the particular issue of the annual review is really more important than any of those other issues, I assume that a stand-along document that changed it would rapidly achieve community consensus (albeit with some complaints about wasted time). Certainly it should not be sufficient to justify approving this document... the change is almost irrelevant to it. It might be the case that it will improve the advancement percentage. It might not. I can not imagine that it will make that even worse. I can because the effects of changes like this are actually very hard to predict. It increases the requirements for the second level, however slightly. Since we have trouble getting things to the second level now, that increased requirement might reduce incentives to bring things off Proposed at a least as much as a theoretical just one more level and then you are finished change would increase those incentives. By changing Proposed from 1/3 of the way to 1/2 way or a bit more, it might remove a small incentive to take the additional step. In addition, the publication without a new RFC provision may actually further increase the de facto
Re: draft-housley-two-maturity-levels
On 7/30/11 11:05 AM, Joel M. Halpern wrote: It seems to me that this does two things, both small but useful. 1) It makes a minor change in the advancement procedures so that they are more reasonable. They may still not be sufficiently reasonable to be used, but it improves them, and thereby improves the odds. 2) It is coupled to an intent to actually behave according to what the document says. Such an intent is obviously not feasible without some change. It is useful to have our behavior and our documented description of how we work match because the mismatch causes confusion, at least for new participants, and sometimes even for experienced participants. It might be the case that it will improve the advancement percentage. It might not. I can not imagine that it will make that even worse. I'm with Joel here. Let's clean up our documentation so that it more closely matches our current practice. We might even encourage more folks to progress their work along the standards track, although I think that failing is more cultural than procedural. So, it seems to me that this matches the description that Eric, Brian, and others have used of a baby step that is not harmful and may be helpful. The baby step description is a metaphor. If we can't make even this small change, how can we expect to complete more significant reforms? BTW, the latest version more clearly describes the problem it is trying to solve, so I think that my DISCUSS has been addressed. I'm clearing the DISCUSS and now approve of publishing this I-D as an RFC. Peter -- Peter Saint-Andre https://stpeter.im/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
On 31st July 2011, Brian Carpenter wrote, in part: I believe that the present situation is confusing both to IETF newcomers (who may falsely believe that the IETF actually follows the 3 stage process) and, worse, confusing to users of IETF standards (who may falsely believe that a document isn't useful until it's advanced). We, and those users, gain by reducing the confusion. (Note: I did not write eliminating the confusion.) I agree totally with Brian's assessment. It defines a practice which is *very* close to present practice, apart from a minor name change. I think that's the best we can do, but that's why it's a baby step, not a no-op. Also agreed. It might cause a change, simply because the effort of making the single move PS-IS will get you to the end state, whereas previously you had to make two efforts, PS-DS-STD. But only time will tell if this changes our collective behaviour. Making this process change definitely will change my attitude towards trying to advance standards-track RFCs that I am directly involved with. Until now, the process overhead to move from PS to STD was far too great to justify the time spent. My perception is that this change reduces the process work substantially -- and a change in perception (i.e. perception by itself) is sufficient to increase my own motivation to make the attempt. While perception normally varies widely between individuals, on virtually all topics, I am not alone in in the view I've expressed just above. Yours, Ran ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
On Jul 31, 2011, at 11:55 AM, RJ Atkinson wrote: On 31st July 2011, Brian Carpenter wrote, in part: [snip] It might cause a change, simply because the effort of making the single move PS-IS will get you to the end state, whereas previously you had to make two efforts, PS-DS-STD. But only time will tell if this changes our collective behaviour. Making this process change definitely will change my attitude towards trying to advance standards-track RFCs that I am directly involved with. Until now, the process overhead to move from PS to STD was far too great to justify the time spent. My perception is that this change reduces the process work substantially -- and a change in perception (i.e. perception by itself) is sufficient to increase my own motivation to make the attempt. While perception normally varies widely between individuals, on virtually all topics, I am not alone in in the view I've expressed just above. Yours, Ran This is the intent. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
it looks so - maybe it would be good to have a pointer in this doc Scott On Jul 28, 2011, at 9:19 AM, Robert Sparks wrote: Scott - Didn't RFC 5657 address your point 2? The current proposal no longer requires this report during advancement, but it does not disallow it. I hope it's obvious that I believe these reports are valuable, but I am willing to accept the proposed structure, with the hope and expectation that communities that are serious about producing and refining protocols will be producing these reports anyhow. RjS On Jul 28, 2011, at 8:19 AM, Scott O. Bradner wrote: this is better than the last version but 1/ I still see no reason to think that this change will cause any significant change in the percent of Proposed Standards that move up the (shorter) standards track since the proposal does nothing to change the underlying reasons that people do not expend the effort needed to advance documents 2/ one of the big issues with the PS-DS step is understanding what documentation is needed to show that there are the interoperable implementations and to list the unused features - it would help a lot to provide some guidance (which I did not do in 2026 - as I have been reminded a number of times :-) ) as to just what process is to be followed could be a spread sheet showing features implementations an assertion by the person proposing the advancement that the requirements have been met or something in between Scott ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf Scott Bradner Harvard University Information Technology Security | Policy, Risk Compliance +1 617 495 3864 29 Oxford St., Room 407 Cambridge, MA 02138 www.harvard.edu/huit ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
On 7/28/11 9:03 AM, Eric Burger wrote: On Jul 28, 2011, at 8:19 AM, Scott O. Bradner wrote: 1/ I still see no reason to think that this change will cause any significant change in the percent of Proposed Standards that move up the (shorter) standards track since the proposal does nothing to change the underlying reasons that people do not expend the effort needed to advance documents And the real question is, are we moving forward? I think that we are not moving as far as we originally wanted. However, I offer we are moving a baby step forward, and as such is worthwhile doing. On 7/28/11 6:07 PM, Brian E Carpenter wrote: Let's just make this baby step and stop worrying about it. Not to pick on Eric and Brian alone; I put this to everyone. I *really* want an answer to the issue that Scott raises. Eric and Brian each refer to a baby step. A baby step toward what exactly? If the answer is simply, to align documentation with current procedure, that's fine, but then I want to know: a) Why is it useful and positive to line up documentation with current procedure? That is, what are we gaining by publishing this? and b) This document is identical to neither 2026 *nor* current procedure, so how is it accomplishing the goal of aligning with current procedure anyway? If the answer is, Yes, this document will cause a change in the percent of Proposed Standards that move up, then I want to know How?, because like Scott, I haven't heard the answer stated in this dicussion. If you think I've missed an obvious alternative reason to go ahead with this document, I'm open to hear it, but it sounds like the only two alternatives expressed so far are, Document current practice and Improve number of documents moving along standards track, and I haven't heard how this document does either of those things. I consider this an open, unaddressed, issue. pr -- Pete Resnickhttp://www.qualcomm.com/~presnick/ Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
It seems to me that this does two things, both small but useful. 1) It makes a minor change in the advancement procedures so that they are more reasonable. They may still not be sufficiently reasonable to be used, but it improves them, and thereby improves the odds. 2) It is coupled to an intent to actually behave according to what the document says. Such an intent is obviously not feasible without some change. It is useful to have our behavior and our documented description of how we work match because the mismatch causes confusion, at least for new participants, and sometimes even for experienced participants. It might be the case that it will improve the advancement percentage. It might not. I can not imagine that it will make that even worse. So, it seems to me that this matches the description that Eric, Brian, and others have used of a baby step that is not harmful and may be helpful. Yours, Joel On 7/30/2011 12:55 PM, Pete Resnick wrote: On 7/28/11 9:03 AM, Eric Burger wrote: On Jul 28, 2011, at 8:19 AM, Scott O. Bradner wrote: 1/ I still see no reason to think that this change will cause any significant change in the percent of Proposed Standards that move up the (shorter) standards track since the proposal does nothing to change the underlying reasons that people do not expend the effort needed to advance documents And the real question is, are we moving forward? I think that we are not moving as far as we originally wanted. However, I offer we are moving a baby step forward, and as such is worthwhile doing. On 7/28/11 6:07 PM, Brian E Carpenter wrote: Let's just make this baby step and stop worrying about it. Not to pick on Eric and Brian alone; I put this to everyone. I *really* want an answer to the issue that Scott raises. Eric and Brian each refer to a baby step. A baby step toward what exactly? If the answer is simply, to align documentation with current procedure, that's fine, but then I want to know: a) Why is it useful and positive to line up documentation with current procedure? That is, what are we gaining by publishing this? and b) This document is identical to neither 2026 *nor* current procedure, so how is it accomplishing the goal of aligning with current procedure anyway? If the answer is, Yes, this document will cause a change in the percent of Proposed Standards that move up, then I want to know How?, because like Scott, I haven't heard the answer stated in this dicussion. If you think I've missed an obvious alternative reason to go ahead with this document, I'm open to hear it, but it sounds like the only two alternatives expressed so far are, Document current practice and Improve number of documents moving along standards track, and I haven't heard how this document does either of those things. I consider this an open, unaddressed, issue. pr ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
Pete Resnick presn...@qualcomm.com wrote: I *really* want an answer to the issue that Scott raises. Eric and Brian each refer to a baby step. A baby step toward what exactly? If the answer is simply, to align documentation with current procedure, that's fine, but then I want to know: a) Why is it useful and positive to line up documentation with current procedure? That is, what are we gaining by publishing this? and b) This document is identical to neither 2026 *nor* current procedure, so how is it accomplishing the goal of aligning with current procedure anyway? Although, to tell truth, I don't care very much whether this I-D becomes an RFC, I am _very_ glad that Pete is raising these questions. We have been wandering in the weeds for years now over how many steps should there be? IMHO, the last serious WG effort (newtrk) reached something very like consensus that that was the wrong question. I _seriously_ hope the IESG will either decide to enact this I-D or stop beating this horse. I suggest that we accept the principle that consensus process means it will be hard to change something in the future; and admit that adjust to current practice isn't a sufficient shibboleth to gain consensus for a change from a previous consensus. It _is_ appropriate for anyone sufficiently bothered by failure to follow current documented rules to appeal actions which don't follow the rules. That _will_ make you unpopular with the folks that must process the appeal, but it is less harmful than asking the entire IETF to wander in the weeds in seek of consensus to change the rules. If I may make a suggestion, actual practice could be documented on ietf.org web pages (with some explanation of how it differs from the RFC rules and why) -- without all this wandering in the weeds. It is _really_ unlikely that would invoke the full appeal process more than once, and it would save a lot of bandwidth on this list. BTW, while I do intend to be silent if the IESG adopts this I-D for publication, that does _not_ mean I will be silent when the next adjust to current practice I-D comes up. -- John Leslie j...@jlc.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
Hi Pete, On 2011-07-31 04:55, Pete Resnick wrote: ... I *really* want an answer to the issue that Scott raises. Eric and Brian each refer to a baby step. A baby step toward what exactly? If the answer is simply, to align documentation with current procedure, that's fine, but then I want to know: a) Why is it useful and positive to line up documentation with current procedure? That is, what are we gaining by publishing this? I believe that the present situation is confusing both to IETF newcomers (who may falsely believe that the IETF actually follows the 3 stage process) and, worse, confusing to users of IETF standards (who may falsely believe that a document isn't useful until it's advanced). We, and those users, gain by reducing the confusion. (Note: I did not write eliminating the confusion.) and b) This document is identical to neither 2026 *nor* current procedure, so how is it accomplishing the goal of aligning with current procedure anyway? It defines a practice which is *very* close to present practice, apart from a minor name change. I think that's the best we can do, but that's why it's a baby step, not a no-op. If the answer is, Yes, this document will cause a change in the percent of Proposed Standards that move up, then I want to know How?, because like Scott, I haven't heard the answer stated in this dicussion. It might cause a change, simply because the effort of making the single move PS-IS will get you to the end state, whereas previously you had to make two efforts, PS-DS-STD. But only time will tell if this changes our collective behaviour. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
I have read version 08 and support this proposal. - Chris --On July 27, 2011 17:46:22 -0400 Jari Arkko jari.ar...@piuha.net wrote: Here's the link: http://tools.ietf.org/html/draft-housley-two-maturity-levels ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
this is better than the last version but 1/ I still see no reason to think that this change will cause any significant change in the percent of Proposed Standards that move up the (shorter) standards track since the proposal does nothing to change the underlying reasons that people do not expend the effort needed to advance documents 2/ one of the big issues with the PS-DS step is understanding what documentation is needed to show that there are the interoperable implementations and to list the unused features - it would help a lot to provide some guidance (which I did not do in 2026 - as I have been reminded a number of times :-) ) as to just what process is to be followed could be a spread sheet showing features implementations an assertion by the person proposing the advancement that the requirements have been met or something in between Scott ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
Scott - Didn't RFC 5657 address your point 2? The current proposal no longer requires this report during advancement, but it does not disallow it. I hope it's obvious that I believe these reports are valuable, but I am willing to accept the proposed structure, with the hope and expectation that communities that are serious about producing and refining protocols will be producing these reports anyhow. RjS On Jul 28, 2011, at 8:19 AM, Scott O. Bradner wrote: this is better than the last version but 1/ I still see no reason to think that this change will cause any significant change in the percent of Proposed Standards that move up the (shorter) standards track since the proposal does nothing to change the underlying reasons that people do not expend the effort needed to advance documents 2/ one of the big issues with the PS-DS step is understanding what documentation is needed to show that there are the interoperable implementations and to list the unused features - it would help a lot to provide some guidance (which I did not do in 2026 - as I have been reminded a number of times :-) ) as to just what process is to be followed could be a spread sheet showing features implementations an assertion by the person proposing the advancement that the requirements have been met or something in between Scott ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
And the real question is, are we moving forward? I think that we are not moving as far as we originally wanted. However, I offer we are moving a baby step forward, and as such is worthwhile doing. On Jul 28, 2011, at 9:19 AM, Robert Sparks wrote: Scott - Didn't RFC 5657 address your point 2? The current proposal no longer requires this report during advancement, but it does not disallow it. I hope it's obvious that I believe these reports are valuable, but I am willing to accept the proposed structure, with the hope and expectation that communities that are serious about producing and refining protocols will be producing these reports anyhow. RjS On Jul 28, 2011, at 8:19 AM, Scott O. Bradner wrote: this is better than the last version but 1/ I still see no reason to think that this change will cause any significant change in the percent of Proposed Standards that move up the (shorter) standards track since the proposal does nothing to change the underlying reasons that people do not expend the effort needed to advance documents 2/ one of the big issues with the PS-DS step is understanding what documentation is needed to show that there are the interoperable implementations and to list the unused features - it would help a lot to provide some guidance (which I did not do in 2026 - as I have been reminded a number of times :-) ) as to just what process is to be followed could be a spread sheet showing features implementations an assertion by the person proposing the advancement that the requirements have been met or something in between Scott ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
On 7/28/11 10:03 AM, Eric Burger wrote: And the real question is, are we moving forward? I think that we are not moving as far as we originally wanted. However, I offer we are moving a baby step forward, and as such is worthwhile doing. We are more closely aligning our documentation with our organizational running code. All other things being equal, that's a good thing. That doesn't imply that all of our organizatioal running code is bug-free. We could have a broader conversation about the latter, but IMHO that's outside the scope of this baby step forward. Peter -- Peter Saint-Andre https://stpeter.im/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
On Jul 28, 2011, at 10:06 AM, Peter Saint-Andre wrote: On 7/28/11 10:03 AM, Eric Burger wrote: And the real question is, are we moving forward? I think that we are not moving as far as we originally wanted. However, I offer we are moving a baby step forward, and as such is worthwhile doing. We are more closely aligning our documentation with our organizational running code. All other things being equal, that's a good thing. Hmm. I've long believed that : - trying to document existing practice - trying to document desirable practice are both worthwhile endeavors, as long as you don't try to do both at the same time. When you try to do both at the same time, there is a conflict. If someone wants to write a document that says we generally follow RFC 2026, except that: - drafts hardly ever advance to Draft Standard and even more rarely to Full Standard, unless there is significant use of the protocol and there are bugs that need to be fixed (in which case the ability to advance can sometimes serve as an incentive of sorts) - we have never been serious about periodic review of standards and we don't have enough time/energy to do that - we've never really nailed down what Historic meant, and when it was appropriate to use it etc. that would be a fine thing. And real changes to the process, say to bring in formal cross review earlier, to clarify the nature of community consensus and the need for it, etc. might also be a fine thing. Unfortunately, such discussions are always contentious and difficult, because they affect the whole community, but they also attract a lot of interests from individuals with particularly unique axes to grind. So we keep trying to fix the substantive problems with incremental changes. I forget who it was who said yesterday that we can't really do that, but I certainly agree with him. Meanwhile, it's not clear to me that simply changing from one document that we don't strictly follow, to another document that we won't follow much better, is helpful. And I don't think IETF's problems with standards quality or process can be addressed merely by changes to the number of maturity levels. That strikes me as a bit like rearranging deck chairs...it might make people feel better but is of little consequence. In other words, I'm not convinced that this change will do much harm, but I'm also not convinced that it will help much. And yet we keep flogging this idea... Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
On 7/28/11 10:20 AM, Keith Moore wrote: In other words, I'm not convinced that this change will do much harm, but I'm also not convinced that it will help much. I don't disagree. And yet we keep flogging this idea... But we always flog the easy issues, rather than facing the tough ones. It would be good to start talking about the tough issues, but IMHO there is some value in settling on two maturity levels as well. Peter -- Peter Saint-Andre https://stpeter.im/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
Keith, On 2011-07-29 02:20, Keith Moore wrote: On Jul 28, 2011, at 10:06 AM, Peter Saint-Andre wrote: On 7/28/11 10:03 AM, Eric Burger wrote: And the real question is, are we moving forward? I think that we are not moving as far as we originally wanted. However, I offer we are moving a baby step forward, and as such is worthwhile doing. We are more closely aligning our documentation with our organizational running code. All other things being equal, that's a good thing. Hmm. I've long believed that : - trying to document existing practice - trying to document desirable practice are both worthwhile endeavors, as long as you don't try to do both at the same time. When you try to do both at the same time, there is a conflict. If someone wants to write a document that says we generally follow RFC 2026, except that: Been there, done that, it sank like a stone. Let's just make this baby step and stop worrying about it. Brian - drafts hardly ever advance to Draft Standard and even more rarely to Full Standard, unless there is significant use of the protocol and there are bugs that need to be fixed (in which case the ability to advance can sometimes serve as an incentive of sorts) - we have never been serious about periodic review of standards and we don't have enough time/energy to do that - we've never really nailed down what Historic meant, and when it was appropriate to use it etc. that would be a fine thing. And real changes to the process, say to bring in formal cross review earlier, to clarify the nature of community consensus and the need for it, etc. might also be a fine thing. Unfortunately, such discussions are always contentious and difficult, because they affect the whole community, but they also attract a lot of interests from individuals with particularly unique axes to grind. So we keep trying to fix the substantive problems with incremental changes. I forget who it was who said yesterday that we can't really do that, but I certainly agree with him. Meanwhile, it's not clear to me that simply changing from one document that we don't strictly follow, to another document that we won't follow much better, is helpful. And I don't think IETF's problems with standards quality or process can be addressed merely by changes to the number of maturity levels. That strikes me as a bit like rearranging deck chairs...it might make people feel better but is of little consequence. In other words, I'm not convinced that this change will do much harm, but I'm also not convinced that it will help much. And yet we keep flogging this idea... Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
On 2011-07-28 09:46, Jari Arkko wrote: After extensive discussion on this list and in the IESG Russ has decided to make a reduced proposal. I am now initiating a new Last Call to gauge consensus on the new version. Thankyou. I fully support this version. Brian Carpenter ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels-06
On Thu May 5 18:31:33 2011, Dave CROCKER wrote: On 5/5/2011 10:22 AM, Dave Cridland wrote: On balance, whilst I appreciate the aims of this document, I think the proposals are not suitable for adoption. 1) This document radically lowers the quality of Proposed Standards. What, specifically, are the parts of the proposal that you believe will lower the quality of a Proposed Standard? The parts unmentioned in the document, in effect. It states: 2.1. The First Maturity Level: Proposed Standard The stated requirements for Proposed Standard are not changed; they remain exactly as specified in RFC 2026 [1]. Various influences have made publishing a Proposed Standard much harder than the stated requirements in RFC 2026. The intention of the two-tier maturity ladder is to restore practice to the requirements for Proposed Standard from RFC 2026, and stop performing more scrutiny than intended in IETF working groups and the IESG. No new requirements are introduced; no existing published requirements are relaxed. RFC 2026 essentially defines a PS document as being a first cut, likely to change, and as such unsuitable for production deployment. In particular: Implementors should treat Proposed Standards as immature specifications. It is desirable to implement them in order to gain experience and to validate, test, and clarify the specification. However, since the content of Proposed Standards may be changed if problems are found or better solutions are identified, deploying implementations of such standards into a disruption-sensitive environment is not recommended. So this clearly states that should we revert to RFC 2026, then we should immediately consider that HTTP, IMAP, and XMPP, for instance, should not be deployed in disruption-sensitive environments. Are you really sure that's what you think our consensus opionion is? It certainly isn't mine. I don't think this reflects the current status quo in the slightest. I think our current PS maturity is essentially considered production quality, although we anticipate that clarifications in the specification may be required, and consultation with other implementors is likely to be beneficial. In particular, for better or worse, the wider internet technical community - ie, the people who are aware of, but not involved in, the IETF - expect our PS documents to have high quality, and would be caught unawares by a sudden shift back to this stance. So to make this clear, I think that as the requirements and scrutiny of PS documents have increased, the quality has as a result, and - undoubtedly more important - the expected quality has also. I am suprised that you don't see this as quite apparent. We have, in general, raised the bar over the years for PS documents, and - whether or not you think this was a good idea - this horse has left the station, and it's too late to put the lid back on - the wider world now expects this. Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - 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://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels-06
On 5/6/2011 1:31 AM, Dave Cridland wrote: On Thu May 5 18:31:33 2011, Dave CROCKER wrote: 1) This document radically lowers the quality of Proposed Standards. What, specifically, are the parts of the proposal that you believe will lower the quality of a Proposed Standard? The parts unmentioned in the document, in effect. It states: ... The stated requirements for Proposed Standard are not changed; they remain exactly as specified in RFC 2026 [1]. ... RFC 2026 essentially defines a PS document as being a first cut, likely to change, and as such unsuitable for production deployment. In particular: You appear to be saying that the new document lowers quality by continuing to use the same basic criteria and qualifiers for Proposed that we've used for many years. Forgive me, but I do not understand how that logic works. How can the new process document lower quality by holding the established criteria for Proposed stable? It appears that your actual concern is not about the new document, but rather the existing process specification (RFC 2026). d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels-06
On Fri, May 06, 2011 at 08:08:54AM -0700, Dave CROCKER wrote: The parts unmentioned in the document, in effect. ^^^ You appear to be saying that the new document lowers quality by continuing to use the same basic criteria and qualifiers for Proposed that we've used for many years. I think he is saying that there is are _de facto_ criteria that are neither called out in 2026 nor in this draft, and that those criteria are the running code, so the documentation ought to be made to match. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels-06
Dave: the issue is that PS was previously not seen as a finished product, now it has much more exalted status, but the criteria have not changed. On May 6, 2011 11:09 AM, Dave CROCKER d...@dcrocker.net wrote: On 5/6/2011 1:31 AM, Dave Cridland wrote: On Thu May 5 18:31:33 2011, Dave CROCKER wrote: 1) This document radically lowers the quality of Proposed Standards. What, specifically, are the parts of the proposal that you believe will lower the quality of a Proposed Standard? The parts unmentioned in the document, in effect. It states: ... The stated requirements for Proposed Standard are not changed; they remain exactly as specified in RFC 2026 [1]. ... RFC 2026 essentially defines a PS document as being a first cut, likely to change, and as such unsuitable for production deployment. In particular: You appear to be saying that the new document lowers quality by continuing to use the same basic criteria and qualifiers for Proposed that we've used for many years. Forgive me, but I do not understand how that logic works. How can the new process document lower quality by holding the established criteria for Proposed stable? It appears that your actual concern is not about the new document, but rather the existing process specification (RFC 2026). d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels-06
I am strongly opposed to this 2 document maturity level proposal. The real problem tha the IETF is regularly facing are constituencies that will fight hard against specifications getting updated, improved or fixed, once they have been published as RFC. Dave Cridland wrote: Dave CROCKER wrote: Dave Cridland wrote: 1) This document radically lowers the quality of Proposed Standards. What, specifically, are the parts of the proposal that you believe will lower the quality of a Proposed Standard? 2.1. The First Maturity Level: Proposed Standard The intention of the two-tier maturity ladder is to restore practice to the requirements for Proposed Standard from RFC 2026, and stop performing more scrutiny than intended in IETF working groups and the IESG. The proposal literally says stop performing more scurtiny than intended. The lower quality of the documents at Proposed is an explicit goal of this proposal. When this proposal is adopted, good quality for documents at Proposed is only going to happen by accident, but no longer by peer review and scrutiny. I believe that this proposal is based on a premise that is inverse to reality. The real causality is: - very few Working Groups go through the effort on fixing or improving documents once they're published as RFCs, which, for standards track documents usually means, they stay at proposed for years - the widespread adoption of protocols specifications on the internet happens based on specification that are at Proposed, if it happens at all. And the logical consequence of Working Groups not updating and fixing Proposed Document specification within a year after publication as RFC, in order to improve interoperability and the quality of the specification on which the software is based that runs the internet -- is to apply more thorough peer review and scrutiny at that point of the standardization process that can not be evaded by WG constituencies, before the adoption of the specification as Proposed Standard. I recently saw a proposal (by a WG chair) to adopt a new charter item following a list of 3 WG documents at or heading for PS: The WG will attempt to avoid gratuitous changes to these protocols. I do not believe that such a statement is motivated by the three maturity levels for documents, but rather caused by constituencies and emotional engagement by individuals with documents they authored or contributed to, that do not want specification to be updated, fixed or changed after these have been published as RFC. I don't think this reflects the current status quo in the slightest. I think our current PS maturity is essentially considered production quality, although we anticipate that clarifications in the specification may be required, and consultation with other implementors is likely to be beneficial. Some IETF participants do, some don't, which results in controversy. My understanding of the IETF standardization process, in particular with respect to specification at PS is updating a spec to improve interoperability is good, reducing complexity is good, i.e. making stuff optional that is hardly used or creates interop problems. And when there are several different extensibility options in a protocol, some of which with very high interop in the installed base and some of which with poor interop in the installed base, then redefining useful features to use the more interoperable extensibility is useful. However, there sometimes are constituencies in IETF WGs that take the position the PS spec MUST NOT be updated or changed, unless proven beyound all doubt, that the spec does not work at all. In particular, for better or worse, the wider internet technical community - ie, the people who are aware of, but not involved in, the IETF - expect our PS documents to have high quality, and would be caught unawares by a sudden shift back to this stance. +1 I assume that for every IETF spec implementer within the IETF, there are 10 or more implementors that do not participate the IETF. And it is for those others that we should produce, and update/improve our specifications, at least once in a while. So to make this clear, I think that as the requirements and scrutiny of PS documents have increased, the quality has as a result, and - undoubtedly more important - the expected quality has also. I am suprised that you don't see this as quite apparent. We have, in general, raised the bar over the years for PS documents, and - whether or not you think this was a good idea - this horse has left the station, and it's too late to put the lid back on - the wider world now expects this. +1 -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels-06
On 5/6/2011 9:15 AM, Martin Rex wrote: The real problem tha the IETF is regularly facing are constituencies that will fight hard against specifications getting updated, improved or fixed, once they have been published as RFC. That seems particularly true about possible changes to RFC 2026. It is, indeed, a problem... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels-06
On 5/6/2011 9:01 AM, Andrew Sullivan wrote: I think he is saying that there is are _de facto_ criteria that are neither called out in 2026 nor in this draft, and that those criteria are the running code, so the documentation ought to be made to match. Oh. But then that doesn't mean that the /current/ draft lowers quality but that the existing process has exhibited the lower. In that case, it seems like the concrete way to resolve such concerns is to propose specific text to add to the current draft? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels-06
On Fri, May 06, 2011 at 09:27:16AM -0700, Dave CROCKER wrote: On 5/6/2011 9:01 AM, Andrew Sullivan wrote: I think he is saying that there is are _de facto_ criteria that are neither called out in 2026 nor in this draft, and that those criteria are the running code, so the documentation ought to be made to match. Oh. But then that doesn't mean that the /current/ draft lowers quality but that the existing process has exhibited the lower. No, it does not. RFC 2026 has a low bar of entry to get something published as PS. As a matter of fact, we don't do what's in 2026. Things published as PS are often quite mature. Since just about nothing moves past PS anyway, people regard it as the effective final level of standardization and therefore require high degrees of review before publication. And once something is published at PS, it is all but impossible to change it in any but the most trivial ways, because of all the contracts that refer to that RFC and require conformance. So in fact a document published as PS has met criteria more stringent than RFC 20206 would have one believe. The present draft explicitly says that the actual criteria as actually published in RFC 2026 are the right ones, and that additional unwritten conventions and so on are to be removed. Therefore, if one thinks those more stringent criteria make for higher quality, then the current draft will lower quality. I think we could state this all more neutrally by saying only that the existing actual criteria do not match the published criteria, and that therefore when the current draft says go back to RFC 2026 published criteria is is in fact changing the criteria. Then we don't have to have an argument about whether the quality is better, since I don't know how that would be measured anyway. But in any case, the document flat out admits that it is changing these criteria: Various influences have made publishing a Proposed Standard much harder than the stated requirements in RFC 2026. The intention of the two-tier maturity ladder is to restore practice to the requirements for Proposed Standard from RFC 2026, and stop performing more scrutiny than intended in IETF working groups and the IESG. So we should not pretend that the draft doesn't change criteria for PS. It just reiterates a position about what should happen. It remains to be seen what will actually happen. And again, I have no horse in this race. I don't believe the document will make any difference at all, but for that very reason I don't care whether it is adopted. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels-06
--On Friday, May 06, 2011 18:15 +0200 Martin Rex m...@sap.com wrote: The real problem tha the IETF is regularly facing are constituencies that will fight hard against specifications getting updated, improved or fixed, once they have been published as RFC. Martin, That is an interesting observation/ claim. Because I don't think I've seen that happen, I'd appreciate some examples. I have seen: * Insistence that any updated version of a document address all known outstanding issues, including insistence that the revised document not move forward until specific changes for which there is no clear consensus be included. In other words, if there is community consensus for changes A and B to document X, but no consensus that change C is needed (or appropriate, or even correct) some people will try to block approval of an X-bis that incorporates only changes A and B until everyone agrees to C. That is a very difficult problem in any standards body. We have sometimes gotten around it by explicitly noting that issue C remains controversial, but rarely without some resistance. But the problem isn't resistance to updates and improvements, only controversy about whether the changes are sufficient. * Insistence by various groups, often (at least apparently) only the IESG, that any document being revised be altered to conform to multiple requirements for content or editorial style that are more recent than the original document and in spite a no evidence that that older style or organization was causing any problems. That clearly makes it more difficult to get an update with actual corrections, etc., issued than it might be. But I've not seen anything that I interpret as evidence of resistance to change or updates once an RFC is published, only procedural and editorial requirements for publication of updated documents that sometimes create barriers that seem unnecessary and inappropriate. * Certainly WGs and others tend to run out of energy once initial RFCs are published. If no one is willing to produce a new or updated draft and persuade others to review it, then revisions are not going to happen. But your comment implies active opposition to such revisions: no energy is not active opposition. Indeed, while I don't think it is justified in today's environment, IIR part of what caused the 2026 advance or die provision was the belief that, if no one cared enough about a given specification to advance it, maybe we didn't need it any more. As someone who has been responsible for several RFCs and who has worked on updates to a large subset of them, I've seen a lot of pushback asking for more, but little or no pushback for the idea of reviewing and revising specs. While I see those issues as significant, none of them have anything to do with this particular proposal: they apply equally regardless of how many steps there are in the Standards Track, apply to documents being recycled in grade, and even apply to non-standards-track materials. So you may be seeing things that I'm not (behaviors do differ between areas and even among protocol families within an area) but, if you are seeing active pushback on making revisions, I'd be interested in hearing specifics about that, what you would propose to do about it, and why this document is either helpful or unhelpful in that regard. regards, john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels-06
On Fri May 6 17:50:07 2011, Andrew Sullivan wrote: On Fri, May 06, 2011 at 09:27:16AM -0700, Dave CROCKER wrote: On 5/6/2011 9:01 AM, Andrew Sullivan wrote: I think he is saying that there is are _de facto_ criteria that are neither called out in 2026 nor in this draft, and that those criteria are the running code, so the documentation ought to be made to match. Oh. But then that doesn't mean that the /current/ draft lowers quality but that the existing process has exhibited the lower. No, it does not. RFC 2026 has a low bar of entry to get something published as PS. As a matter of fact, we don't do what's in 2026. Things published as PS are often quite mature. Since just about nothing moves past PS anyway, people regard it as the effective final level of standardization and therefore require high degrees of review before publication. And once something is published at PS, it is all but impossible to change it in any but the most trivial ways, because of all the contracts that refer to that RFC and require conformance. So in fact a document published as PS has met criteria more stringent than RFC 20206 would have one believe. The present draft explicitly says that the actual criteria as actually published in RFC 2026 are the right ones, and that additional unwritten conventions and so on are to be removed. Therefore, if one thinks those more stringent criteria make for higher quality, then the current draft will lower quality. I think we could state this all more neutrally by saying only that the existing actual criteria do not match the published criteria, and that therefore when the current draft says go back to RFC 2026 published criteria is is in fact changing the criteria. Then we don't have to have an argument about whether the quality is better, since I don't know how that would be measured anyway. But in any case, the document flat out admits that it is changing these criteria: Various influences have made publishing a Proposed Standard much harder than the stated requirements in RFC 2026. The intention of the two-tier maturity ladder is to restore practice to the requirements for Proposed Standard from RFC 2026, and stop performing more scrutiny than intended in IETF working groups and the IESG. So we should not pretend that the draft doesn't change criteria for PS. It just reiterates a position about what should happen. It remains to be seen what will actually happen. Thanks for explaining that; it is indeed what I'm trying to say. And again, I have no horse in this race. I don't believe the document will make any difference at all, but for that very reason I don't care whether it is adopted. I would rather not make the situation worse, especially without documentation which shows we have a real understanding of the de-facto standards process. Ideally, I'd rather we first - before any attempts are made to change the standards process - document what it *is*. Then, we should have a clearer understanding of the problems we're attempting to solve, and it should prove a lot less contentious. Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - 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://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels-06
Martin, I think you may actually be arguing for a 1 step process. Eliot ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels-06
I think he is saying that there is are _de facto_ criteria that are neither called out in 2026 nor in this draft, and that those criteria are the running code, so the documentation ought to be made to match. This suggests that perhaps we should rename Proposed Standard to Not a Standard But Might Be One Later, promote the PS published under the overstrict rules to DS, and we're done. I'm not sure whether I'm serious or not. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels-06
This suggests that perhaps we should rename Proposed Standard to Not a Standard But Might Be One Later, promote the PS published under the overstrict rules to DS, and we're done. I'm not sure whether I'm serious or not. Whether you are or not.., the only way to do this is to stop calling them RFCs. Maybe we should have a PROP series for PS docs, and only give them RFC numbers later, when they progress. Barry ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels-06
This suggests that perhaps we should rename Proposed Standard to Not a Standard But Might Be One Later, promote the PS published under the overstrict rules to DS, and we're done. I'm not sure whether I'm serious or not. Whether you are or not.., the only way to do this is to stop calling them RFCs. Maybe we should have a PROP series for PS docs, and only give them RFC numbers later, when they progress. Well, you know, the Not a Standard But Might Be One Later really are requesting comments. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Please consider the environment before reading this e-mail. http://jl.ly ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels-06
On Fri May 6 22:12:35 2011, Barry Leiba wrote: This suggests that perhaps we should rename Proposed Standard to Not a Standard But Might Be One Later, promote the PS published under the overstrict rules to DS, and we're done. I'm not sure whether I'm serious or not. Whether you are or not.., the only way to do this is to stop calling them RFCs. Maybe we should have a PROP series for PS docs, and only give them RFC numbers later, when they progress. This is not far off Scott Bradner's 2004 suggestion of Stable Snapshots of I-Ds. It's also like the (much more versatile) labelling proposal Keith Moore made here. Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - 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://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels-06
John said... Well, you know, the Not a Standard But Might Be One Later really are requesting comments. Yes, well, we all know that RFC has lost any real sense of its expansion long ago. It certainly has done so in the eyes of most of the world, for whom RFC means Internet standard. Dave Cridland sid... It's also like the (much more versatile) labelling proposal Keith Moore made here. Perhaps, but Keith's labelling proposal is still not sufficient if we CALL them RFCs. The *only* way to make people not look at them as already standard is by NOT giving them RFC numbers. Now, I'm not sure that's what we should do. But I *am* sure it's the only way to do it. Barry ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels-06
On 5/6/2011 2:29 PM, John R. Levine wrote: Whether you are or not.., the only way to do this is to stop calling them RFCs. Maybe we should have a PROP series for PS docs, and only give them RFC numbers later, when they progress. Well, you know, the Not a Standard But Might Be One Later really are requesting comments. seems like that is rather cumbersome phrasing for a label. perhaps we can come up with a term that is shorter but implies a similar status with regard to now and later. hmmm. what about the word 'proposed'? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels-06
On Fri May 6 22:37:20 2011, Barry Leiba wrote: John said... Well, you know, the Not a Standard But Might Be One Later really are requesting comments. Yes, well, we all know that RFC has lost any real sense of its expansion long ago. It certainly has done so in the eyes of most of the world, for whom RFC means Internet standard. Actually, for most of the world, it means Rugby Football Club. But yes, for the majority of folk who know about protocol specs, then RFC means Standard. Dave Cridland sid... It's also like the (much more versatile) labelling proposal Keith Moore made here. Perhaps, but Keith's labelling proposal is still not sufficient if we CALL them RFCs. The *only* way to make people not look at them as already standard is by NOT giving them RFC numbers. Right, which is why both Scott and Keith's proposals involve I-Ds, not RFCs. Now, I'm not sure that's what we should do. But I *am* sure it's the only way to do it. I think it represents the sanest approach proposed so far. Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - 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://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels-06
Barry Leiba wrote: John said... Well, you know, the Not a Standard But Might Be One Later really are requesting comments. Yes, well, we all know that RFC has lost any real sense of its expansion long ago. It certainly has done so in the eyes of most of the world, for whom RFC means Internet standard. Correct. It really does not matter how *WE* call it, it is not going to affect in any way what the world does with it as long as it has the published status. In many areas 90% of the implementors are outside of the IETF. And if they get the task to implement and ship some protocol in a product -- they will check the RFC index for a document describing the protocol. And if there is exactly one version of a protocol (and ultimately just one RFC document describing it), then they going to use exactly that document for their implementation, indepent of what labelboilerplate the IETF has slapped on the front page. It really does not matter whether it reads Informational, Proposed Standard, Draft Standard or Standard. They need to implement it, there is just one document describing it, so really, what does this matter? And frankly, large parts of the internet run with protocols and specification that are Informational and Proposed, and a non-marginal part even runs on I-Ds. The large majority out there just doesn't care how many document maturity levels the IETF uses. And the folks that prefer more numerous and easier I-D - RFC transitions are likely the early adopters which are frequently shipping products based on I-Ds, and often the members of constituencies that would love to completely lock down a specification as soon as they ship a product based on it. -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels-06
07.05.2011 0:29, John R. Levine wrote: This suggests that perhaps we should rename Proposed Standard to Not a Standard But Might Be One Later, promote the PS published under the overstrict rules to DS, and we're done. I'm not sure whether I'm serious or not. Whether you are or not.., the only way to do this is to stop calling them RFCs. Maybe we should have a PROP series for PS docs, and only give them RFC numbers later, when they progress. Well, you know, the Not a Standard But Might Be One Later really are requesting comments. Why invent something new? The Experimental category covers what you want to name Not a Standard But Might Be One Later; Experimental docs. are fine for permanent record of some protocol to encourage its experimental implementations to produce the Standards Track document of really high level (since it's based on received experience with this protocol). Some recent RFCs are good examples; see eg. http://tools.ietf.org/html/rfc6137#section-1.5 The other problem (if it is) is that implementators really don't care whether the Standards Track document is Proposed, Draft or Full; as mentioned before in this thread, everything named RFC is considered to be stable and OK for implementation (maybe, except Historic documents :-). And this can't be changed; this is established; this is implementator's mentality. Considering it, many WGs/folks who once wrote Proposed Standard see no sense to move it forward to Draft and Full. Considering this, even though it was planned by RFC 2026 in the other way, Proposed Standards are actually worth that scrutiny they are currently given (even though I personally can hardly agree with this statement). Mykyta Yevstifeyev Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Please consider the environment before reading this e-mail. http://jl.ly ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels-06
On 5/5/2011 10:22 AM, Dave Cridland wrote: On balance, whilst I appreciate the aims of this document, I think the proposals are not suitable for adoption. 1) This document radically lowers the quality of Proposed Standards. What, specifically, are the parts of the proposal that you believe will lower the quality of a Proposed Standard? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels-05
19.04.2011 1:21, Russ Housley wrote: Mykyta: 4. Downward References Permitted This section says nothing about references to documents with no status (pre-IETF RFCs). Maybe informative references to such RFCs should be allowed. And what about normative ones? Whether the RFC 3967 procedure will be used in such cases, or such references are disallowed in Standards Track docs? I think this should also be mentioned in your draft. What does this have to do with moving from two maturity levels? Mostly nothing, but if you consider that the whole Section 4 is appropriate for your document, what I propose is appropriate also. Mykyta Russ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels-05
Mykyta: 4. Downward References Permitted This section says nothing about references to documents with no status (pre-IETF RFCs). Maybe informative references to such RFCs should be allowed. And what about normative ones? Whether the RFC 3967 procedure will be used in such cases, or such references are disallowed in Standards Track docs? I think this should also be mentioned in your draft. What does this have to do with moving from two maturity levels? Mostly nothing, but if you consider that the whole Section 4 is appropriate for your document, what I propose is appropriate also. I just reviewed RFC 3967. It does not seem to claim that references to those older documents requires special handling. I'd like to leave this topic to an update to RFC 3967 if such an update is needed at all. Russ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels-05
On 4/19/11 9:57 AM, Russ Housley wrote: Mykyta: 4. Downward References Permitted This section says nothing about references to documents with no status (pre-IETF RFCs). Maybe informative references to such RFCs should be allowed. And what about normative ones? Whether the RFC 3967 procedure will be used in such cases, or such references are disallowed in Standards Track docs? I think this should also be mentioned in your draft. What does this have to do with moving from two maturity levels? Mostly nothing, but if you consider that the whole Section 4 is appropriate for your document, what I propose is appropriate also. I just reviewed RFC 3967. It does not seem to claim that references to those older documents requires special handling. I'd like to leave this topic to an update to RFC 3967 if such an update is needed at all. +1. Let's keep this I-D short and focused. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels-05
06.04.2011 18:27, Russ Housley wrote:
This revision proposes a solution to the issue raised by Brian Carpenter about
documents lingering at Draft Standard. Some people thought it was a problem.
Others thought it did not matter. The proposed solution leaves the matter in
the hands of the IESG.
Russ,
Hello again. I have another minor comment regarding this document.
4. Downward References Permitted
This section says nothing about references to documents with no status
(pre-IETF RFCs). Maybe informative references to such RFCs should be
allowed. And what about normative ones? Whether the RFC 3967 procedure
will be used in such cases, or such references are disallowed in
Standards Track docs? I think this should also be mentioned in your draft.
Mykyta Yevstifeyev
Russ
Begin forwarded message:
From: IETF I-D Submission Toolidsubmiss...@ietf.org
Date: April 6, 2011 11:22:25 AM EDT
To: hous...@vigilsec.com
Cc: dcroc...@bbiw.net, ebur...@standardstrack.com
Subject: New Version Notification for draft-housley-two-maturity-levels-05
A new version of I-D, draft-housley-two-maturity-levels-05.txt has been
successfully submitted by Russ Housley and posted to the IETF repository.
Filename:draft-housley-two-maturity-levels
Revision:05
Title: Reducing the Standards Track to Two Maturity Levels
Creation_date: 2011-04-06
WG ID: Independent Submission
Number_of_pages: 7
Abstract:
This document proposes several changes to the Internet Engineering
Task Force (IETF) Standards Process defined in RFC 2026, primarily a
reduction from three IETF standards track maturity levels to two.
{{ RFC Editor: please change proposes several changes to the to
changes the. }}
The IETF Secretariat.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels-05
2011/4/7, Russ Housley hous...@vigilsec.com:
Mykyta:
If this approach is acceptable to the community, implementation reports will
no longer be needed at all.
In this case your document should obsolete RFC 5657 and mention this.
Mykyta
Russ
On Apr 7, 2011, at 10:09 AM, Mykyta Yevstifeyev wrote:
06.04.2011 18:27, Russ Housley wrote:
This revision proposes a solution to the issue raised by Brian Carpenter
about documents lingering at Draft Standard. Some people thought it was
a problem. Others thought it did not matter. The proposed solution
leaves the matter in the hands of the IESG.
I can hardly see my comments from 18 March
(http://www.ietf.org/mail-archive/web/ietf/current/msg65911.html)
considered in -05. Are you planning to make any changes regarding this in
-06?
Mykyta Yevstifeyev
Russ
Begin forwarded message:
From: IETF I-D Submission Toolidsubmiss...@ietf.org
Date: April 6, 2011 11:22:25 AM EDT
To: hous...@vigilsec.com
Cc: dcroc...@bbiw.net, ebur...@standardstrack.com
Subject: New Version Notification for
draft-housley-two-maturity-levels-05
A new version of I-D, draft-housley-two-maturity-levels-05.txt has been
successfully submitted by Russ Housley and posted to the IETF
repository.
Filename: draft-housley-two-maturity-levels
Revision: 05
Title: Reducing the Standards Track to Two Maturity Levels
Creation_date: 2011-04-06
WG ID: Independent Submission
Number_of_pages: 7
Abstract:
This document proposes several changes to the Internet Engineering
Task Force (IETF) Standards Process defined in RFC 2026, primarily a
reduction from three IETF standards track maturity levels to two.
{{ RFC Editor: please change proposes several changes to the to
changes the. }}
The IETF Secretariat.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels-05
06.04.2011 18:27, Russ Housley wrote:
This revision proposes a solution to the issue raised by Brian Carpenter about
documents lingering at Draft Standard. Some people thought it was a problem.
Others thought it did not matter. The proposed solution leaves the matter in
the hands of the IESG.
I can hardly see my comments from 18 March
(http://www.ietf.org/mail-archive/web/ietf/current/msg65911.html)
considered in -05. Are you planning to make any changes regarding this
in -06?
Mykyta Yevstifeyev
Russ
Begin forwarded message:
From: IETF I-D Submission Toolidsubmiss...@ietf.org
Date: April 6, 2011 11:22:25 AM EDT
To: hous...@vigilsec.com
Cc: dcroc...@bbiw.net, ebur...@standardstrack.com
Subject: New Version Notification for draft-housley-two-maturity-levels-05
A new version of I-D, draft-housley-two-maturity-levels-05.txt has been
successfully submitted by Russ Housley and posted to the IETF repository.
Filename:draft-housley-two-maturity-levels
Revision:05
Title: Reducing the Standards Track to Two Maturity Levels
Creation_date: 2011-04-06
WG ID: Independent Submission
Number_of_pages: 7
Abstract:
This document proposes several changes to the Internet Engineering
Task Force (IETF) Standards Process defined in RFC 2026, primarily a
reduction from three IETF standards track maturity levels to two.
{{ RFC Editor: please change proposes several changes to the to
changes the. }}
The IETF Secretariat.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels-05
Mykyta:
If this approach is acceptable to the community, implementation reports will no
longer be needed at all.
Russ
On Apr 7, 2011, at 10:09 AM, Mykyta Yevstifeyev wrote:
06.04.2011 18:27, Russ Housley wrote:
This revision proposes a solution to the issue raised by Brian Carpenter
about documents lingering at Draft Standard. Some people thought it was a
problem. Others thought it did not matter. The proposed solution leaves
the matter in the hands of the IESG.
I can hardly see my comments from 18 March
(http://www.ietf.org/mail-archive/web/ietf/current/msg65911.html) considered
in -05. Are you planning to make any changes regarding this in -06?
Mykyta Yevstifeyev
Russ
Begin forwarded message:
From: IETF I-D Submission Toolidsubmiss...@ietf.org
Date: April 6, 2011 11:22:25 AM EDT
To: hous...@vigilsec.com
Cc: dcroc...@bbiw.net, ebur...@standardstrack.com
Subject: New Version Notification for draft-housley-two-maturity-levels-05
A new version of I-D, draft-housley-two-maturity-levels-05.txt has been
successfully submitted by Russ Housley and posted to the IETF repository.
Filename:draft-housley-two-maturity-levels
Revision:05
Title: Reducing the Standards Track to Two Maturity Levels
Creation_date: 2011-04-06
WG ID: Independent Submission
Number_of_pages: 7
Abstract:
This document proposes several changes to the Internet Engineering
Task Force (IETF) Standards Process defined in RFC 2026, primarily a
reduction from three IETF standards track maturity levels to two.
{{ RFC Editor: please change proposes several changes to the to
changes the. }}
The IETF Secretariat.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels-05
The last *several* revisions have been perfectly fine. The most recent edits are also fine. We're micro-editing this document at this point, meaning that perfect is impeding our ability to deploy more than good enough to replace 3-tier system that most IETF folks agree is broken, and has been broken for at least a decade. A tiny few people might like to edit this document more, but the IETF supposedly operates upon rough consensus, rather than either smooth consensus or unanimity. Could we please Last Call, approve, and ship this right now ? Yours, Ran Atkinson ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels-05
On 06.04.2011 17:27, Russ Housley wrote: This revision proposes a solution to the issue raised by Brian Carpenter about documents lingering at Draft Standard. Some people thought it was a problem. Others thought it did not matter. The proposed solution leaves the matter in the hands of the IESG. Russ ... A question...: A specification shall remain at the Proposed Standard maturity level for at least six (6) months before consideration for advancement to the Internet Standard maturity level. It would probably good to clarify when the six month period starts (IESG approval? RFC publication?). Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels-05
On 4/6/11 10:45 AM, Julian Reschke wrote: On 06.04.2011 17:27, Russ Housley wrote: This revision proposes a solution to the issue raised by Brian Carpenter about documents lingering at Draft Standard. Some people thought it was a problem. Others thought it did not matter. The proposed solution leaves the matter in the hands of the IESG. Russ ... A question...: A specification shall remain at the Proposed Standard maturity level for at least six (6) months before consideration for advancement to the Internet Standard maturity level. It would probably good to clarify when the six month period starts (IESG approval? RFC publication?). RFC publication seems sensible -- sometimes it can take more than six months between IESG approval and RFC publication! (Slow authors during AUTH48, dependencies on yet-to-be-published specs, etc.) Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels-05
Julian: A question...: A specification shall remain at the Proposed Standard maturity level for at least six (6) months before consideration for advancement to the Internet Standard maturity level. It would probably good to clarify when the six month period starts (IESG approval? RFC publication?). This is not a new question. It comes up every few years, and it was a big topic a few yers back when there was a long delay between approval and RFC publication. The 6 months starts with RFC publication. Russ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels-05
Russ == Russ Housley hous...@vigilsec.com writes: Russ The 6 months starts with RFC publication. Please say that in the draft then. I had a different take away from the last version of this discussion I participated in. I don't care much what the answer is, but it seems clear that it requires documentation. Apologies if it is already stated elsewhere in the draft: I have not read 05 yet. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels-05
Sam and Julian: Russ == Russ Housley hous...@vigilsec.com writes: Russ The 6 months starts with RFC publication. Please say that in the draft then. I had a different take away from the last version of this discussion I participated in. I don't care much what the answer is, but it seems clear that it requires documentation. Apologies if it is already stated elsewhere in the draft: I have not read 05 yet. I will add a sentence in -06 to make this clear. Russ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels-05
On 2011-04-07 03:27, Russ Housley wrote: This revision proposes a solution to the issue raised by Brian Carpenter about documents lingering at Draft Standard. Some people thought it was a problem. Others thought it did not matter. The proposed solution leaves the matter in the hands of the IESG. That seems like a fine approach; it allows common sense to be applied. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
Russ, all, Another proposal as for your document. So, it fails to mention what are the procedures for reclassification of Standards Track RFCs to Historic. Therefore, I propose the following text: 6. Procedures for Reclassification of Standards Track RFCs as Historic Documents Under some circumstances Standards Track RFCs may be reclassified to Historic document (i. e. its initial status may be changed to Historic). RFC 2026 [1], as well as its predecessors, contains some words about the Historic RFCs, but it failes to define the procedures for reclassification of RFCs to Historic status. Such situation, of course, causes misunderstandings of the members of the community. This document removes this uncertainty; it defines the circumstances under what the Standards Track RFC should be moved to Historic status and describes the procedures for such action. The Standards Track RFC, either Proposed Standard or Internet Standard, should be considered to be appropriate for reclassification as Historic document if (a) there is another document that replaces it or (b) it described the protocol or other technology that got out-of-use. In the case mentioned as (a) above the superseding document should just have the notice of the necessity of reclassification of its predecessor to Historic. However such action is not obligatory. In the case mentioned as (b) above the procedure is as follows. If the individual or a group of individuals (e. g. IETF working group) assume that the protocol or other technology defined in the Standards Track RFC is now out-of-use and is very unlikely to become widely used in the future, they SHALL apply to IESG to request the reclassification of such document to Historic. IESG SHALL then issue the IETF-wide Last Call on this action, not shorter than 2 weeks, in order to determine whether there is the community consensus on reclassification. If Last Call did not reveal community objection to this action, this document SHALL be reclassified to Historic. During the sunset period, set by this document, Draft Standards SHALL be reclassified to Historic using the procedure as defined above. ... and renumber the following sections. What do you think about this proposal? Mykyta Yevstifeyev 14.03.2011 1:32, Russ Housley wrote: There have been conflicting suggestions about the best way forward. We have constructed an updated proposal. It has been posted as draft-housley-two-maturity-levels-04. Russ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
As far as I can tell, your proposal does not match the meaning we use for Historic. More importantly, there does not seem to be a problem that needs to be addressed in this area. Most importantly, if there is a problem, it should in my opinion be addressed separately from the topic of this draft. Please do not conflate the two. Yours, Joel M. Halpern On 3/24/2011 11:32 AM, Mykyta Yevstifeyev wrote: Russ, all, Another proposal as for your document. So, it fails to mention what are the procedures for reclassification of Standards Track RFCs to Historic. Therefore, I propose the following text: 6. Procedures for Reclassification of Standards Track RFCs as Historic Documents Under some circumstances Standards Track RFCs may be reclassified to Historic document (i. e. its initial status may be changed to Historic). RFC 2026 [1], as well as its predecessors, contains some words about the Historic RFCs, but it failes to define the procedures for reclassification of RFCs to Historic status. Such situation, of course, causes misunderstandings of the members of the community. This document removes this uncertainty; it defines the circumstances under what the Standards Track RFC should be moved to Historic status and describes the procedures for such action. The Standards Track RFC, either Proposed Standard or Internet Standard, should be considered to be appropriate for reclassification as Historic document if (a) there is another document that replaces it or (b) it described the protocol or other technology that got out-of-use. In the case mentioned as (a) above the superseding document should just have the notice of the necessity of reclassification of its predecessor to Historic. However such action is not obligatory. In the case mentioned as (b) above the procedure is as follows. If the individual or a group of individuals (e. g. IETF working group) assume that the protocol or other technology defined in the Standards Track RFC is now out-of-use and is very unlikely to become widely used in the future, they SHALL apply to IESG to request the reclassification of such document to Historic. IESG SHALL then issue the IETF-wide Last Call on this action, not shorter than 2 weeks, in order to determine whether there is the community consensus on reclassification. If Last Call did not reveal community objection to this action, this document SHALL be reclassified to Historic. During the sunset period, set by this document, Draft Standards SHALL be reclassified to Historic using the procedure as defined above. ... and renumber the following sections. What do you think about this proposal? Mykyta Yevstifeyev 14.03.2011 1:32, Russ Housley wrote: There have been conflicting suggestions about the best way forward. We have constructed an updated proposal. It has been posted as draft-housley-two-maturity-levels-04. Russ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
24.03.2011 17:42, Joel M. Halpern wrote: As far as I can tell, your proposal does not match the meaning we use for Historic. More importantly, there does not seem to be a problem that needs to be addressed in this area. Most importantly, if there is a problem, it should in my opinion be addressed separately from the topic of this draft. Please do not conflate the two. While it is not directly related to the draft's topic, it it just an attempt since this draft is very likely to become published unlike the separate proposal on this topic. Mykyta Yours, Joel M. Halpern On 3/24/2011 11:32 AM, Mykyta Yevstifeyev wrote: Russ, all, Another proposal as for your document. So, it fails to mention what are the procedures for reclassification of Standards Track RFCs to Historic. Therefore, I propose the following text: 6. Procedures for Reclassification of Standards Track RFCs as Historic Documents Under some circumstances Standards Track RFCs may be reclassified to Historic document (i. e. its initial status may be changed to Historic). RFC 2026 [1], as well as its predecessors, contains some words about the Historic RFCs, but it failes to define the procedures for reclassification of RFCs to Historic status. Such situation, of course, causes misunderstandings of the members of the community. This document removes this uncertainty; it defines the circumstances under what the Standards Track RFC should be moved to Historic status and describes the procedures for such action. The Standards Track RFC, either Proposed Standard or Internet Standard, should be considered to be appropriate for reclassification as Historic document if (a) there is another document that replaces it or (b) it described the protocol or other technology that got out-of-use. In the case mentioned as (a) above the superseding document should just have the notice of the necessity of reclassification of its predecessor to Historic. However such action is not obligatory. In the case mentioned as (b) above the procedure is as follows. If the individual or a group of individuals (e. g. IETF working group) assume that the protocol or other technology defined in the Standards Track RFC is now out-of-use and is very unlikely to become widely used in the future, they SHALL apply to IESG to request the reclassification of such document to Historic. IESG SHALL then issue the IETF-wide Last Call on this action, not shorter than 2 weeks, in order to determine whether there is the community consensus on reclassification. If Last Call did not reveal community objection to this action, this document SHALL be reclassified to Historic. During the sunset period, set by this document, Draft Standards SHALL be reclassified to Historic using the procedure as defined above. ... and renumber the following sections. What do you think about this proposal? Mykyta Yevstifeyev 14.03.2011 1:32, Russ Housley wrote: There have been conflicting suggestions about the best way forward. We have constructed an updated proposal. It has been posted as draft-housley-two-maturity-levels-04. Russ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
On 3/24/2011 4:49 PM, Mykyta Yevstifeyev wrote: Another proposal as for your document. So, it fails to mention what are the procedures for reclassification of Standards Track RFCs to Historic. Generally, the document tries to limit itself to discussion of what it changes. There are no changes proposed for moving to Historic. (The question of Historic has not been part of the many discussions about streamlining the standards labeling.) Hence that issue is out of scope for the document. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
On Mar 24, 2011, at 5:01 PM, Dave CROCKER wrote: On 3/24/2011 4:49 PM, Mykyta Yevstifeyev wrote: Another proposal as for your document. So, it fails to mention what are the procedures for reclassification of Standards Track RFCs to Historic. Generally, the document tries to limit itself to discussion of what it changes. There are no changes proposed for moving to Historic. (The question of Historic has not been part of the many discussions about streamlining the standards labeling.) Hence that issue is out of scope for the document. +1 Bob ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
Agreed. On Mar 24, 2011, at 12:13 PM, Bob Hinden wrote: On Mar 24, 2011, at 5:01 PM, Dave CROCKER wrote: On 3/24/2011 4:49 PM, Mykyta Yevstifeyev wrote: Another proposal as for your document. So, it fails to mention what are the procedures for reclassification of Standards Track RFCs to Historic. Generally, the document tries to limit itself to discussion of what it changes. There are no changes proposed for moving to Historic. (The question of Historic has not been part of the many discussions about streamlining the standards labeling.) Hence that issue is out of scope for the document. +1 Bob ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
There seems to be a minor but important inconsistency which leaves us still not clearly addressing the interoperability issues. The commentary text on the second standards level includes, when commenting on the removal of the requirement for interoperability testing reports: subsumed by the requirement for actual deployment and use of independent and interoperable implementations. While not perfect (nothing is), such a requirement would probably leave me satisfied. However, there is no requirement in general for multiple independent implementations. There is a requirement for multiple implementations and successful operational experience. There is only a requirement for independent implementations relative to patented or otherwise controlled technologies. And even that requirement does not say anything about any interoperability of those independent implementations. Yours, Joel On 3/13/2011 7:32 PM, Russ Housley wrote: There have been conflicting suggestions about the best way forward. We have constructed an updated proposal. It has been posted as draft-housley-two-maturity-levels-04. Russ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
There have been conflicting suggestions about the best way forward. We have constructed an updated proposal. It has been posted as draft-housley-two-maturity-levels-04. Russ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: prerequisite for change (was Re: draft-housley-two-maturity-levels)
On 1/30/2011 8:06 AM, Andrew Sullivan wrote: On Sun, Jan 30, 2011 at 07:49:44AM -0800, Dave CROCKER wrote: The current proposal specifies a second maturity level that does not permit changing the technical specification. Yes, I know. I fail completely to see why anyone would ever do the work for such movement of maturity level. The proposal seems to me to be something along the lines of giving gold stars to protocols with people who are willing to do the busywork. One of the challenges in the discussion of this topic on the IETF list is some very different models of the role of a standards label. Given the frequent view that only technical details matter, one would think that we are composed only of engineers who give little thought to organizational, social and psychological factors that might also affect adoption decisions... One curiosity about this is that our documentation style for specifications permits far more tutorial and explanatory content than most other standards group, which one might take to indicate that we actually worry a bit about those who will adopt our work and that we actually want to help them. Yet our organization mode tends to consider 'publication' the end of our concern. As folks in the communications game, the IETF tends to have a curious lack of interest in the 'feedback' portion of a Shannon-Weaver model[1], when it comes to protocol adoption. It's as if we stopped reading after the first Shannon paper.[2] In any event, I thought the value proposition of the proposal's second label had been discussed at some length: For significant portions of industry, the decision whether to adopt new technology relies heavily on an assessment of its stability and likely success. Some specs are nascent and fluid. Some are failed. Others are successful. As of now, it can be difficult for such folk to distinguish the real maturity of IETF proposals, since most are at Proposed. So the proposal defines a second stage that serves the purpose of making an official statement of stability and success, by virtue of noting significant deployment. That can be helpful during the market expansion phase of adoption. d/ [1] http://en.wikipedia.org/wiki/Shannon%E2%80%93Weaver_model [2] http://plan9.bell-labs.com/cm/ms/what/shannonday/shannon1948.pdf -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: prerequisite for change (was Re: draft-housley-two-maturity-levels)
I believe this proposal to be dangerous and undesirable. The fact is that the three stage process has never worked. As in not ever. If you take a look at the current Internet standards over half of the total are grandfathered from before the IETF was started. You cannot return to a state that never existed. The raising of the bar for proposed standard has a very simple reason: it is now almost impossible to change specifications once deployed. There is no point in conducting a security review after the RFC has issued, it is too late. Similarly there is no point in checking to see if the Gen Art criteria are met. Another factor here is that many specifications coming to IETF have already had significant work done. On Sat, Jan 29, 2011 at 5:39 PM, Scott O. Bradner s...@harvard.edu wrote: I've previously expressed my opinion that proposals to muck with the number of steps in teh IETF standards process will no do anything useful (i.e., will not be effective) - JOhn and I have just posted what, to us, would be a prerequisite for amy process mucking proposal to succeed Scott - From: internet-dra...@ietf.org To: i-d-annou...@ietf.org Subject: I-D Action:draft-bradner-restore-proposed-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Restoring Proposed Standard to Its Intended Use Author(s) : J. Klensin, S. Bradner Filename: draft-bradner-restore-proposed-00.txt Pages : 6 Date: 2011-01-29 Restore the very low bar for Proposed Standard described in RFC 2026 (BCP 9) A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bradner-restore-proposed-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Website: http://hallambaker.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: prerequisite for change (was Re: draft-housley-two-maturity-levels)
On Sun, Jan 30, 2011 at 09:27:17AM -0500, Phillip Hallam-Baker wrote: The raising of the bar for proposed standard has a very simple reason: it is now almost impossible to change specifications once deployed. That's an argument for _no_ maturity levels, then, not for two. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: prerequisite for change (was Re: draft-housley-two-maturity-levels)
On Jan 30, 2011, at 9:58 AM, Andrew Sullivan wrote: On Sun, Jan 30, 2011 at 09:27:17AM -0500, Phillip Hallam-Baker wrote: The raising of the bar for proposed standard has a very simple reason: it is now almost impossible to change specifications once deployed. That's an argument for _no_ maturity levels, then, not for two. Is there an implicit assumption here that more standards (presumably of poorer quality) is a good thing? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: prerequisite for change (was Re: draft-housley-two-maturity-levels)
On Sun, Jan 30, 2011 at 10:15:01AM -0500, Keith Moore wrote: That's an argument for _no_ maturity levels, then, not for two. Is there an implicit assumption here that more standards (presumably of poorer quality) is a good thing? Not on my part. I'm merely observing that, if the claim is that you can't alter deployed protocols, then there's no reason to say that we need two maturity levels, because in fact nothing will advance past the first stage anyway. Phillip's description of the state of affairs is consistent with what we actually see today in a three-maturity-level system: nothing moves past the first level. But if the problem is that you can't alter a deployed spec, then no matter how many levels we pare off past the first, nothing will move to those higher levels, because it's only the first level that counts. I'm not happy about this, note. I'm just making an observation about what is entailed by Phillip's description. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: prerequisite for change (was Re: draft-housley-two-maturity-levels)
On Jan 30, 2011, at 10:35 AM, Andrew Sullivan wrote: On Sun, Jan 30, 2011 at 10:15:01AM -0500, Keith Moore wrote: That's an argument for _no_ maturity levels, then, not for two. Is there an implicit assumption here that more standards (presumably of poorer quality) is a good thing? Not on my part. Sorry, I didn't mean to imply that it was your assumption. I do wonder if it's an assumption held by many in the discussion. I'm merely observing that, if the claim is that you can't alter deployed protocols, then there's no reason to say that we need two maturity levels, because in fact nothing will advance past the first stage anyway. As far as I can tell, the principal reason any specifications move beyond Proposed is that they are widely deployed and their limitations become apparent. So I think you can alter deployed protocols, but only if the protocols or their implementations are seen to be sufficiently broken. (Which could lead one to conclude, from a perverse point-of-view, that some flaws should be left in at Proposed Standards so that they'll have to be fixed later, so that we can get more Draft and Full Standards published.) Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: prerequisite for change (was Re: draft-housley-two-maturity-levels)
On 1/30/2011 7:35 AM, Andrew Sullivan wrote: Is there an implicit assumption here that more standards (presumably of poorer quality) is a good thing? Not on my part. I'm merely observing that, if the claim is that you can't alter deployed protocols, then there's no reason to say that we need two maturity levels, because in fact nothing will advance past the first stage anyway. The current proposal specifies a second maturity level that does not permit changing the technical specification. But if the problem is that you can't alter a deployed spec, then no matter how many levels we pare off past the first, nothing will move to those higher levels, because it's only the first level that counts. The rationale for the second level concerns assessment of success, not changes to the protocol. So the basis upon which the second level will succeed or fail has nothing to do with the criterion you are citing. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: prerequisite for change (was Re: draft-housley-two-maturity-levels)
On Sun, Jan 30, 2011 at 07:49:44AM -0800, Dave CROCKER wrote: Not on my part. I'm merely observing that, if the claim is that you can't alter deployed protocols, then there's no reason to say that we need two maturity levels, because in fact nothing will advance past the first stage anyway. The current proposal specifies a second maturity level that does not permit changing the technical specification. Yes, I know. I fail completely to see why anyone would ever do the work for such movement of maturity level. The proposal seems to me to be something along the lines of giving gold stars to protocols with people who are willing to do the busywork. I don't have any special objection to the proposal, and I don't really have strong feelings about whether it goes anywhere. But I don't believe it will change things very much, and it feels to me more like a bureaucratic improvement than something that helps IETF participants and consumers of IETF protocols. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: prerequisite for change (was Re: draft-housley-two-maturity-levels)
On Sun, Jan 30, 2011 at 9:58 AM, Andrew Sullivan a...@shinkuro.com wrote: On Sun, Jan 30, 2011 at 09:27:17AM -0500, Phillip Hallam-Baker wrote: The raising of the bar for proposed standard has a very simple reason: it is now almost impossible to change specifications once deployed. That's an argument for _no_ maturity levels, then, not for two. Not at all, many protocols are never successfully deployed. In the case that a protocol is successfully deployed, the final protocol has frequently required major modification. Documenting those changes has value. -- Website: http://hallambaker.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
On 2011-01-27 16:29, Scott O. Bradner wrote: 1/ I still do not think this (modified) proposal will have any real impact on the number of Proposed Standard documents that move to a (in this proposal, the) higher level since I do not see how this makes any significant changes to the underlying reasons that documents have not progressed in the past - i.e., I see no reason to think that this proposal would change the world much (would not help, would not hurt) I tend to be more optimistic. I think that having only one step ahead to reach final status is *much* less of a psychological barrier, and the name Internet Standard is a *much* more appealing target than Draft Standard. Therefore, I believe this change will be a significant step forward. 2/ I think the proposal must specifically deal with the 2026 IPR licence requirement in section 4.1.2 If patented or otherwise controlled technology is required for implementation, the separate implementations must also have resulted from separate exercise of the licensing process. I strongly agree. This exact sentence should be carried forward. The requirement can be dealt with by explicitly discarding it or by including it. But not mentioning the requirement does not make the issue go away. This requirement was, in theory, a way to keep the IETF/IESG out of the business of evaluating the fairness of licensing terms. I can remember only one time it came up (in an appeal) so getting rid of it may be fine - but don't make it look like it was just forgotten. 3/ I think you also be quite specific as to how to decide that the conditions for advancement have been met - one of the big implementation issues with 2026 was knowing how to decide that a technology was ready to be advanced (did you need a spreadsheet listing all features and noting with ones had been multiply implemented (as was done at huge effort for HTTP 1.1) or is there someting simplier - clear rules would help avoid this type of issue in the future Whike I agree with Scott, I suggest solving this outside the BCP itself. It's quite a complex issue. 4/ as part of #3 - the rules should also specifically deal with the following pp from 2026 The requirement for at least two independent and interoperable implementations applies to all of the options and features of the specification. In cases in which one or more options or features have not been demonstrated in at least two interoperable implementations, the specification may advance to the Draft Standard level only if those options or features are removed. this requirement was included to try to remove cruft from protocols as they went forward - maybe this is no longer a desire but, like with the license issue, a specific mention of what has been decided would mean that people would not think that things were not just forgotton. Actually the draft does not appear to require interoperability testing at all: * There are a significant number of implementations with successful operational experience. Is that intentional? I thought interop was generally regarded as fundamental. So I think the text needs to be explicit about which bits of section 4.1.2 of RFC 2026 still apply. Or expand the sentence by adding , including interoperation between different implementations when meaningful. (It's when meaningful because some standards such as MIB modules don't interoperate as such, see RFC 2438.) On another point: 5. Open Question Regarding STD Numbers IMHO the easiest solution is still what I suggested some years ago: retain STD numbers, but assign them at the PS stage. That removes the confusion about a PS that updates a numbered Standard. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
On 1/29/2011 12:10 PM, Brian E Carpenter wrote: On 2011-01-27 16:29, Scott O. Bradner wrote: 4/ as part of #3 - the rules should also specifically deal with the following pp from 2026 The requirement for at least two independent and interoperable implementations applies to all of the options and features of the ... Actually the draft does not appear to require interoperability testing at all: * There are a significant number of implementations with successful operational experience. Is that intentional? I thought interop was generally regarded as People are confusing testing with use. Those are two different kinds of interoperability, with the latter being far more stringent. The new draft specifies the latter. And it quite intentionally does not specify the former. While testing is extremely important for when doing development, there is no reason that the IETF should be required to include that very intermediary activity within our standards process. So the new proposal has two phases: 1) Specification 2) Use That there are intermediate real-world phases, such as development, testing and deployment is essential, of course. But there is nothing essential in having the IETF mark completion of any of those intermediate phases. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
On 2011-01-30 09:52, Dave CROCKER wrote: On 1/29/2011 12:10 PM, Brian E Carpenter wrote: On 2011-01-27 16:29, Scott O. Bradner wrote: 4/ as part of #3 - the rules should also specifically deal with the following pp from 2026 The requirement for at least two independent and interoperable implementations applies to all of the options and features of the ... Actually the draft does not appear to require interoperability testing at all: * There are a significant number of implementations with successful operational experience. Is that intentional? I thought interop was generally regarded as People are confusing testing with use. Those are two different kinds of interoperability, with the latter being far more stringent. The new draft specifies the latter. And it quite intentionally does not specify the former. Please point to the text that requires *any* kind of interoperability being demonstrated by running code. successful operational experience does not state or imply interoperation between independent implementations. This is a big change in principle from 2026, which is not what is advertised on the box as primarily a reduction from three IETF standards track maturity levels to two. I want a two stage process, but I don't want to lose interoperability as an explicit criterion. To me, that's always been the meaning of the running code slogan. Brian While testing is extremely important for when doing development, there is no reason that the IETF should be required to include that very intermediary activity within our standards process. So the new proposal has two phases: 1) Specification 2) Use That there are intermediate real-world phases, such as development, testing and deployment is essential, of course. But there is nothing essential in having the IETF mark completion of any of those intermediate phases. d/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
prerequisite for change (was Re: draft-housley-two-maturity-levels)
I've previously expressed my opinion that proposals to muck with the number of steps in teh IETF standards process will no do anything useful (i.e., will not be effective) - JOhn and I have just posted what, to us, would be a prerequisite for amy process mucking proposal to succeed Scott - From: internet-dra...@ietf.org To: i-d-annou...@ietf.org Subject: I-D Action:draft-bradner-restore-proposed-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Restoring Proposed Standard to Its Intended Use Author(s) : J. Klensin, S. Bradner Filename: draft-bradner-restore-proposed-00.txt Pages : 6 Date: 2011-01-29 Restore the very low bar for Proposed Standard described in RFC 2026 (BCP 9) A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bradner-restore-proposed-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: prerequisite for change (was Re: draft-housley-two-maturity-levels)
Hi Scott and John, I don't see this as inconsistent with the current 2-stage proposal, if the latter's omission of a requirement for independent interoperable implementations for stage 2 is corrected. I don't, however, believe that the problems are separable. The bar for PS has crept up, IMHO, precisely because the bar for DS/STD has appeared too high to be readily attainable. So I see two ways forward that hang together: 1. draft-bradner-restore-proposed + (draft-housley-two-maturity-levels + independent interoperable implementations) 2. draft-loughney-newtrk-one-size-fits-all-01 (i.e. simply abolish the second and third stages, and make interoperability reports optional) I prefer #1. Regards Brian On 2011-01-30 11:39, Scott O. Bradner wrote: I've previously expressed my opinion that proposals to muck with the number of steps in teh IETF standards process will no do anything useful (i.e., will not be effective) - JOhn and I have just posted what, to us, would be a prerequisite for amy process mucking proposal to succeed Scott - From: internet-dra...@ietf.org To: i-d-annou...@ietf.org Subject: I-D Action:draft-bradner-restore-proposed-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Restoring Proposed Standard to Its Intended Use Author(s) : J. Klensin, S. Bradner Filename: draft-bradner-restore-proposed-00.txt Pages : 6 Date: 2011-01-29 Restore the very low bar for Proposed Standard described in RFC 2026 (BCP 9) A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bradner-restore-proposed-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: prerequisite for change (was Re: draft-housley-two-maturity-levels)
--On Sunday, January 30, 2011 1:01 PM +1300 Brian E Carpenter brian.e.carpen...@gmail.com wrote: Hi Scott and John, I don't see this as inconsistent with the current 2-stage proposal, if the latter's omission of a requirement for independent interoperable implementations for stage 2 is corrected. I won't try to speak for Scott, but I agree. I don't, however, believe that the problems are separable. The bar for PS has crept up, IMHO, precisely because the bar for DS/STD has appeared too high to be readily attainable. I think one can read the symptoms, and cause-effect relationships, in different ways. However, I think it is safe to say that -- * as the bar for PS creeps up, there is less energy, inclination, and motivation to move toward DS/STD * as the percentage of documents --out of those that represent specifications of protocols anyone cares about -- that are actually advanced to DS/STD goes down, the incentives to raise the bar for PS increase. In other words, regardless of what one believes about cause and effect, there is a positive feedback loop operating here. Collapsing STD onto DS is unlikely to affect that loop. There has been no evidence offered that such a collapse will increase the number of documents that advance to that level. Indeed, by _adding_ requirements to a combined DS/STD level, it is at least as likely to raise the perceived threshold for getting to DS/STD without significantly increasing the motivation to push documents into that level. On the other hand, reverting the definition of PS both makes that level faster and increases the motivation to move a document to DS/STD because that second level become the first one at which a reader can really expect a complete and comprehensive spec. That is why we used used the term prerequisite. So I see two ways forward that hang together: 1. draft-bradner-restore-proposed + (draft-housley-two-maturity-levels + independent interoperable implementations) 2. draft-loughney-newtrk-one-size-fits-all-01 (i.e. simply abolish the second and third stages, and make interoperability reports optional) I prefer #1. So do I. But we agree that, absent the commitment to interoperability testing as a critical part of the standards process -- the one thing we claimed for years was what made IETF work almost unique and almost uniquely successful among SDO-- there is little value in having a multiple-step process. regards, john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
Mark Atwood m...@pobox.com wrote: This post would be much less confusing if you would name names, cite examples, and point fingers. No, it wouldn't. We don't need a flame-war over which features of which protocols would have to go away under a strict reading of RFC 2026 in order to advance. The point is clear enough: that features that find their way into Proposed Standards have constituencies, and that pulling them out is too painful for most WGs to tackle. [Martin Rex m...@sap.com wrote:] The reason why so many documents are at proposed is that they're often collections of bloat (limited-use features with an aggresive requirements level) from various interest groups that is not strictly necessary for a protocol to be useful, and sometimes used only by a minority. Thank you, Martin! This brings us closer to the actual problem. Normally, for progression from Proposed to Draft, - some of the MUSTs would have to be changed to SHOULDs, - some of the SHOULDs would have to be changed to MAYs, - some parts might better be moved to seperate, optional extensions documents I've been there, done that, got the T-shirt. Some pretty dreadful MUSTs remain because of constituencies. Consensus is reached only by exhaustion. Often we end up leaving stuff which can reasonably be called bloat (though that's not how I would describe it) because we can't reach agreement that we can patch-in a better way without recycling at Proposed. The whole process is exhausting. More often than not, folks give up. But the particular interest groups would rather have the document remain at Proposed than seeing any of the requirements level of those particular features they're interested in, to come out lowered, or see features removed from the base protocol and into a seperate extensions document. Remaining at Proposed just doesn't seem that bad after you've been through the wringer a few times. (It's not that people start out wanting to prevent progression; it's that consensus on needed changes is too hard to reach.) Add to this that chartering a WG to advance from Proposed to Draft never seems to happen (what AD would volunteer to endure this _again_?) and we have the wrangling which should be contained in a WG arising during IETF LastCall: few document authors will persist long enough. I refuse to argue how many levels there should be -- though I'd be happy to work within the old consensus for three. What needs work (assuming we aim for more than one) is how to get there from here! I have some ideas; but the time just doesn't seem ripe to discuss them. -- John Leslie j...@jlc.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
--On Thursday, January 27, 2011 09:41 +0200 Gonzalo Camarillo gonzalo.camari...@ericsson.com wrote: Hi, yes, I also agree the first one is the most important point and has not been addressed so far. If we want a system that works (and is used), it needs to include incentives to move from one level to the next one. I have discussed this issue with quite a few people. Some people claim that those incentives exist in some areas (e.g., public institutions preferring or requiring full standards in their RFQs) but, at least in the RAI area, the incentives are not there in the vast majority of cases. Gonzalo, Suppose we were to succeed in returning Proposed Standard to its intended purpose -- more or less a good rough sketch of a protocol, suitable for implementation and testing with the support of mailing list discussions -- and being completely clear about what that meant. I think the incentives to advance to a more complete specification that represented community consensus about its being implementable and probably useful would then be clear. That change clearly requires our being very clear internally that Proposed Standard is a lightweight spec with a lightweight approval process: if we can't get away from the mentality of you made me review this, so I have to find at least something to comment on and ask for changes in the various review teams and the IESG, I think it is pretty much hopeless and that draft-housley-two-maturity-levels will turn out to accomplish exactly nothing other than to eliminate whatever further specification refinement occurs in the few documents that now to to Full Standard. As long as we apply a very high bar to entry for Proposed Standard and insist that specifications at that level are perfectly good standards, there will rarely be an incentive to move to the second level, no matter what we call it and whether or not there is a third level. I think the change, and the incentives, might be reinforced by renaming Proposed to Rough Preliminary Specification or something else without Standard in its name, but that is a separate matter. best, john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
On 1/26/2011 7:29 PM, Scott O. Bradner wrote: 2/ I think the proposal must specifically deal with the 2026 IPR licence requirement in section 4.1.2 If patented or otherwise controlled technology is required for implementation, the separate implementations must also have resulted from separate exercise of the licensing process. The requirement can be dealt with by explicitly discarding it or by including it. But not mentioning the requirement does not make the issue go away. This requirement was, in theory, a way to keep the IETF/IESG out of the business of evaluating the fairness of licensing terms. I can remember only one time it came up (in an appeal) so getting rid of it may be fine - but don't make it look like it was just forgotten. Please note that this reply is only about Scott's friendly amendment for one added sentence to cover interoperability about IPR: +1 It's terse, relevant and seems pragmatic. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
On 01/27/2011 01:10, John C Klensin wrote: --On Thursday, January 27, 2011 09:41 +0200 Gonzalo Camarillo gonzalo.camari...@ericsson.com wrote: Hi, yes, I also agree the first one is the most important point and has not been addressed so far. If we want a system that works (and is used), it needs to include incentives to move from one level to the next one. I have discussed this issue with quite a few people. Some people claim that those incentives exist in some areas (e.g., public institutions preferring or requiring full standards in their RFQs) but, at least in the RAI area, the incentives are not there in the vast majority of cases. Gonzalo, Suppose we were to succeed in returning Proposed Standard to its intended purpose -- more or less a good rough sketch of a protocol, suitable for implementation and testing with the support of mailing list discussions -- and being completely clear about what that meant. I think the incentives to advance to a more complete specification that represented community consensus about its being implementable and probably useful would then be clear. That change clearly requires our being very clear internally that Proposed Standard is a lightweight spec with a lightweight approval process: if we can't get away from the mentality of you made me review this, so I have to find at least something to comment on and ask for changes in the various review teams and the IESG, I think it is pretty much hopeless and that draft-housley-two-maturity-levels will turn out to accomplish exactly nothing other than to eliminate whatever further specification refinement occurs in the few documents that now to to Full Standard. As long as we apply a very high bar to entry for Proposed Standard and insist that specifications at that level are perfectly good standards, there will rarely be an incentive to move to the second level, no matter what we call it and whether or not there is a third level. I think the change, and the incentives, might be reinforced by renaming Proposed to Rough Preliminary Specification or something else without Standard in its name, but that is a separate matter. I've made this statement before, so I'll only touch on it briefly. The world outside the IETF does not understand the difference between our various flavors of RFC now. There is absolutely no hope of refining that understanding EXternally when we can't even follow it consistently INternally. To some extent I think Russ' draft accurately reflects the status quo, namely that drafts are the new proposed, and that proposed is the new deployed. I'm hesitant to provide full-throated support for the draft for a few reasons: 1. To the extent that anyone still cares that I once managed the IANA I don't want to appear to be trying to influence the IETF's processes. 2. As an IETF participant I haven't fully thought through all the ramifications of the draft. 3. As both an IETF participant and as a consumer of the standards we create I still believe (as I've said previously) that what we need is not an evolution, but a revolution; with different names for things that more accurately reflect their status and intended use. However, it's pretty obvious at this point that there is no broad support for this position, so I won't waste more time on it. hth, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
At 19:29 26-01-11, Scott O. Bradner wrote: 1/ I still do not think this (modified) proposal will have any real impact on the number of Proposed Standard documents that move to a (in this proposal, the) higher level since I do not see how this makes any significant changes to the underlying reasons that documents have not progressed in the past - i.e., I see no reason to think that this proposal would change the world much (would not help, would not hurt) If this draft is published, there may be more documents moving to the next level. There has been some comments about stated requirements for Proposed Standard being restored. It requires more than a BCP for that to happen. In Section 2: Reconsideration of the portions that were previously approved for publication as a Proposed Standard requires evidence that the unchanged features are causing harm to the Internet. I gather that there won't be any requirement for interoperability. That draft does not say which sections of RFC 2026 are being updated. As I do not have any IETF experience, I'll defer to what the elders of the IETF have to say about BCP 9 if it ever becomes subject to interpretation. :-) At 01:10 27-01-11, John C Klensin wrote: I think the change, and the incentives, might be reinforced by renaming Proposed to Rough Preliminary Specification or something else without Standard in its name, but that is a separate matter. The constituency has a lot of authors of documents which are at Proposed Standard. A name change will face strong resistance unless it is at least at par with the current gold standard. At 13:50 27-01-11, Doug Barton wrote: I've made this statement before, so I'll only touch on it briefly. The world outside the IETF does not understand the difference between our various flavors of RFC now. There As it is probably the consensus of the IETF that the world inside the IETF understands the difference, it is not worth arguing about. 3. As both an IETF participant and as a consumer of the standards we create I still believe (as I've said previously) that what we need is not an evolution, but a revolution; with different names for things that more accurately reflect their status and intended use. However, it's pretty obvious at this point that there is no broad support for this position, so I won't waste more time on it. A revolution is only possible if the world runs out of IPv4 addresses or if there is support from business constituency, whichever happens later. Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
Scott O. Bradner wrote: 1/ I still do not think this (modified) proposal will have any real impact on the number of Proposed Standard documents that move to a (in this proposal, the) higher level since I do not see how this makes any significant changes to the underlying reasons that documents have not progressed in the past - i.e., I see no reason to think that this proposal would change the world much (would not help, would not hurt) The reason why so many documents are at proposed is that they're often collections of bloat (limited-use features with an aggresive requirements level) from various interest groups that is not strictly necessary for a protocol to be useful, and sometimes used only by a minority. Normally, for progression from Proposed to Draft, - some of the MUSTs would have to be changed to SHOULDs, - some of the SHOULDs would have to be changed to MAYs, - some parts might better be moved to seperate, optional extensions documents But the particular interest groups would rather have the document remain at Proposed than seeing any of the requirements level of those particular features they're interested in, to come out lowered, or see features removed from the base protocol and into a seperate extensions document. This is one of the reasons why there is a constant stream of new authentication protocols. -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
This post would be much less confusing if you would name names, cite examples, and point fingers. The reason why so many documents are at proposed is that they're often collections of bloat (limited-use features with an aggresive requirements level) from various interest groups that is not strictly necessary for a protocol to be useful, and sometimes used only by a minority. Normally, for progression from Proposed to Draft, - some of the MUSTs would have to be changed to SHOULDs, - some of the SHOULDs would have to be changed to MAYs, - some parts might better be moved to seperate, optional extensions documents But the particular interest groups would rather have the document remain at Proposed than seeing any of the requirements level of those particular features they're interested in, to come out lowered, or see features removed from the base protocol and into a seperate extensions document. This is one of the reasons why there is a constant stream of new authentication protocols. -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
+1 to the proposed rules for reclassifying DS to IS. I think they offer a reasonable balance between expediency and quality. Ned On 1/24/2011 12:37 PM, Russ Housley wrote: draft-housley-two-maturity-levels-03 was just posted. ... Overall I find this spec to be an improvement over the previous version. Here are a few areas where improvements can be made. This phrase in Section 1: In addition, IETF working groups and IESG members providing much more scrutiny than is called for by RFC 2026 [1] prior to publication as Proposed Standard. is not a sentence. Should it be provide? Should it be have been providing? Something else? The sentence in Section 1 One desired outcome is to provide an environment where the IETF community is able to publish Proposed Standards as soon as rough consensus is achieved. and these sentences in Section 2.1: The intention of the two-tier maturity ladder is to restore the requirements for Proposed Standard from RFC 2026. No new requirements are introduced; no existing published requirements are relaxed. together lay out what is required for PS. Disregarding the other arguments over the word restore, these sentences are otherwise fine and dandy. But I think there needs to be further guidance provided to the IESG and Working Groups on how they should change their behavior. What is wrong with how the WGs and IESG are currently interpreting the rules of 2026 for PS? What current behaviors differ or have gone beyond what 2026 requires, and hence need to be changed to restore those requirements? Without such guidance, nothing changes. One major section that has been removed from the previous version of this I-D is what to do with documents currently in the Draft Standard status. I know that there was significant disagreement with the automatic reclassification to Internet Standard proposed before, with good reason. I'm going to letter the the rules in section 2.2 as follows. I'm also going to indicate how these sort of map into the old classifications: a) technical maturity (DS = FS) b) belief in significant benefit to Internet community (DS = FS) c) significant number of implementations with successful operational experience (DS = FS) d) no unresolved errata (PS = DS) e) no unused features that increases implementation complexity (PS = DS) Some people have argued that having a significant number of implementations (c) is sufficient to demonstrate both technical maturity (a) and the belief in benefit (b). The (d) and (e) requirements have already been demonstrated by virtue of those RFCs already being at DS status, although additional errata may have been filed against the DS. So I'm going to suggest that the following be applied to documents that are currently in Draft Standard status: Any protocol or service that is currently in Draft Standard status, without significant unresolved errata, may be reclassified as an Internet Standard as soon as it can be demonstrated to have a significant number of implementations with successful operational experience. This reclassification may be accomplished by filing a request with the IESG, detailing the Implementation and Operational Experience. After review, the IESG will hold an IETF-wide Last Call on the reclassification. If there is consensus for the reclassification, the RFC will be reclassified without being reissued. Protocols and services that have significant unresolved errata will need to be re-issued to resolve the errata before the above criteria can be applied. Of course, there is still an open question what it means to have a significant number, which will remain as subjective as it was before with the 2026 rules. Tony Hansen t...@att.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
1/ I still do not think this (modified) proposal will have any real impact on the number of Proposed Standard documents that move to a (in this proposal, the) higher level since I do not see how this makes any significant changes to the underlying reasons that documents have not progressed in the past - i.e., I see no reason to think that this proposal would change the world much (would not help, would not hurt) 2/ I think the proposal must specifically deal with the 2026 IPR licence requirement in section 4.1.2 If patented or otherwise controlled technology is required for implementation, the separate implementations must also have resulted from separate exercise of the licensing process. The requirement can be dealt with by explicitly discarding it or by including it. But not mentioning the requirement does not make the issue go away. This requirement was, in theory, a way to keep the IETF/IESG out of the business of evaluating the fairness of licensing terms. I can remember only one time it came up (in an appeal) so getting rid of it may be fine - but don't make it look like it was just forgotten. 3/ I think you also be quite specific as to how to decide that the conditions for advancement have been met - one of the big implementation issues with 2026 was knowing how to decide that a technology was ready to be advanced (did you need a spreadsheet listing all features and noting with ones had been multiply implemented (as was done at huge effort for HTTP 1.1) or is there someting simplier - clear rules would help avoid this type of issue in the future 4/ as part of #3 - the rules should also specifically deal with the following pp from 2026 The requirement for at least two independent and interoperable implementations applies to all of the options and features of the specification. In cases in which one or more options or features have not been demonstrated in at least two interoperable implementations, the specification may advance to the Draft Standard level only if those options or features are removed. this requirement was included to try to remove cruft from protocols as they went forward - maybe this is no longer a desire but, like with the license issue, a specific mention of what has been decided would mean that people would not think that things were not just forgotton. Scott ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
+1 on all points, especially the first one. john --On Wednesday, January 26, 2011 22:29 -0500 Scott O. Bradner s...@harvard.edu wrote: 1/ I still do not think this (modified) proposal will have any realimpact on the number of Proposed Standard documents that moveto a (in this proposal, the) higher level since I do not seehow this makes any significant changes to the underlying reasonsthat documents have not progressed in the past - i.e., I see noreason to think that this proposal would change the world much(would not help, would not hurt) 2/ I think the proposal must specifically deal with the 2026 IPR licencerequirement in section 4.1.2 If patented or otherwise controlled technology is required for implementation, the separate implementations must also have resulted from separate exercise of the licensing process. The requirement can be dealt with by explicitly discarding it or by including it. But not mentioning the requirement doesnot make the issue go away. This requirement was, in theory, away to keep the IETF/IESG out of the business of evaluatingthe fairness of licensing terms. I can remember onlyone time it came up (in an appeal) so getting rid of it maybe fine - but don't make it look like it was just forgotten. 3/ I think you also be quite specific as to how to decide that theconditions for advancement have been met - one of the bigimplementation issues with 2026 was knowing how to decidethat a technology was ready to be advanced (did you needa spreadsheet listing all features and noting with ones had been multiply implemented (as was done at huge effort for HTTP 1.1) or is there someting simplier - clear rules would help avoid this type of issue in the future 4/ as part of #3 - the rules should also specifically deal with the following pp from 2026 The requirement for at least two independent and interoperable implementations applies to all of the options and features of the specification. In cases in which one or more options or features have not been demonstrated in at least two interoperable implementations, the specification may advance to the Draft Standard level only if those options or features are removed. this requirement was included to try to remove cruft from protocolsas they went forward - maybe this is no longer a desire but,like with the license issue, a specific mention of what hasbeen decided would mean that people would not think thatthings were not just forgotton. Scott ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
Hi, yes, I also agree the first one is the most important point and has not been addressed so far. If we want a system that works (and is used), it needs to include incentives to move from one level to the next one. I have discussed this issue with quite a few people. Some people claim that those incentives exist in some areas (e.g., public institutions preferring or requiring full standards in their RFQs) but, at least in the RAI area, the incentives are not there in the vast majority of cases. Cheers, Gonzalo On 27/01/2011 9:28 AM, John C Klensin wrote: +1 on all points, especially the first one. john --On Wednesday, January 26, 2011 22:29 -0500 Scott O. Bradner s...@harvard.edu wrote: 1/ I still do not think this (modified) proposal will have any realimpact on the number of Proposed Standard documents that moveto a (in this proposal, the) higher level since I do not seehow this makes any significant changes to the underlying reasonsthat documents have not progressed in the past - i.e., I see noreason to think that this proposal would change the world much(would not help, would not hurt) 2/ I think the proposal must specifically deal with the 2026 IPR licencerequirement in section 4.1.2 If patented or otherwise controlled technology is required for implementation, the separate implementations must also have resulted from separate exercise of the licensing process. The requirement can be dealt with by explicitly discarding it or by including it. But not mentioning the requirement doesnot make the issue go away. This requirement was, in theory, away to keep the IETF/IESG out of the business of evaluatingthe fairness of licensing terms. I can remember onlyone time it came up (in an appeal) so getting rid of it maybe fine - but don't make it look like it was just forgotten. 3/ I think you also be quite specific as to how to decide that theconditions for advancement have been met - one of the bigimplementation issues with 2026 was knowing how to decidethat a technology was ready to be advanced (did you needa spreadsheet listing all features and noting with ones had been multiply implemented (as was done at huge effort for HTTP 1.1) or is there someting simplier - clear rules would help avoid this type of issue in the future 4/ as part of #3 - the rules should also specifically deal with the following pp from 2026 The requirement for at least two independent and interoperable implementations applies to all of the options and features of the specification. In cases in which one or more options or features have not been demonstrated in at least two interoperable implementations, the specification may advance to the Draft Standard level only if those options or features are removed. this requirement was included to try to remove cruft from protocolsas they went forward - maybe this is no longer a desire but,like with the license issue, a specific mention of what hasbeen decided would mean that people would not think thatthings were not just forgotton. Scott ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
draft-housley-two-maturity-levels-03 was just posted. It reflects much of the discussion on this thread over the last few months. In particular, it embraces the changes put forward in the recent proposal by Dave Crocker, Eric Burger, Peter Saint-Andre, and Spencer Dawkins. Please take a look at the revised document, and provide your thoughts. Russ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
On 1/24/11 10:37 AM, Russ Housley wrote: draft-housley-two-maturity-levels-03 was just posted. It reflects much of the discussion on this thread over the last few months. In particular, it embraces the changes put forward in the recent proposal by Dave Crocker, Eric Burger, Peter Saint-Andre, and Spencer Dawkins. Please take a look at the revised document, and provide your thoughts. Thanks, Russ. A few comments: 1. It's not clear to me if this is quite correct in the Introduction: Similarly, subsequent revisions to the documents ought to be easier to publish, whether the document is advancing on the maturity ladder or not. As discussion later in the I-D reveals, we don't want to make it easy for folks to publish subsequent revisions that are significant, we want to make it easy to publish adjustments based on implementation and deployment experience: Experience with a Proposed Standard often leads to revisions that clarify, modify, enhance, or remove features. See also: A specification may be, and indeed, is likely to be, revised as it advances from Proposed Standard to Internet Standard. When a revised specification is proposed for advancement to Internet Standard, the IESG shall determine the scope and significance of the changes to the specification, and, if necessary and appropriate, modify the recommended action. Minor revisions and the removal of unused features are expected, but a significant revision may require that the specification accumulate more experience at Proposed Standard before progressing. I suggest: Similarly, it ought to be easier to publish revisions that incorporate implementation and deployment experience, whether the document is advancing on the maturity ladder or not. 2. I found this statement to be strange: The intention of the two-tier maturity ladder is to restore the requirements for Proposed Standard from RFC 2026. Why restore? Have they been superseded or ignored? I suggest retain. 3. I think there is a word missing here: The rules that make references to documents at lower maturity levels are a major cause of stagnation in the advancement of documents. Perhaps The rules prohibiting references...? Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
It seems to me that this proposal strikes a good balance in making an effort to improve the situation regarding our document track. Regarding the particular clause: On 1/24/2011 1:30 PM, Peter Saint-Andre wrote: ... 2. I found this statement to be strange: The intention of the two-tier maturity ladder is to restore the requirements for Proposed Standard from RFC 2026. Why restore? Have they been superseded or ignored? I suggest retain. I think the use of the word restore is very important. Over the years, our informal requirements and our sense of what was needed for Proposed Standard have moved up noticeably. This reflected a number of factors, all of them driven as best I can tell by good intentions. Restoring the lower bar for PS is probably the most direct benefit this proposal can have on our work. Separately, the replacement of the requirement for verified interoperability with the assumption of interoperability based on wide deployment is an understandable compromise. I am not sure I like this change, but I can live with it, which is good enough. I do like the more relaxed wording on the removal of unused features. Yours, Joel M. Halpern ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
On 1/24/11 11:39 AM, Joel M. Halpern wrote: It seems to me that this proposal strikes a good balance in making an effort to improve the situation regarding our document track. Regarding the particular clause: On 1/24/2011 1:30 PM, Peter Saint-Andre wrote: ... 2. I found this statement to be strange: The intention of the two-tier maturity ladder is to restore the requirements for Proposed Standard from RFC 2026. Why restore? Have they been superseded or ignored? I suggest retain. I think the use of the word restore is very important. Over the years, our informal requirements and our sense of what was needed for Proposed Standard have moved up noticeably. This reflected a number of factors, all of them driven as best I can tell by good intentions. Restoring the lower bar for PS is probably the most direct benefit this proposal can have on our work. Aha: so restore operationally. That makes sense. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
On Mon, Jan 24, 2011 at 1:39 PM, Joel M. Halpern j...@joelhalpern.comwrote: It seems to me that this proposal strikes a good balance in making an effort to improve the situation regarding our document track. Regarding the particular clause: On 1/24/2011 1:30 PM, Peter Saint-Andre wrote: ... 2. I found this statement to be strange: The intention of the two-tier maturity ladder is to restore the requirements for Proposed Standard from RFC 2026. Why restore? Have they been superseded or ignored? I suggest retain. I think the use of the word restore is very important. Over the years, our informal requirements and our sense of what was needed for Proposed Standard have moved up noticeably. This reflected a number of factors, all of them driven as best I can tell by good intentions. Restoring the lower bar for PS is probably the most direct benefit this proposal can have on our work. I would like that to be possible, but I would settle for just being able to make Standard status feasible. One of the side effects of most drafts deadlocking at Proposed is that people don't want to let anything 'bad' go through and that often means something that people 'feel uncomfortable with'. -- Website: http://hallambaker.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
Earlier, Joel Halpern wrote: It seems to me that this proposal strikes a good balance in making an effort to improve the situation regarding our document track. Regarding the particular clause: On 1/24/2011 1:30 PM, Peter Saint-Andre wrote: ... 2. I found this statement to be strange: The intention of the two-tier maturity ladder is to restore the requirements for Proposed Standard from RFC 2026. Why restore? Have they been superseded or ignored? I suggest retain. I think the use of the word restore is very important. Over the years, our informal requirements and our sense of what was needed for Proposed Standard have moved up noticeably. This reflected a number of factors, all of them driven as best I can tell by good intentions. Restoring the lower bar for PS is probably the most direct benefit this proposal can have on our work. Separately, the replacement of the requirement for verified interoperability with the assumption of interoperability based on wide deployment is an understandable compromise. I am not sure I like this change, but I can live with it, which is good enough. I do like the more relaxed wording on the removal of unused features. +1 to Joel's comments. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
On 1/24/2011 12:37 PM, Russ Housley wrote: draft-housley-two-maturity-levels-03 was just posted. ... Overall I find this spec to be an improvement over the previous version. Here are a few areas where improvements can be made. This phrase in Section 1: In addition, IETF working groups and IESG members providing much more scrutiny than is called for by RFC 2026 [1] prior to publication as Proposed Standard. is not a sentence. Should it be provide? Should it be have been providing? Something else? The sentence in Section 1 One desired outcome is to provide an environment where the IETF community is able to publish Proposed Standards as soon as rough consensus is achieved. and these sentences in Section 2.1: The intention of the two-tier maturity ladder is to restore the requirements for Proposed Standard from RFC 2026. No new requirements are introduced; no existing published requirements are relaxed. together lay out what is required for PS. Disregarding the other arguments over the word restore, these sentences are otherwise fine and dandy. But I think there needs to be further guidance provided to the IESG and Working Groups on how they should change their behavior. What is wrong with how the WGs and IESG are currently interpreting the rules of 2026 for PS? What current behaviors differ or have gone beyond what 2026 requires, and hence need to be changed to restore those requirements? Without such guidance, nothing changes. One major section that has been removed from the previous version of this I-D is what to do with documents currently in the Draft Standard status. I know that there was significant disagreement with the automatic reclassification to Internet Standard proposed before, with good reason. I'm going to letter the the rules in section 2.2 as follows. I'm also going to indicate how these sort of map into the old classifications: a) technical maturity (DS = FS) b) belief in significant benefit to Internet community (DS = FS) c) significant number of implementations with successful operational experience (DS = FS) d) no unresolved errata (PS = DS) e) no unused features that increases implementation complexity (PS = DS) Some people have argued that having a significant number of implementations (c) is sufficient to demonstrate both technical maturity (a) and the belief in benefit (b). The (d) and (e) requirements have already been demonstrated by virtue of those RFCs already being at DS status, although additional errata may have been filed against the DS. So I'm going to suggest that the following be applied to documents that are currently in Draft Standard status: Any protocol or service that is currently in Draft Standard status, without significant unresolved errata, may be reclassified as an Internet Standard as soon as it can be demonstrated to have a significant number of implementations with successful operational experience. This reclassification may be accomplished by filing a request with the IESG, detailing the Implementation and Operational Experience. After review, the IESG will hold an IETF-wide Last Call on the reclassification. If there is consensus for the reclassification, the RFC will be reclassified without being reissued. Protocols and services that have significant unresolved errata will need to be re-issued to resolve the errata before the above criteria can be applied. Of course, there is still an open question what it means to have a significant number, which will remain as subjective as it was before with the 2026 rules. Tony Hansen t...@att.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
25.01.2011 6:13, Tony Hansen wrote: On 1/24/2011 12:37 PM, Russ Housley wrote: draft-housley-two-maturity-levels-03 was just posted. ... Overall I find this spec to be an improvement over the previous version. Here are a few areas where improvements can be made. [. . . . .] One major section that has been removed from the previous version of this I-D is what to do with documents currently in the Draft Standard status. I know that there was significant disagreement with the automatic reclassification to Internet Standard proposed before, with good reason. I'm going to letter the the rules in section 2.2 as follows. I'm also going to indicate how these sort of map into the old classifications: a) technical maturity (DS = FS) b) belief in significant benefit to Internet community (DS = FS) c) significant number of implementations with successful operational experience (DS = FS) d) no unresolved errata (PS = DS) e) no unused features that increases implementation complexity (PS = DS) Some people have argued that having a significant number of implementations (c) is sufficient to demonstrate both technical maturity (a) and the belief in benefit (b). The (d) and (e) requirements have already been demonstrated by virtue of those RFCs already being at DS status, although additional errata may have been filed against the DS. So I'm going to suggest that the following be applied to documents that are currently in Draft Standard status: Any protocol or service that is currently in Draft Standard status, without significant unresolved errata, may be reclassified as an Internet Standard as soon as it can be demonstrated to have a significant number of implementations with successful operational experience. This reclassification may be accomplished by filing a request with the IESG, detailing the Implementation and Operational Experience. After review, the IESG will hold an IETF-wide Last Call on the reclassification. If there is consensus for the reclassification, the RFC will be reclassified without being reissued. Protocols and services that have significant unresolved errata will need to be re-issued to resolve the errata before the above criteria can be applied. Of course, there is still an open question what it means to have a significant number, which will remain as subjective as it was before with the 2026 rules. Russ, Tony, all, I think that Section 5, regarding STD numbers, does not fully introduce the topic and is not acceptable. So I'd like to propose the following solution: the STD numbers are splitted into two groups: STD P-xxx and STD F-xxx, for proposed and full standards and assigned to all Standards-Track document once they move to one of these levels. The number must then be the same for P- and F- groups, with one of them reserved while the doc is in the other level. I.e. the doc is PS - STD F-xxx is reserved and vice versa. This, IMO, will resolve the problem with STD numbers. As for the issue with Draft Standards, I find that Tony proposed acceptable. But we should mention that if reclassification to FS did not gain the consensus, the spec. is reclassified to Proposed Standard. All the best, Mykyta Yevstifeyev Tony Hansen t...@att.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Alternate entry document model (was: Re: IETF processes (was Re: draft-housley-two-maturity-levels))
At 13:39 29-10-10, Andrew Sullivan wrote: Supppse we actually have the following problems: 1. People think that it's too hard to get to PS. (Never mind the competing anecdotes. Let's just suppose this is true.) 2. People think that PS actually ought to mean Proposed and not Permanent. (i.e. people want a sort of immature-ish level for standards so that it's possible to build and deploy something interoperable without first proving that it will never need to change.) Some people view that level as an immature-ish level; some people may view it as a mature as they have overcome the barriers to publication. 4. Most of the world thinks RFC == Internet Standard. Yes. If all of those things are right and we're actually trying to solve them all, then it seems to me that the answer is indeed to move to _n_ maturity levels of RFC, where _n_ 3 (I propose 1), but that we introduce some new document series (call them TRFC, for Tentative Request For Comment, or whatever) that is the first step. Then we get past the thing that people are optimizing for (everything stays as Proposed Standard once it gets published) by simply eliminating that issue permanently. That's somewhat similar to the Working Group Snapshot proposal. Such proposals are mainly about addressing point 4. I don't think that this community would support having Proposed Standard renamed to Alleged Standard or that such a change is in accordance with the IETF's sense of humor. Ah, you say, but now things will stick at TRFC. Maybe. But we could on purpose make it easier to get TRFC than it is now to get PS (say, by adopting John's limited DISCUSS community for TRFC, or one of the other things discussed in this thread). Also, the argument about everyone thinking that RFCs are standard, and the resulting pressure to make them perfect and permanent, would be explicitly relieved (at least for a while), because nobody thinks that TRFCs are standards. The RFC brand worked too well. The people who have to decide on the issue are the same people who have authored documents which are currently at Proposed Standard level. At a different level, this is like asking the IETF to give up the RFC brand. Note that this is not to denigrate SM's suggestion, which also doesn't I view your comments as constructive criticism. seem wrong to me. But since one of the issues appears to be that anything called RFC is set in stone, then if we just stop calling the early-publication documents RFC that and introduce something after I-D (which is formally only on the _way_ to some consensus, and not actually the product of it), the blockage might be removed. People commented that there were not one issue but multiple issues. RFCs published in the IETF Stream differ from RFCs from other streams in one aspect; they go through the IETF Standards Process. I am over-simplying here. The label is also about archival of the consensus decision [1]. At 14:03 29-10-10, Martin Rex wrote: Essentially, you seem to be asserting that IETF community feedback should be considered harmful and delayed to much later in the process where it can have even less impact. I did not describe community feedback as harmful. I prefer not to provide an example here to avoid conflating this with matters that are subject to appeal. To me, that sound a little like giving up. Maybe. I doubt that the ideal solution would gain consensus. Anyway, what's ideal is subjective. Changing solutions, fixing protocols and fixing documents is exhausting and painful, so let's just skip all of that. Let vendors and implementors I agree that it can be exhausting and painful. But then there is a price to pay for getting free reviews. Authors who would like to have their protocols and documents fixed should realize that it cannot happen without effort on both sides. wiggle out how to create interoperable products from shoddy specs all by themselves -- which is what some of them have been doing for some time -- implementing defective specs and shipping interoperability- impaired products long before the standardization work has converged on a moderately stable Proposed Standard. We might call it shoddy specs; other view it as a matter of doing business. It works for me is a bad idea if we are concerned about interoperability and clarity. At 01:39 30-10-10, John C Klensin wrote: If that is true --and it may be-- it would indicate that not even we can keep track of the difference between RFC and Standard. If that were to be the case, discussion of maturity levels is basically a waste of time. Yes, and the end result could be giving up. I think there are other issues with your outline, but the key one is that it would really, really, depend on do or die working. If it didn't, the IETF would rapidly acquire a reputation for producing garbage as Standards, and that would be, IMO, really bad. Yes. But the
Re: Alternate entry document model (was: Re: IETF processes (was Re: draft-housley-two-maturity-levels))
A few quick observations... --On Friday, October 29, 2010 13:20 -0700 SM s...@resistor.net wrote: ... While my instinct is that RFC publication would be desirable, if that didn't seem workable we could move the idea a bit closer to the Snapshot idea by posting the document in the I-D series and giving it a gold star. It would be difficult to get buy-in if the document is not published as a RFC. If that is true --and it may be-- it would indicate that not even we can keep track of the difference between RFC and Standard. If that were to be the case, discussion of maturity levels is basically a waste of time. Instead of eliminating Proposed Standard, how about allowing the working group output document to be published as Proposed Standard? The approval could be done within the working group only but that might results in documents of questionable quality. If we take your idea of ... (v) Document goes into do or die track I think there are other issues with your outline, but the key one is that it would really, really, depend on do or die working. If it didn't, the IETF would rapidly acquire a reputation for producing garbage as Standards, and that would be, IMO, really bad. But the odds are against do or die. We've had that provision (automatic moves to Historic for Proposed (or Draft) Standards that are not advanced within a set period) for a very long time. Unlike the Proposed Standard criteria, which have gradually evolved to become more and more burdensome in practice, we have _never_ followed that rule as written and only once (the de-cruft spinoff from the NEWTRK WG) make a serious attempt to clean out documents no one cared about any more. I also suggest that the odds are against us, if only because the IESG will always have higher priorities than reviewing the status of documents no one cares about any more (either because they didn't get traction or because they got so much traction that they represent established practice that no one has motivation to update them). In addition, I'm cynical enough to believe that IESG members would hesitate to kill off documents that have a few supporters who might put a lot of effort into complaining to the Nomcom... at least without strong documented evidence of community support. Note that we have also made killing things hard: the idea that it takes putting together and publishing an RFC with details, justification, and all of the usual sections and boilerplate to move another RFC to Historic is a post-2026 innovation. I think it was caused by the above issues with the IESG deprecating things because it was obviously the Right Thing to Do. But, regardless of the causes, it means a lot of motivation is needed to kill (or deprecate) something rather than letting it languish. IMO, if we wanted do or die, we'd have to change that culture too. ... best, john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Alternate entry document model (was: Re: IETF processes (was Re: draft-housley-two-maturity-levels))
On Oct 29, 2010, at 10:39 PM, Andrew Sullivan wrote: If all of those things are right and we're actually trying to solve them all, then it seems to me that the answer is indeed to move to _n_ maturity levels of RFC, where _n_ 3 (I propose 1), but that we introduce some new document series (call them TRFC, for Tentative Request For Comment, or whatever) that is the first step. Then we get past the thing that people are optimizing for (everything stays as Proposed Standard once it gets published) by simply eliminating that issue permanently. Ah, you say, but now things will stick at TRFC. Maybe. But we could on purpose make it easier to get TRFC than it is now to get PS (say, by adopting John's limited DISCUSS community for TRFC, or one of the other things discussed in this thread). Also, the argument about everyone thinking that RFCs are standard, and the resulting pressure to make them perfect and permanent, would be explicitly relieved (at least for a while), because nobody thinks that TRFCs are standards. I know how you can get it to approve first: Don't take it to the IESG. Require approval only from the ADs for that area. And don't give them a name that makes them look like some slightly different kind of RFC. Call it blessed draft or something like that. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
