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
Alternate entry document model (was: Re: IETF processes (was Re: draft-housley-two-maturity-levels))
--On Thursday, October 28, 2010 14:15 -0400 RJ Atkinson rja.li...@gmail.com wrote: On 28 Oct 2010, at 13:29 , Dave CROCKER wrote: On 10/28/2010 9:22 AM, RJ Atkinson wrote: Most times it would be better if IETF WGs initially create an Experimental status RFC, possibly doing so quite rapidly, and then later revise that (based on at experience) and publish the revision on the IETF standards-track. 1. Getting /any/ RFC through the IETF process is very high overhead, including Experimental. I believe that publishing an Experimental RFC is visibly easier than publishing a standards-track RFC. While, based on the recent EAI experience, I think there is sometimes (not necessarily often) considerable advantage in going to Experimental first, I don't believe that there is any significant difference in the time or pain level associated with getting WG Experimental documents through the IESG as compared to Proposed Standard documents. There may be some, e.g., it is easier with an Experimental document to respond to DISCUSS: I don't think this can be implemented, nor that it will work as intended with that is what we are trying to find out and document, but I've only rarely seen that come up in a DISCUSS on either type of document. As Dave has tried to say in a variety of ways, these things just depend on the views of the responsible AD and the composition of the IESG -- generalizations are generally not possible other than that the mechanisms that produce slow and/or painful take a lot less IESG consensus than moving things along quickly. The situation might be quite different for non-IETF streams and possibly non-WG document streams. ... Shouldn't a standards process be able to sit down and do a standard, rather than iterate on experimental designs? The above seems to reflect a mis-reading of what I wrote. I merely suggested that often an IETF WG would find it more productive to go to Experimental RFC first, then later to the standards-track. There are a number of worked examples of this historically, going back some number of years. I provided a handful of recent or current examples. This suggestion is not in any way novel or strange. Indeed, I'm merely echoing the suggestions of other folks -- this is not an idea that I originated. I think this takes us immediately back to those fundamental questions of what problem we are trying to solve and why do we think it would make a difference. I still remember my very first task when I became Apps AD: I got to explain to a vendor that, by implementing and deploying something based on (IIR) a Proposed Standard, they had only themselves to blame for their deployed system being incompatible when the WG decided a particular feature was a bad idea and changed it. I don't think it would be possible for an AD to do that today: along with making it harder to get Proposed Standard, we have started to treat them as if they are cast in concrete (one can argue cause and effect either way). Personally, I continue to believe that the Internet would be better served by having a lot less difference between Proposed and Experimental, by changing things (back?) so that getting one or the other approved and published was really quick, and making our main standardization/ get the document exactly right / consensus level the second one.In that context, I think it would make less difference whether we had two levels or three (but I'm the guy who proposed replacing category-levels that are never quite right with narrative text what could be used to explain what we really thought about a spec and its maturity). But, if we are going to persist in treating Proposed as already refined specification to be implemented and deployed and in requiring a very high standard of documentation, specification, and agreement for Experimental, then it seems to me that the odds are good that trying to insert Experimental below Proposed would, in lots of cases, just push Proposed up (four levels?) and make things even slower. And that would, IMO, increase the justification for documents bearing a WG-only stamp of approval such as the snapshot I-D plan. I'm not a fan of that plan because I think we should fix Proposed, including reduce the time and trouble it takes to get a spec published as Proposed, but, if we really can't do that, then formal pre-approval by a WG seems like the right way to go. Strawman (consciously derived from the current procedures of another SDO who, oddly, modeled those procedures on what they thought we are doing a decade or two ago): Suppose we eliminate Proposed Standard, replacing it with IETF Area Specification or Preliminary Specification (there are probably better names) with the following properties: -- No known technical defects (the present criterion for Proposed) -- Review and approval only within the (single) area of origin, i.e., WG review and AD review and approval
Re: Alternate entry document model (was: Re: IETF processes (was Re: draft-housley-two-maturity-levels))
Hi John, This is a quick reply to your message. Please treat it as highly immature. At 11:23 29-10-10, John C Klensin wrote: Personally, I continue to believe that the Internet would be better served by having a lot less difference between Proposed and Experimental, by changing things (back?) so that getting one or the other approved and published was really quick, and making our main standardization/ get the document exactly right / consensus level the second one.In that context, I think it would make less difference whether we had two levels or three (but I'm the guy who proposed replacing category-levels that are never quite right with narrative text what could be used to explain what we really thought about a spec and its maturity). Keith posted some comments about document quality. The ideas are good but implementing them will create more work. It might be possible to combine the ideas with other proposals to come up with a workable alternative. I don't know whether Keith will find a dilution of the ideas acceptable. But, if we are going to persist in treating Proposed as already refined specification to be implemented and deployed and in requiring a very high standard of documentation, specification, and agreement for Experimental, then it seems to me that the odds are good that trying to insert Experimental below Proposed would, in lots of cases, just push Proposed up (four levels?) and make things even slower. Agreed. And that would, IMO, increase the justification for documents bearing a WG-only stamp of approval such as the snapshot I-D plan. I'm not a fan of that plan because I think we should fix Proposed, including reduce the time and trouble it takes to get a spec published as Proposed, but, if we really can't do that, then formal pre-approval by a WG seems like the right way to go. Strawman (consciously derived from the current procedures of another SDO who, oddly, modeled those procedures on what they thought we are doing a decade or two ago): Suppose we eliminate Proposed Standard, replacing it with IETF Area Specification or Preliminary Specification (there are probably better names) with the following properties: -- No known technical defects (the present criterion for Proposed) -- Review and approval only within the (single) area of origin, i.e., WG review and AD review and approval (with whatever addition input the AD wanted to ask for, as now), but no IESG approval process at all. -- Published as RFCs, but clearly labeled as preliminary, possibly incomplete and not a standard. I wouldn't expect that to do much good, especially if someone were inclined to distort the situation for marketing reasons, but we can and should try. -- Instructions to the RFC Editor to favor speed of publication and basic comprehensibility over getting the text just right. Presumably this gets things through the IESG faster, if only because the number of people who can launch a formal DISCUSS is reduced to two from 15. It would also reduce IESG workload on documents that really are preliminary somewhat which, IMO, would be A Good Thing. 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. 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 having an area review instead, some problems which a working group might ignore would be caught. It would also look better for labelling purposes. There will be technical defects and architecturally unsound proposals coming out of this.For those who might say that it is unacceptable, I might point out that there it is already the case. It could work as follows: (i) Working Group Last Call (ii) Area-wide Last Call - This is for the document to get more exposure (iii) AD review of comments and document (iv) Document published as Proposed Standard with text saying that it represents the consensus of Area X and does not represent IETF consensus (v) Document goes into do or die track (vi) Working Group writes a revised proposal (vii) Last Call and IESG evaluation (ix) Document published as Draft Standard. It represents the consensus of the IETF and benefits from IETF-wide review (x) Deployment report required for document to be moved to Internet Standard (I am not getting into what the report should be about to keep this short). The above can also be used for
Re: Alternate entry document model (was: Re: IETF processes (was Re: draft-housley-two-maturity-levels))
On Fri, Oct 29, 2010 at 01:20:23PM -0700, SM wrote: It would be difficult to get buy-in if the document is not published as a RFC. 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.) 3. We want things to move along and be Internet STANDARDs. 4. Most of the world thinks RFC == Internet Standard. 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. Note that this is not to denigrate SM's suggestion, which also doesn't 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. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ 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))
Andrew == Andrew Sullivan a...@shinkuro.com writes: Andrew On Fri, Oct 29, 2010 at 01:20:23PM -0700, SM wrote: It would be difficult to get buy-in if the document is not published as a RFC. Andrew Supppse we actually have the following problems: Andrew 1. People think that it's too hard to get to PS. Andrew (Never mind the competing anecdotes. Let's just suppose Andrew this is true.) Andrew 2. People think that PS actually ought to mean Andrew Proposed and not Permanent. (i.e. people want a sort of Andrew immature-ish level for standards so that it's possible to Andrew build and deploy something interoperable without first Andrew proving that it will never need to change.) Andrew 3. We want things to move along and be Internet Andrew STANDARDs. Andrew 4. Most of the world thinks RFC == Internet Andrew Standard. Andrew If all of those things are right and we're actually trying Andrew to solve them all, then it seems to me that the answer is Andrew indeed to move to _n_ maturity levels of RFC, where _n_ 3 Andrew (I propose 1), but that we introduce some new document Andrew series (call them TRFC, for Tentative Request For Comment, Andrew or whatever) that is the first step. Then we get past the Andrew thing that people are optimizing for (everything stays as Andrew Proposed Standard once it gets published) by simply Andrew eliminating that issue permanently. I think this is a workable idea. But, instead of calling things TRFC, let's do something less glamorous and give it hash... maybe based upon the sha1 of the document or something. TRFC-ipsec-4d66-1618-00bbd99b.txt :-) -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[ ] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video http://www.youtube.com/watch?v=kzx1ycLXQSE then sign the petition. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
