Re: Last Call: draft-housley-two-maturity-levels-06.txt (Reducing the Standards Track to Two Maturity Levels) to BCP
On 2011-06-11 06:36, Mykyta Yevstifeyev wrote: ... whereas you propose making I-Ds almost Standards Track. As it was discussed before, there is an evidence of leaving PSs without any action/progress; introducing Stable Snapshots there might occur Stable Snapshots left without any action, like PSs. But PSs are RFCs at least and I-Ds are nothing-as-per-2026. Adopting this proposal might result in implementators claiming we implement Stable Snapshot of the Internet-Draft, which is unacceptable, IMO. ... Out of curiosity: why do you find that unacceptable? It's *good* when the stuff in IDs gets implemented, and it's also good if there's clear information *which* draft is implemented. What can be problematic is when products are *released* with this kind of implementation. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-two-maturity-levels-06.txt (Reducing the Standards Track to Two Maturity Levels) to BCP
11.06.2011 10:59, Julian Reschke wrote: On 2011-06-11 06:36, Mykyta Yevstifeyev wrote: ... whereas you propose making I-Ds almost Standards Track. As it was discussed before, there is an evidence of leaving PSs without any action/progress; introducing Stable Snapshots there might occur Stable Snapshots left without any action, like PSs. But PSs are RFCs at least and I-Ds are nothing-as-per-2026. Adopting this proposal might result in implementators claiming we implement Stable Snapshot of the Internet-Draft, which is unacceptable, IMO. ... Out of curiosity: why do you find that unacceptable? It's *good* when the stuff in IDs gets implemented, and it's also good if there's clear information *which* draft is implemented. What can be problematic is when products are *released* with this kind of implementation. Under-development implementation is doubtlessly useful. Above under implementing I meant final implementation, incorporating some technology in the final product. Introducing Stable Snaps is very likely to make such cases more frequent, as they will be made almost equal to RFCs. Mykyta Yevstifeyev Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-two-maturity-levels-06.txt (Reducing the Standards Track to Two Maturity Levels) to BCP
08.06.2011 10:58, Dave Cridland wrote: On Wed Jun 8 05:57:15 2011, Pete Resnick wrote: On 6/7/11 11:00 PM, Peter Saint-Andre wrote: And, more to the point I think, to greatly decrease the quality of RFCs published. Perhaps that's OK, but we need pretty strong consensus that it's the right thing to do, and I haven't seen that consensus in the Last Call discussion. All of the above may be true. I personally think that the best thing that could happen in some sense is to decrease the quality of Proposed Standard RFCs, but that's certainly a controversial view. And I think it's worthy of an independent discussion. So, at the very least, we either need to agree on this as a topic for this document or remove it. [ . . . ] The best proposal I've seen - and I'd note that I can't recall now if this is Keith Moore's or Scott Bradner's, to my shame - is that of marking up specific I-D documents as being a Stable Snapshot. To my mind, this will override the basic rule of RFC 2026: * * * Under no circumstances should an Internet-Draft* * be referenced by any paper, report, or Request-* * for-Proposal, nor should a vendor claim compliance * * with an Internet-Draft.* * * whereas you propose making I-Ds almost Standards Track. As it was discussed before, there is an evidence of leaving PSs without any action/progress; introducing Stable Snapshots there might occur Stable Snapshots left without any action, like PSs. But PSs are RFCs at least and I-Ds are nothing-as-per-2026. Adopting this proposal might result in implementators claiming we implement Stable Snapshot of the Internet-Draft, which is unacceptable, IMO. Mykyta Yevstifeyev This proposal seems to have the following benefits: a) It satisfies the two paragraphs above in a non-conflicting manner. That is, it provides everything that RFC 2026's PS was intended to without being an RFC, with all that that moniker currently implies. b) It's fairly obvious, in my view, how to start to use the new grade, and how we might adapt to it in a smooth manner. Working Groups, authors, etc would be able to start to use it in a fairly ad-hoc manner, without the kinds of flag day changes to process that two-maturity-levels seems to imply. So if anyone has the patience for another I-D thrown into the soup, I'm willing to [re]write this one up, assuming the original instigator[s] of the proposal don't wish to. Dave. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-two-maturity-levels-06.txt (Reducing the Standards Track to Two Maturity Levels) to BCP
On Wed Jun 8 05:57:15 2011, Pete Resnick wrote: On 6/7/11 11:00 PM, Peter Saint-Andre wrote: And, more to the point I think, to greatly decrease the quality of RFCs published. Perhaps that's OK, but we need pretty strong consensus that it's the right thing to do, and I haven't seen that consensus in the Last Call discussion. All of the above may be true. I personally think that the best thing that could happen in some sense is to decrease the quality of Proposed Standard RFCs, but that's certainly a controversial view. And I think it's worthy of an independent discussion. So, at the very least, we either need to agree on this as a topic for this document or remove it. Just to throw in my tuppence, once more: I'm entirely in favour of there being a cheaper, rougher, lower-quality grade of specification; I think this should be what Proposed Standard was originally intended to be; I think there is a pressing need for a specification grade to fill this niche within the IETF. In this, I think I'm in agreement with Pete. I am very much against trying to redefine - and at this stage it is a de jure redefinition, as it were - Proposed Standard *or any other RFC grade* to fill this gap. I think customer expectation of the RFC series is now for a much higher quality than RFC 2026 envisaged, and the net result of regrading PS would be that of lowering the quality of the specifications used in the field. In this, I think I'm in agreement with Peter. The best proposal I've seen - and I'd note that I can't recall now if this is Keith Moore's or Scott Bradner's, to my shame - is that of marking up specific I-D documents as being a Stable Snapshot. This proposal seems to have the following benefits: a) It satisfies the two paragraphs above in a non-conflicting manner. That is, it provides everything that RFC 2026's PS was intended to without being an RFC, with all that that moniker currently implies. b) It's fairly obvious, in my view, how to start to use the new grade, and how we might adapt to it in a smooth manner. Working Groups, authors, etc would be able to start to use it in a fairly ad-hoc manner, without the kinds of flag day changes to process that two-maturity-levels seems to imply. So if anyone has the patience for another I-D thrown into the soup, I'm willing to [re]write this one up, assuming the original instigator[s] of the proposal don't wish to. 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: Last Call: draft-housley-two-maturity-levels-06.txt (Reducing the Standards Track to Two Maturity Levels) to BCP
Pete, thanks for your helpful summary. Comments inline, now that I've had a chance to review all of the Last Call feedback. On 5/30/11 5:20 PM, Pete Resnick wrote: On 5/5/11 11:13 AM, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Reducing the Standards Track to Two Maturity Levels' draft-housley-two-maturity-levels-06.txt as a BCP The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-06-02. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Man without hat: Speaking as an individual contributor, not an AD. Ditto. Summary: I am in favor of most of the changes in this document. The primary change I am opposed to is the one identified in the title and therefore object the adoption of this document as a BCP. However, I believe there is a single (though significant) change that would make the document acceptable to me. My summary: I am in favor of many of the changes in this document, although what you and I like and dislike does not overlap much. :| Details: The document says in section 1 that the motivation for the changes is: In the current environment, many documents are published as Proposed Standard and never advance to a higher maturity level. I think that's fine and usually appropriate. In addition, IETF working groups and IESG members provide much more scrutiny than is called for by RFC 2026 [1] prior to publication as Proposed Standard. Although this is adduced as a motivation, by my reading it doesn't actually motivate the proposals in this document. I certainly agree with addressing the above concerns. I'm not yet convinced that these are real problems. Section 2 lists one additional motivation for the changes: The benefit associated with a third maturity level has proven insufficient to justify the effort associated with document progression. I'll address this below. I think the third maturity level is unnecessary, but I'm not yet convinced that we understand what results we're trying to achieve and what behaviors we're trying to encourage by modifying the standards track. Here is a summary of the process changes that occur in the document, by section: Section 2 (a) Generally, go to two maturity levels, Proposed Standard and Internet Standard (b) Only review the changes, not the entire document, when recycled at Proposed Section 2.1 (a) Go back to 2026 level of (i.e., less) scrutiny for Proposed Standard Section 2.2 (a) Specifically, merge Draft Standard into Internet Standard (b) Combine criteria from Draft Standard and Standard (i) Significant number of implementations with successful operational experience (ii) No unresolved errata causing interoperational problems (iii) No unused features, except allow unused features that do not greatly increase implementation complexity (iv) Independent patent/licensing for implementations (c) Remove overt requirement for documentation of interoperability testing Section 3 (a) No more annual review of Proposed Standards for movement to Historic Section 4 (a) Allow normative references from Internet Standards to Proposed Standards (Editorial note: Please move 2(b) into 2.1. That change is a change to the handling of Proposed Standards and therefore belongs in 2.1. That makes the rest of Section 2 just introductory text and not making a specific procedural change.) My analysis by section: 2(a) - I am opposed to this change and will discuss it below in section 2.2(a). I am in favor of this change. 2(b) - I like this change and support it. I'm mostly agnostic about this, although I note that sometimes things change (e.g., new security threats) and it makes sense to revisit parts of a document even if they haven't been changed (or, in some instances, especially if they haven't been changed). 2.1(a) - I wholeheartedly agree with this change (or, more to the point, reversion to the documented way of doing things). I disagree with this change. It sounds attractive (let's return to the golden age) but I agree with those who posted during the Last Call that it is a significant change from current practice. You could argue that current practice is not the best practice, but I don't see how a reversion to RFC 2026 principles here is truly best current practice. In addition, IMHO we have not thought enough about the consequences of a lower bar for Proposed Standard (e.g., our customers think that an RFC is an RFC, and if we suddenly start publishing PS specs of lesser quality then we might be diluting our brand). However: - This document gives no mechanism to facilitate this change. I would like to hear how this
Re: Last Call: draft-housley-two-maturity-levels-06.txt (Reducing the Standards Track to Two Maturity Levels) to BCP
On 6/7/11 11:00 PM, Peter Saint-Andre wrote: Pete, thanks for your helpful summary. Comments inline, now that I've had a chance to review all of the Last Call feedback. A conversation I'm happy to have. Comments inline. We are still men without hats. On 5/30/11 5:20 PM, Pete Resnick wrote: Details: The document says in section 1 that the motivation for the changes is: In the current environment, many documents are published as Proposed Standard and never advance to a higher maturity level. I think that's fine and usually appropriate. So you think that this is *not* a motivation for the changes and is *not* something we need to change? Interesting. In addition, IETF working groups and IESG members provide much more scrutiny than is called for by RFC 2026 [1] prior to publication as Proposed Standard. Although this is adduced as a motivation, by my reading it doesn't actually motivate the proposals in this document. We agree on that point. I certainly agree with addressing the above concerns. I'm not yet convinced that these are real problems. This we're likely to agree to disagree on. Section 2 lists one additional motivation for the changes: The benefit associated with a third maturity level has proven insufficient to justify the effort associated with document progression. I'll address this below. I think the third maturity level is unnecessary, but I'm not yet convinced that we understand what results we're trying to achieve and what behaviors we're trying to encourage by modifying the standards track. Strongly agreed on the latter point: I'm not at all convinced that we understand what results we're trying to achieve and what behaviors we're trying to encourage by modifying the standards track. And given that, whatever change we end up making, I have to say that this document can't be it, because it does not explain what we're trying to achieve. Skipping down to going back to 2026 requirements for proposed: I disagree with this change. It sounds attractive (let's return to the golden age) but I agree with those who posted during the Last Call that it is a significant change from current practice. You could argue that current practice is not the best practice, but I don't see how a reversion to RFC 2026 principles here is truly best current practice. In addition, IMHO we have not thought enough about the consequences of a lower bar for Proposed Standard (e.g., our customers think that an RFC is an RFC, and if we suddenly start publishing PS specs of lesser quality then we might be diluting our brand). However: - This document gives no mechanism to facilitate this change. I would like to hear how this will be accomplished. I have my doubts that this is even achievable now, at least absent serious changes to IETF culture and individual expectations among spec authors, WG chairs, Area Directors, review teams, and everyone else. - This change, along with 2(b) has the potential to greatly increase the number of RFCs published. The document does not discuss the impact of that. And, more to the point I think, to greatly decrease the quality of RFCs published. Perhaps that's OK, but we need pretty strong consensus that it's the right thing to do, and I haven't seen that consensus in the Last Call discussion. All of the above may be true. I personally think that the best thing that could happen in some sense is to decrease the quality of Proposed Standard RFCs, but that's certainly a controversial view. And I think it's worthy of an independent discussion. So, at the very least, we either need to agree on this as a topic for this document or remove it. As to the change to 2 levels: 2.2(a) - I see no motivation for this change other than the one sentence in section 2. This change does not address the difficulty of going from Proposed to Draft, and it doesn't address the heightened scrutiny for going to Proposed. Therefore, if the only reason for changing from three levels to two is that getting through the three levels is too hard, and most of the procedural changes in this document are to make it easier to get through the first two levels, I see no justification for removing the third (and in 2026, easiest to get through) level. It does not solve any identified problem. I'm in favor of this change. I don't think the document describes the motivation very well, but this one makes sense to me. As Thoreau said, simplify, simplify, simplify (although why did he need to say it three times?). Simplify (even three times) is not a good motivation for this change. If simplify, simplify, simplify means cut off your right arm, cut off your left arm, and cut off your left leg, I will certainly be a simpler being for the act, but none the better; I would argue a bit worse for my purposes. Simplify is not, in and of itself, a good justification.
Re: Last Call: draft-housley-two-maturity-levels-06.txt (Reducing the Standards Track to Two Maturity Levels) to BCP
On Tue, Jun 07, 2011 at 11:57:15PM -0500, Pete Resnick wrote: So you think that this is *not* a motivation for the changes and is *not* something we need to change? Interesting. For what it's worth, quite apart from thinking that the draft in question will do nothing to change the state of affairs with respect to advancement, I also wonder why anyone cares whether documents advance. If someone cares enough, documents will advance. Someone will do the work. For instance, apparently Scott Hollenbeck cared about the advancement of EPP. The Extensible Provisioning Protocol is a full Standard. Meanwhile, the protocol some EPP-using registries employ to update the contents of their DNS zone files (DNS Update, RFC 2136) is a Proposed Standard and has been since 1997. I assert that someone fooling with DNS dynamic update such that the protocol changed incompatably would have far more wide-ranging and deleterious consequences for the Internet than someone altering EPP in a backward-incompatible way. We have a hope of contacting all the EPP users on Earth, to begin with. (None of this is to denigrate EPP or the work that those who moved it along the standards track undertook. I think it is an excellent example of what to do and how to do it. It's just also a handy example of a well-defined protocol with a reasonably tightly packed user community, compared to some other protocols.) If the people who use and rely on a protocol don't care about this maturity-level advancement to do something about it, why should the rest of us care? A -- Andrew Sullivan a...@anvilwalrusden.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-two-maturity-levels-06.txt (Reducing the Standards Track to Two Maturity Levels) to BCP
Pete Resnick wrote: [...] Section 2.2 (a) Specifically, merge Draft Standard into Internet Standard (b) Combine criteria from Draft Standard and Standard (i) Significant number of implementations with successful operational experience (ii) No unresolved errata causing interoperational problems (iii) No unused features, except allow unused features that do not greatly increase implementation complexity (iv) Independent patent/licensing for implementations (c) Remove overt requirement for documentation of interoperability testing [...] 2.2(b)(i) - This is the current requirement for Internet Standard. I'm fine with that remaining, but object to the removal of any notion of interoperability. If this were changed to A significant number of interoperable implementations..., I would have no objection. +1. 2.2(b)(iii) - I would prefer that this be amended to All unused 'MUST' requirements will be changed to 'SHOULD' requirements. If deployment is interoperable and a feature is unused, it means that the feature was not actually REQUIRED for interoperability. I object to this as it stands. -1. If for a protocol X nobody implemented MUST implement security mechanism, I don't think I would like it to be downgraded to a SHOULD. At least not without a good explanation. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-two-maturity-levels-06.txt (Reducing the Standards Track to Two Maturity Levels) to BCP
For an outsider's feedback about John's comments (1), (4), and (5): On 31/May/11 18:23, John C Klensin wrote: This proposal is problematic in several ways. The first is obviously the most important, but the others suggest changes that might be useful whether or not that main provision is adopted. (1) Excessively-high requirements for Proposed Standard and dropping the three-level model. The document asserts, I believe correctly, that one of the problems with the IETF Standards Process is that the relatively low bar established for Proposed Standards in RFC 2026 has evolved into a very high bar and that we should return to that lower requirement level. Yet it effectively proposed to solve that problem by reducing the number of steps in the standards process to two. No evidence has been offered that whether or not the standards process is two levels or three has anything to do with difficulties completing Proposed Standards or getting them to a satisfactory level of completeness and correctness. The logic on that subject in the document appears to me to quite similar to a physician saying We agree there is a problem with your hand. We don't know how to treat it either surgically or medically, but we should do something, so let's amputate your foot. That really makes no sense and is probably bad for the patient (only probably... one really never knows). In addition, draft-housley-two-maturity-levels-06 does not discuss any mechanism for getting from the current as-practiced requirements for Proposed Standard back to the requirements of RFC 2026, a schedule for doing so, nor whether it is necessary to warn readers about the level of scrutiny applied (it may not be, but there has been little or no discussion of that subject in the IETF and there is no such discussion in the document). If this were a technical specification, unless there were an expectation that a transition will occur immediately and by magic, that omission would be a known defect. Suggestion: The level of completeness and quality required for a Proposed Standard, at least insofar as those requirements exceed the requirements in RFC 2026, are entirely in the hands of the IESG, relevant WGs, and the Last Call process. Whether those requirements can be reduced to the level required by 2026 has nothing to do with this document because there is no change to the 2026 requirements. While those considerations are entirely self-evident, I omit John's suggestions (i), (ii), and (iv) as they address an apparently different problem. In facts, on the requirements for Proposed Standard, the I-D says that they remain exactly as specified in RFC 2026, which seems to mean that the I-D is not attempting to alter their formal status in any way. I agree that the transition described in Section 5 is somewhat abrupt. It seems to me it would be smoother and more flexible to allow the new two-step ladder to coexist with the current three-step one, at least temporarily. That is to say, use add to rather than replace or change in the RFC Editor notes, and alter the last sentence in section 2 to read Minor revisions and the removal of unused features are expected, but a significant revision may require that the specification accumulate more experience at either Proposed Standard or Draft Standard before progressing. In John's word: (iii) The above implies that different areas, and perhaps even different WGs within an area, will end up with different practical requirements based, at least in part, on their perception of the risks implied by a less comprehensive document. I see that as an advantage and recognition of reality, not a problem. (4) Discussion of the STD document series in Section 6. It has been pointed out several times, in recent months to suppress discussion of proposals that might be alternates to some or all of this one, that there are many issues with how the IETF develops, approves, documents, and manages standards that are not addressed in this specification and that the community cannot reasonable expect to address all at the same time. The question of what should be done about the STD numbers is just one entry on this very long list. Examination of other IETF procedural RFCs indicates that we rarely, if ever, include a discussion of a single option that we have decided to _not_ pursue (even if only in the near term). The only apparent justification for including Section 6 in this draft is that there was a
Re: Last Call: draft-housley-two-maturity-levels-06.txt (Reducing the Standards Track to Two Maturity Levels) to BCP
On 5/30/11 7:39 PM, SM wrote: At 16:20 30-05-2011, Pete Resnick wrote: So, here is my a proposed alternative: 1. Make the changes in (A). We still need to say how to make that happen, and how to deal with the increased number of RFCs. The annual review provides an alternative to deal with the increased number of (non-historic) RFCs. A no substantive objection clause might enable the removal of drive-by RFCs. My concern was not the absolute number of RFCs. It is that, if we go back to something like 2026 criteria for Proposed, we should expect a bunch more revisions of RFCs (since we will find bugs that need to be fixed), and that may put an awful lot of pressure on the RFC Editor. Because the changes are likely to only be specific bug fixes and not total rewrites, perhaps the RFC Editor might be OK with only checking the new parts and not worrying about the old ones. But this is not addressed at all in the current document and needs to be. 2.2(b)(iii) - I would prefer that this be amended to All unused 'MUST' requirements will be changed to 'SHOULD' requirements. If deployment is interoperable and a feature is unused, it means that the feature was not actually REQUIRED for interoperability. I object to this as it stands. That's one way to deal with RFC 2119 creep. I'll go one step further. If there is a significant number of implementations that do not implement a SHOULD, the feature can be removed. The resulting specification might be easier to implement once the amount of requirements are reduced. This to me is wordsmithing. The current text says that you remove the ones that greatly increase implementation complexity. You're suggesting removing ones that might make it harder to implement. I think there's probably a happy median in there someplace. 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: Last Call: draft-housley-two-maturity-levels-06.txt (Reducing the Standards Track to Two Maturity Levels) to BCP
--On Thursday, May 05, 2011 09:13 -0700 The IESG iesg-secret...@ietf.org wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Reducing the Standards Track to Two Maturity Levels' draft-housley-two-maturity-levels-06.txt as a BCP The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-06-02. ... Hi. I made several comments about earlier versions of this document then stopped because, while the incremental versions have all included small improvements, they have addressed few of the basic issues and the document seemed to be riding something of a juggernaut. Because it is now in Last Call, I want to summarize and update those comments, in large measure because I don't want my near-silence since late January to be taken as agreement. This proposal is problematic in several ways. The first is obviously the most important, but the others suggest changes that might be useful whether or not that main provision is adopted. (1) Excessively-high requirements for Proposed Standard and dropping the three-level model. The document asserts, I believe correctly, that one of the problems with the IETF Standards Process is that the relatively low bar established for Proposed Standards in RFC 2026 has evolved into a very high bar and that we should return to that lower requirement level. Yet it effectively proposed to solve that problem by reducing the number of steps in the standards process to two. No evidence has been offered that whether or not the standards process is two levels or three has anything to do with difficulties completing Proposed Standards or getting them to a satisfactory level of completeness and correctness. The logic on that subject in the document appears to me to quite similar to a physician saying We agree there is a problem with your hand. We don't know how to treat it either surgically or medically, but we should do something, so let's amputate your foot. That really makes no sense and is probably bad for the patient (only probably... one really never knows). In addition, draft-housley-two-maturity-levels-06 does not discuss any mechanism for getting from the current as-practiced requirements for Proposed Standard back to the requirements of RFC 2026, a schedule for doing so, nor whether it is necessary to warn readers about the level of scrutiny applied (it may not be, but there has been little or no discussion of that subject in the IETF and there is no such discussion in the document). If this were a technical specification, unless there were an expectation that a transition will occur immediately and by magic, that omission would be a known defect. Suggestion: The level of completeness and quality required for a Proposed Standard, at least insofar as those requirements exceed the requirements in RFC 2026, are entirely in the hands of the IESG, relevant WGs, and the Last Call process. Whether those requirements can be reduced to the level required by 2026 has nothing to do with this document because there is no change to the 2026 requirements. If we are serious about making that change, I recommend that the IESG: (i) Put this document aside temporarily (ii) Announce to the community (presumably via an IESG statement) that, as a general matter, documents submitted for Proposed Standard will not be required to meet conditions beyond those imposed by 2026. Note that 2026 allows imposition of additional requirements, especially requirements for implementation experience. Whether a particular WG should strive for a higher quality standard for its documents should be treated as a management issue (e.g., it would rarely make sense to downgrade documents that were nearly finished at a higher level), but reviews on Last Call or from within the IESG that suggest a higher level of perfection should probably be ignored unless they provide reasoning for the greater requirement. (iii) The above implies that different areas, and perhaps even different WGs within an area, will end up with different practical requirements based, at least in part, on their perception of the risks
Re: Last Call: draft-housley-two-maturity-levels-06.txt (Reducing the Standards Track to Two Maturity Levels) to BCP
--On Tuesday, May 31, 2011 08:27 -0500 Pete Resnick presn...@qualcomm.com wrote: 1. Make the changes in (A). We still need to say how to make that happen, and how to deal with the increased number of RFCs. The annual review provides an alternative to deal with the increased number of (non-historic) RFCs. A no substantive objection clause might enable the removal of drive-by RFCs. My concern was not the absolute number of RFCs. It is that, if we go back to something like 2026 criteria for Proposed, we should expect a bunch more revisions of RFCs (since we will find bugs that need to be fixed), and that may put an awful lot of pressure on the RFC Editor. Because the changes are likely to only be specific bug fixes and not total rewrites, perhaps the RFC Editor might be OK with only checking the new parts and not worrying about the old ones. But this is not addressed at all in the current document and needs to be Concur. I do believe that, for Proposed Standards only, adopting a rule that only changes are examined when recycling in grade could reasonably be applied to the RFC Editor as well as IETF review. However, I think it is workable only if: -- There is some sort of exception procedure that can be applied when good sense requires it.For example, while our normal practice is that the editor of a spec is the editor of a revision of that spec, there are exceptions. The exceptions can involve sufficiently large changes in style that not editing the whole document could produce a result that is very hard to read and understand. -- Any sort of tolerate editorially-poor documents strategy, whether involving edit only changes as you suggest above, accept less-than-ideal writing style as long as the protocol intent is clear as suggested in my comments, or something else needs to have a clear point at which we apply a different set of expectations. I believe that ought to be the second level in the standards process (whatever that is called). However the line is drawn, I don't think we can have an expectation of high-quality finished documents, fast approval and publishing of Proposed Standards, and little editing work on documents going to the second level john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-two-maturity-levels-06.txt (Reducing the Standards Track to Two Maturity Levels) to BCP
On 5/5/11 11:13 AM, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Reducing the Standards Track to Two Maturity Levels' draft-housley-two-maturity-levels-06.txt as a BCP The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-06-02. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Man without hat: Speaking as an individual contributor, not an AD. Summary: I am in favor of most of the changes in this document. The primary change I am opposed to is the one identified in the title and therefore object the adoption of this document as a BCP. However, I believe there is a single (though significant) change that would make the document acceptable to me. Details: The document says in section 1 that the motivation for the changes is: In the current environment, many documents are published as Proposed Standard and never advance to a higher maturity level. In addition, IETF working groups and IESG members provide much more scrutiny than is called for by RFC 2026 [1] prior to publication as Proposed Standard. I certainly agree with addressing the above concerns. Section 2 lists one additional motivation for the changes: The benefit associated with a third maturity level has proven insufficient to justify the effort associated with document progression. I'll address this below. Here is a summary of the process changes that occur in the document, by section: Section 2 (a) Generally, go to two maturity levels, Proposed Standard and Internet Standard (b) Only review the changes, not the entire document, when recycled at Proposed Section 2.1 (a) Go back to 2026 level of (i.e., less) scrutiny for Proposed Standard Section 2.2 (a) Specifically, merge Draft Standard into Internet Standard (b) Combine criteria from Draft Standard and Standard (i) Significant number of implementations with successful operational experience (ii) No unresolved errata causing interoperational problems (iii) No unused features, except allow unused features that do not greatly increase implementation complexity (iv) Independent patent/licensing for implementations (c) Remove overt requirement for documentation of interoperability testing Section 3 (a) No more annual review of Proposed Standards for movement to Historic Section 4 (a) Allow normative references from Internet Standards to Proposed Standards (Editorial note: Please move 2(b) into 2.1. That change is a change to the handling of Proposed Standards and therefore belongs in 2.1. That makes the rest of Section 2 just introductory text and not making a specific procedural change.) My analysis by section: 2(a) - I am opposed to this change and will discuss it below in section 2.2(a). 2(b) - I like this change and support it. 2.1(a) - I wholeheartedly agree with this change (or, more to the point, reversion to the documented way of doing things). However: - This document gives no mechanism to facilitate this change. I would like to hear how this will be accomplished. - This change, along with 2(b) has the potential to greatly increase the number of RFCs published. The document does not discuss the impact of that. 2.2(a) - I see no motivation for this change other than the one sentence in section 2. This change does not address the difficulty of going from Proposed to Draft, and it doesn't address the heightened scrutiny for going to Proposed. Therefore, if the only reason for changing from three levels to two is that getting through the three levels is too hard, and most of the procedural changes in this document are to make it easier to get through the first two levels, I see no justification for removing the third (and in 2026, easiest to get through) level. It does not solve any identified problem. 2.2(b)(i) - This is the current requirement for Internet Standard. I'm fine with that remaining, but object to the removal of any notion of interoperability. If this were changed to A significant number of interoperable implementations..., I would have no objection. 2.2(b)(ii) - I have no objection to this new requirement, but have no strong feeling about it. 2.2(b)(iii) - I would prefer that this be amended to All unused 'MUST' requirements will be changed to 'SHOULD' requirements. If deployment is interoperable and a feature is unused, it means that the feature was not actually REQUIRED for interoperability. I object to this as it stands. 2.2(b)(iv) - This is the current requirement for Draft Standard. I'm fine with that remaining. 2.2(c) - If this is actually subsumed by 2.2(b)(i) (see my change above), then I am fine with this change. 3(a) - I have no objection to this
Re: capturing the intended standards level, Re: Last Call: draft-housley-two-maturity-levels-06.txt (Reducing the Standards Track to Two Maturity Levels) to BCP
Hi Julian, At 22:12 09-05-2011, Julian Reschke wrote: rfc2629.xslt allows specifying the intended maturity in the XML source...: http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#rfc.section.12.1.p.2 ...but it's only metadata in the XML source. Maybe we should add it to the ID boilerplate in the future? I'll ignore details such as authors running an ASCII version of their draft through Id-nits. Quoting Alexey: Sometimes references get reclassified during IESG review and this causes downrefs. The issue can occur at the IESG evaluation stage. With the new RFC Editor Model, it's unlikely to occur during AUTH48. If intended maturity is viewed as a mechanical issues and what you suggested fixes 80% of the problem, it may be worth a try. One could also argue that the IESG might see a value in having a reference reclassified (things you need to read to implement this specification). Instead of trying to capture the intended standards level, you could simply approve publication as Experimental. The author gets a RFC number. The IESG does not have to repeat the Last Call. Obviously, authors will lobby against that. :-) If you would like a glimpse of the outside world, read the thread at http://lists.cluenet.de/pipermail/ipv6-ops/2011-May/005514.html Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-two-maturity-levels-06.txt (Reducing the Standards Track to Two Maturity Levels) to BCP
SM: s much as I would like to use the IESG as a scapegoat, the reality is that IETF working groups also work briskly to on impediments. Section 4 mentions that the rules that prohibit references to documents at lower maturity levels are a major cause of stagnation in the advancement of documents. I beg to disagree. Quoting RFC 4897: With appropriate community review, the IESG may establish procedures for when normative downward references should delay a document and when downward references should be noted. There is an IESG statement [1] about that. I'll highlight the following sentence: Normative references specify documents that must be read to understand or implement the technology in the new RFC, or whose technology must be present for the technology in the new RFC to work. Quoting RFC 2026: Standards track specifications normally must not depend on other standards track specifications which are at a lower maturity level or on non standards track specifications other than referenced specifications from other standards bodies. Let's take a document moving to Draft Standard as an example. When we talk about down-ref, it is the maturity that is the issue. What it means, in my opinion, is that the referenced (normative) Proposed Standard can be changed in ways which affect the stability of the Draft Standard document. An implementation that is compliant with the Draft Standard may end up being incompliant overnight as the group that worked on the referenced Proposed Standard found some good reason for adding some requirements. Having down-refs on the No Fly list can be an impediment. By explicitly calling out the down-ref during a Last Call, the IETF offers a means to evaluate whether the document can live with the down-ref. I commented a week ago on the down-refs in RFC 5953 which is being advanced to Draft Standard. One of the down-refs could be fixed easily. Another one could be addressed with some rewording. Sometimes, such a change is not possible. In a distant future, the IETF community might come to terms with the notion that down-refs are not evil. My person experience with advancing documents is that downrefs are a significant hindrance. As you point out, procedures have been adopted to permit downrefs, but they are not sufficient. We often see Last Call repeated just to resolve a downref that was caught very late in the process. These intoduce delay, and they almost never produce a single comment from the community. Russ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-two-maturity-levels-06.txt (Reducing the Standards Track to Two Maturity Levels) to BCP
On 09.05.2011 16:34, Russ Housley wrote: ... My person experience with advancing documents is that downrefs are a significant hindrance. As you point out, procedures have been adopted to permit downrefs, but they are not sufficient. We often see Last Call repeated just to resolve a downref that was caught very late in the process. These intoduce delay, and they almost never produce a single comment from the community. ... Maybe we should find out why we actually ever start a LC with unexpected downrefs... I think we have at least two tools to check for those. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-two-maturity-levels-06.txt (Reducing the Standards Track to Two Maturity Levels) to BCP
Hi Julian, Julian Reschke wrote: On 09.05.2011 16:34, Russ Housley wrote: ... My person experience with advancing documents is that downrefs are a significant hindrance. As you point out, procedures have been adopted to permit downrefs, but they are not sufficient. We often see Last Call repeated just to resolve a downref that was caught very late in the process. These intoduce delay, and they almost never produce a single comment from the community. ... Maybe we should find out why we actually ever start a LC with unexpected downrefs... I think we have at least two tools to check for those. Sometimes references get reclassified during IESG review and this causes downrefs. I've certainly caused this several times. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-two-maturity-levels-06.txt (Reducing the Standards Track to Two Maturity Levels) to BCP
On 09.05.2011 18:10, Alexey Melnikov wrote: Hi Julian, Julian Reschke wrote: On 09.05.2011 16:34, Russ Housley wrote: ... My person experience with advancing documents is that downrefs are a significant hindrance. As you point out, procedures have been adopted to permit downrefs, but they are not sufficient. We often see Last Call repeated just to resolve a downref that was caught very late in the process. These intoduce delay, and they almost never produce a single comment from the community. ... Maybe we should find out why we actually ever start a LC with unexpected downrefs... I think we have at least two tools to check for those. Sometimes references get reclassified during IESG review and this causes downrefs. I've certainly caused this several times. Oh, informative - normative. Good point. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-two-maturity-levels-06.txt (Reducing the Standards Track to Two Maturity Levels) to BCP
Hi Russ, At 07:34 09-05-2011, Russ Housley wrote: My person experience with advancing documents is that downrefs are a significant Thanks for sharing that. hindrance. As you point out, procedures have been adopted to permit downrefs, but they are not sufficient. We often see Last Call repeated just to resolve a downref that was caught very late in the process. These intoduce delay, and they almost never produce a single comment from the community. This is an extract from the output of Id-nits for draft-ietf-yam-rfc1652bis-03: Checking references for intended status: Proposed Standard (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. For what it is worth, the draft was intended for publication as an Internet Standard (STD 71). As I see it, the problem here is that Intended status: Standards Track is assumed to be Proposed Standard. As the Document Shepherd runs a draft through Id-nits, he or she will not catch the above issue. It's unlikely that the IETF Secretariat will catch the issue. If down-refs are a process burden (Last Call has to be repeated) and the community does not see any value in having that restriction, the IETF could do any with it. I don't think that would be a good idea as it wipes out the notion of maturity levels. There are a lot of things that do not produce a single comment from the community. They are done for a reason. For example, there was a message about Draft Secretariat SOW for Community Comment. There has been only one comment on that. There is a cost to adhering to a standard of goodness. Once you do away with that, it is not as easy to get it back. Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
capturing the intended standards level, Re: Last Call: draft-housley-two-maturity-levels-06.txt (Reducing the Standards Track to Two Maturity Levels) to BCP
On 09.05.2011 19:07, SM wrote: ... For what it is worth, the draft was intended for publication as an Internet Standard (STD 71). As I see it, the problem here is that Intended status: Standards Track is assumed to be Proposed Standard. As the Document Shepherd runs a draft through Id-nits, he or she will not catch the above issue. It's unlikely that the IETF Secretariat will catch the issue. ... rfc2629.xslt allows specifying the intended maturity in the XML source...: http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#rfc.section.12.1.p.2 ...but it's only metadata in the XML source. Maybe we should add it to the ID boilerplate in the future? Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-two-maturity-levels-06.txt (Reducing the Standards Track to Two Maturity Levels) to BCP
At 09:13 05-05-2011, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Reducing the Standards Track to Two Maturity Levels' draft-housley-two-maturity-levels-06.txt as a BCP The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-06-02. Exceptionally, comments may be From Section 1: This document proposes several changes to the Internet Standards Process defined in RFC 2026 [1]. In recent years, the Internet Engineering Task Force (IETF) has witnessed difficulty in advancing documents through the maturity levels: Proposed Standard, Draft Standard, and finally Standard. These changes are designed to simplify the IETF Standards Process and reduce impediments to standards progression while preserving the most important benefits of the IETF engineering approach. There is a documented case where the difficulty occurred at the IESG level. I could not find anything in draft-housley-two-maturity-levels-06 to reduce that impediment. In addition, IETF working groups and IESG members provide much more scrutiny than is called for by RFC 2026 [1] prior to publication as Proposed Standard. As much as I would like to use the IESG as a scapegoat, the reality is that IETF working groups also work briskly to on impediments. Section 4 mentions that the rules that prohibit references to documents at lower maturity levels are a major cause of stagnation in the advancement of documents. I beg to disagree. Quoting RFC 4897: With appropriate community review, the IESG may establish procedures for when normative downward references should delay a document and when downward references should be noted. There is an IESG statement [1] about that. I'll highlight the following sentence: Normative references specify documents that must be read to understand or implement the technology in the new RFC, or whose technology must be present for the technology in the new RFC to work. Quoting RFC 2026: Standards track specifications normally must not depend on other standards track specifications which are at a lower maturity level or on non standards track specifications other than referenced specifications from other standards bodies. Let's take a document moving to Draft Standard as an example. When we talk about down-ref, it is the maturity that is the issue. What it means, in my opinion, is that the referenced (normative) Proposed Standard can be changed in ways which affect the stability of the Draft Standard document. An implementation that is compliant with the Draft Standard may end up being incompliant overnight as the group that worked on the referenced Proposed Standard found some good reason for adding some requirements. Having down-refs on the No Fly list can be an impediment. By explicitly calling out the down-ref during a Last Call, the IETF offers a means to evaluate whether the document can live with the down-ref. I commented a week ago on the down-refs in RFC 5953 which is being advanced to Draft Standard. One of the down-refs could be fixed easily. Another one could be addressed with some rewording. Sometimes, such a change is not possible. In a distant future, the IETF community might come to terms with the notion that down-refs are not evil. From Section 2: Note that the distinct requirement from RFC 2026 [1] for reports of interoperability testing among two or more independent implementations is intentionally subsumed by the requirement for actual deployment and use of independent and interoperable implementations. This draft conflates interoperability and deployment. Having a two-track level sounds reasonable at first glance. My garden variety protocol might qualify for Internet Standard now that wide-spread deployment has been watered down to actual deployment. From the same section: The Last Call is intended to identify unused portions of the specification that greatly increase implementation complexity without burdensome implementation testing and documentation. That sounds like a good idea. I would strongly support the removal of all the key words that are literally sprinkled in specifications nowadays. It is always a good idea to kill the pet peeve that you strong-armed the editor into adding through consensus by exhaustion. But identifying the unused portions of the specification tends to reopen old wounds. Going back to 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. That can mean reviewing how IESG evaluation is carried out. If you want to provide such an environment, one possible step is to remove DISCUSSes at Proposed Standard level
Re: Last Call: draft-housley-two-maturity-levels-06.txt (Reducing the Standards Track to Two Maturity Levels) to BCP
On 05 May 2011, at 12:13 , The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Reducing the Standards Track to Two Maturity Levels' draft-housley-two-maturity-levels-06.txt as a BCP The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Yes, please, and as soon as possible. This is very long overdue. Many thanks to Russ H for being patient and persistent on this topic. Yours, Ran Atkinson ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-two-maturity-levels-06.txt (Reducing the Standards Track to Two Maturity Levels) to BCP
On Thu May 5 23:47:50 2011, Dave CROCKER wrote: Folks, On 5/5/2011 11:33 AM, Scott O. Bradner wrote: As I have stated before, I do not think that this proposal will achieve anything useful since it will not change anything related to the underlying causes of few Proposed Standards advancing on the standards track. We currently have a standards process that largely ignores two of its stages. That's part of the story. It's not a complete observation, though. We have a standards process that is four stage, not three, and a first step should be to document what we're doing. That's how we work - we document running code. At the least, our community should be embarrassed about this cruft and should want to streamline things and make them more likely to be fully exercised. No. The minimum is that we should be embarrassed about the cruft. It is a trivial observation that we do not follow RFC 2026, and we should ensure that we have a standards process we actually follow. 1. The criteria for the second stage are significantly clarified and rely exclusively on actual adoption and use (again, modulo some important nuances.) Whatever happens with the practice of getting to Proposed, this should make it more predictable and easier to get to (Full) Internet Standard, based solely on actual success of the specification. More predictable is good. Easier? I'm not sure. But the real problem I have is the phrase hidden away in the above - Whatever happens with the practise of getting to Proposed. You're not seriously intending to put forward another document which defines our standards process yet not expecting anyone to follow it, are you? 2. The model is cleaned up, in my opinion significantly. This improves transparency of the process a bit. Also, I think Draft made sense when our whole endeavor was less mature and we needed to help the community understand what is needed for achieving interoperable deployments. Today we need the /practice/ of interop efforts, but we do not need it in the formal process, as demonstrated by how few specs get to Draft in spite of becoming entirely successful community services.[1] I'll go along with this one. 3. The changes are likely to remove bits of community confusion about the IETF standards labels. Not entirely of course, because people are creative. But the proposed changes make a very clean distinction between the initial technical work and the later adoption/deployment/use work. This one is hysterically funny. To quote from draft-bradner-ietf-stds-trk-00 (paraphrasing newtrk). 4/ there seems to be a reinforcing feedback loop involved: vendors implement and deploy PS documents so the IESG tries to make the PS documents better This is the core issue, which far from addressing, the proposal tries to discard the feedback loop, stick its fingers in its ears, and sing la-la-la-I'm-not-listening. The fact remains that vendors treat PS maturity RFCs as standards. By reverting to the letter of RFC 2026, this will undoubtedly increase confusion - indeed, it's apparent that much of the deviation from RFC 2026 has been related to this very confusion. 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: Last Call: draft-housley-two-maturity-levels-06.txt (Reducing the Standards Track to Two Maturity Levels) to BCP
Dave Cridland d...@cridland.net wrote: To quote from draft-bradner-ietf-stds-trk-00 (paraphrasing newtrk). 4/ there seems to be a reinforcing feedback loop involved: vendors implement and deploy PS documents so the IESG tries to make the PS documents better This is the core issue, which far from addressing, the proposal tries to discard the feedback loop, stick its fingers in its ears, and sing la-la-la-I'm-not-listening. Please excuse the hyperbole -- Dave's just trying to get our attention. The fact remains that vendors treat PS maturity RFCs as standards. By reverting to the letter of RFC 2026, this will undoubtedly increase confusion - indeed, it's apparent that much of the deviation from RFC 2026 has been related to this very confusion. Nothing we put in a rfc2026-bis will change this. Nothing we put in a rfc2026-bis _CAN_ change this. If we want to change this, we need to start putting warning-labels in the _individual_ RFCs that don't meet a ready for widespread deployment criterion. (I am speaking neither for nor against two-maturity-levels here: warning-labels need to happen if we expect to change implementors' expectations of PS RFCs.) -- John Leslie j...@jlc.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-two-maturity-levels-06.txt (Reducing the Standards Track to Two Maturity Levels) to BCP
Jari, and others, I support this draft with the caveat that we can establish a set of significant metrics that provide us an understanding as to the impact of the change. Eliot ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-two-maturity-levels-06.txt (Reducing the Standards Track to Two Maturity Levels) to BCP
On Fri May 6 11:44:48 2011, John Leslie wrote: Dave Cridland d...@cridland.net wrote: To quote from draft-bradner-ietf-stds-trk-00 (paraphrasing newtrk). 4/ there seems to be a reinforcing feedback loop involved: vendors implement and deploy PS documents so the IESG tries to make the PS documents better This is the core issue, which far from addressing, the proposal tries to discard the feedback loop, stick its fingers in its ears, and sing la-la-la-I'm-not-listening. Please excuse the hyperbole -- Dave's just trying to get our attention. I concede that the draft neither has fingers nor sings; the point remains valid however. The fact remains that vendors treat PS maturity RFCs as standards. By reverting to the letter of RFC 2026, this will undoubtedly increase confusion - indeed, it's apparent that much of the deviation from RFC 2026 has been related to this very confusion. Nothing we put in a rfc2026-bis will change this. Nothing we put in a rfc2026-bis _CAN_ change this. I'm in total agreement with this, which is why I'm so against a proposal which exacerbates the issue. If we want to change this, we need to start putting warning-labels in the _individual_ RFCs that don't meet a ready for widespread deployment criterion. I do not believe this will work, actually. In general, I think boilerplate warning messages get ignored - people quickly learn to expect and ignore them as routine - and I don't think we're likely to be able to construct unique and varying warning messages for every RFC we publish. 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: Last Call: draft-housley-two-maturity-levels-06.txt (Reducing the Standards Track to Two Maturity Levels) to BCP
As the sponsoring AD for Russ' draft, I'm very interested in hearing what everyone thinks about this. Please keep those comments coming! The last call was started as it was felt that discussion may have converged enough so that we could perhaps move forward with this proposal, or at least agree that its harmless and does not stand in the way of other improvements that some people may wish in addition. We'll see what the consensus will be. I can also see that some specific changes have already been discussed. Thanks for all those suggestions. But I also wanted to provide my own opinion. I would like to see the draft adopted. I personally do not believe that it will make a very significant change by itself; to a large extent the two (or even one) level model is already the running code. However, it does make the process a bit easier and it does allow us to get rid of at least some of the cruft from the IETF process. I think it is very important to simplify the process and align process documents with actual practice, as these will make it easier to describe, use, and evolve the IETF process. There are plenty of IETF process problems to address, even if this draft moves forward. Jari ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-two-maturity-levels-06.txt (Reducing the Standards Track to Two Maturity Levels) to BCP
Dave Cridland d...@cridland.net wrote: On Fri May 6 11:44:48 2011, John Leslie wrote: If we want to change this, we need to start putting warning-labels in the _individual_ RFCs that don't meet a ready for widespread deployment criterion. I do not believe this will work, actually. It is at least a step which _might_ work... In general, I think boilerplate warning messages get ignored - people quickly learn to expect and ignore them as routine - It's not fair to compare this to government-warnings on cigarette packs. However, I agree that if warning-labels look like boilerplate, folks will ignore them. and I don't think we're likely to be able to construct unique and varying warning messages for every RFC we publish. I offer as evidence the quite-limited warning-labels that the IESG may put on RFCs that are not IETF series RFCs. These happen routinely and seem to be accomplishing their intent. And, if I may speculate, we might consider warning-labels that refer readers to status pages maintained by area teams to show progress on issues not (yet) resolved at the time of publication. There _are_ things worthy of trying here. -- John Leslie j...@jlc.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-two-maturity-levels-06.txt (Reducing the Standards Track to Two Maturity Levels) to BCP
Ship it. We are way past the point of diminishing returns in polishing this. Regards Brian Carpenter ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-two-maturity-levels-06.txt (Reducing the Standards Track to Two Maturity Levels) to BCP
Hello again, Now as for the document itself. I really appreciate its purpose; encouraging Proposed-Standards-writers to advance their document replacing 3-tier system to 2-tier one is a good idea. However, in fact, this proposal in its current view really can't work effectively because of: Any protocol or service that is currently at the abandoned Draft Standard maturity level will retain that classification, absent explicit actions. In this case, as Brian Carpenter said during discussions of previous versions of this document, unless we have a firm sunset date, the job will never be finished and in fifty years there will still be DS documents. (http://www.ietf.org/mail-archive/web/ietf/current/msg65870.html) Considered this, removal of the sunset period is probably harmful; as nobody cared about progressing their DSs (see my previous message), they will continue to do this. Two possible actions are available: (1) A Draft Standard may be reclassified as an Internet Standard as soon as the criteria inSection 2.2 http://tools.ietf.org/html/draft-housley-two-maturity-levels-06#section-2.2 are satisfied. This [ . . . ] (2) At any time after two years from the approval of this document as a BCP, the IESG may choose to reclassify any Draft Standard document as Proposed Standard. A reasonable question: whether such action won't be available after 2 years? Anyway, leaving the situation with DSs as is won't result in something useful. As proposed before, 2-year sunset period is OK; if nobody undertakes any steps to advance their DS to FS during these 2 years, such DS is reclassified to PS. Another issue is removing the requirement for implementation reports. This must really result in low quality of FSs. As Bernold Adoba mentioned before, Today it is quite common within WGs to see conflicting claims about protocol implementations and interoperability. IMHO one of the critical purposes served by implementation reports is to require proponents to produce the evidence backing their claims. The above paragraph left me wondering what the burden of proof would be in practice. For example, I would not want to see the IESG put in the position of adjudicating he said, she said arguments made during Last Call. I fully agree with the last sentence; implementation reports serve as some documentary justification of existing of implementations that suit all requirements of the spec. The following requirement for FSs seems unclear: * If patented or otherwise controlled technology is required for implementation, the separate implementations must also have resulted from separate exercise of the licensing process. Maybe I'm misunderstanding smth., but this is not a requirement but rather just statement. This introduces new difficulties to advancing PSs to FSs; this hard-to-understand demand will mislead almost everybody, I think. Also, the minimum period for existing on Standards Track of 6 month is not really sufficient to fulfill the following requirement: * There are a significant number of implementations with successful operational experience. Some words on STD numbers as well. Their initial purpose was to provide clear reference point to FSs; RFC 1796 encouraged their use to distinguish Standards from other RFCs. However, the experience showed that they doesn't work (or work partly). The well-known problem is what to do with STD number when FSs is recycled to PS. Some recent proposals, such as written by John Klensin (http://tools.ietf.org/html/draft-klensin-std-numbers-01) proposed assignment of STD numbers to all Standards Track RFCs, including PSs. This, even solving aforementioned problem, decreases the usefulness of STD numbers; but now we are not speaking about that proposal. Russ' document leaves this question open; I think it shouldn't. I really think STD numbers should be abandoned; they just make a mess into the Standards Track. Another proposal should be to put some identifier of maturity level in the STD number, assigning one for all documents moving through the Standards Track system, ie. STD P-xx, STD D-xx and STD xx (for FSs), where xx is assigned to PSs only while all its successors retain it; but I don't think such proposal will ever be adopted. Removal of requirement for annual reviews of PSs is a good deed, since nobody really suited to it after NEWTRK WG effort, except rare cases. There are also some minor defects in this draft, concerning Section 4 mostly; I don't want to mention them now. So, taking everything into account, I wouldn't like to see this document approved as BCP. Having a good idea, its realization isn't as good. Mykyta Yevstifeyev 05.05.2011 19:13, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Reducing the Standards Track to Two Maturity Levels'
Re: Last Call: draft-housley-two-maturity-levels-06.txt (Reducing the Standards Track to Two Maturity Levels) to BCP
I am opposed to approving this document as BCP. It is trying to solve the wrong problem; or to put it another way, it is trying to solve a relatively minor problem in a way that distracts attention away from more important problems. Approval of this document will exacerbate an already bad situation, and further dilute the value of IETF standardization. 1. I strongly disagree with the stated goal to publish Proposed Standards as soon as rough consensus is achieved. This goal is consistent with the original intended meaning of proposed standard. But the reality is that the public has long associated proposed standard with suitable for widespread deployment, and is likely to continue to do so no matter how IETF changes its process. Rough consensus is not, and never will be, sufficient to indicate that a standard is suitable for widespread deployment. Instead, I would suggest introducing one or more stages to the process, with clear and unambiguous labels, prior to advancement to Proposed Standard. e.g. recommended for prototype implementations or recommended for isolated interoperability testing or recommended for limited deployment only or candidate for Proposed Standard. These stages shouldn't require full IESG review or publication as RFCs - merely naming the Internet-Draft (with version number) should be sufficient.There should be clear and simple criteria for these labels, and WG consensus + approval of the responsible AD should be sufficient. There should also be defined mechanisms for reporting defects in these documents, and for responding to defect reports. 2. It is arguable that there is little value added by the current transition from Draft Standard to Full Standard, and that the process is too cumbersome in relation to the value provided to the Internet community. But there is still a need to provide incentives to update standards in light of interoperability problems that are observed in the field, and/or changing conditions on the network. There is still a need to inform the Internet community about the current applicability of old standards. Rather than simply drop the last state transition from the current process, we should be examining how to better tailor the process to meet actual community needs. 3. Six months is not sufficient time between approval of Proposed Standard and approval for the final standards maturity level. 4. The increased requirements that have been imposed in practice for Proposed Standard status exist mostly for valid reasons that benefit the community. It is possible that these are indications of flaws in the original 2026 process, but merely relaxing the requirements without addressing the need for those requirements in other ways, will do great harm to the value of IETF documents and to IETF's ability to benefit the Internet community. I strongly disagree with that provision. 5. I strongly object to the idea that IETF should endorse widespread deployment and use of a Proposed Standard prior to any reports of interoperability testing. 6. I support the removal of requirement for annual review of Proposed and Draft Standards, but I think that other mechanisms are needed to ensure that the community is informed about current document applicability. For example, a document's label as standard or its applicability label could automatically expire if not updated within two years' time. 7. I agree that downward references are a significant cause of delay in document approval, but I disagree with the provision to permit downward references to Proposed Standards if the requirements for Proposed Standards are relaxed from what they currently are in practice. I'd feel better about downward references if the current set of requirements were largely kept intact and more formally codified. 8. I think STD numbers have not been beneficial to the community and should probably be abandoned. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-two-maturity-levels-06.txt (Reducing the Standards Track to Two Maturity Levels) to BCP
The document currently says: Downward normative references to Informational documents continue to be allowed using the procedure specified in RFC 3967 [2]. Downward normative references to Historic documents, Experimental documents, and Internet-Draft documents continue to be prohibited. I believe these two statements are in conflict and the conflict must be resolved. My reading of 3967 is that if the community has approved the use of an Experimental document or internet-draft as a downref in a specific last call, that downref is permitted and may even become institutionalized (see the text on an AD waiving further last calls). One of the reasons given in RFC 3967 is: o A migration or co-existence document may need to define a standards track mechanism for migration from, and/or co-existence with, an historic protocol, a proprietary protocol, or possibly a non-standards track protocol. Unless a downref is permitted here, in other words, no coexistence or migration mechanism can ever advance to Internet Standard. This seems to me contrary to the aim of the document. I recommend that the Last Call for advancement re-iterate any downrefs as a specific part of the call and that these calls be lengthened to 4 weeks. This seems to me to follow the current BCPs best, but other resolutions are, of course, possible. I strongly object to this text in Section 5: 2) At any time after two years from the approval of this document as a BCP, the IESG may choose to reclassify any Draft Standard document as Proposed Standard. Section 1 already provides a method for any interested party to request that a document advance from Draft to Internet Standard. Creating another, less stringent method to be employed only after 2 years is, at best, odd. At worst, it seems like a signal that the IESG desires to do a mass update in the future, but does not wish to deal with the political fall-out of saying so at the same time as the publication of the document. I draw this inference from the fact that the current section 2 does not require any IETF-wide Last Call. If this is meant to say that after 2 years, any IESG member may put forward a Last Call for any document to be advanced, then I believe that the IESG member is simply taking the role of community member set forward in Section 1, and no further section is needed. IESG review, Last Call, and approval would still go forward according section 1. In case this is not clear, I do not think a mass update is valuable or desirable. Many of the critical RFCs are pre-Track and no one much seems to mind. At most, I think saying that Internet Standards are permitted to reference Draft Standards is needed. (This can be inferred now from the fact that Proposed Standards may be referenced, but it wouldn't hurt to update that in section 4). I also strongly believe that this proposal will not have the intended effect without concerted efforts by the IESG and WG Chairs to adhere to the new Proposed Standard vision. As a new WG Chair, I plan to push that vision for my own group, and I hope that the IESG will support that effort as this document intends. regards, Ted Hardie ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-two-maturity-levels-06.txt (Reducing the Standards Track to Two Maturity Levels) to BCP
Ted: The document currently says: Downward normative references to Informational documents continue to be allowed using the procedure specified in RFC 3967 [2]. Downward normative references to Historic documents, Experimental documents, and Internet-Draft documents continue to be prohibited. I believe these two statements are in conflict and the conflict must be resolved. My reading of 3967 is that if the community has approved the use of an Experimental document or internet-draft as a downref in a specific last call, that downref is permitted and may even become institutionalized (see the text on an AD waiving further last calls). One of the reasons given in RFC 3967 is: o A migration or co-existence document may need to define a standards track mechanism for migration from, and/or co-existence with, an historic protocol, a proprietary protocol, or possibly a non-standards track protocol. Unless a downref is permitted here, in other words, no coexistence or migration mechanism can ever advance to Internet Standard. This seems to me contrary to the aim of the document. I recommend that the Last Call for advancement re-iterate any downrefs as a specific part of the call and that these calls be lengthened to 4 weeks. This seems to me to follow the current BCPs best, but other resolutions are, of course, possible. Good catch. I think we should revise this to allow normative references to Informational, Experimental, and Historic RFCs using the procedures in RFC 3967. I strongly object to this text in Section 5: 2) At any time after two years from the approval of this document as a BCP, the IESG may choose to reclassify any Draft Standard document as Proposed Standard. Section 1 already provides a method for any interested party to request that a document advance from Draft to Internet Standard. Creating another, less stringent method to be employed only after 2 years is, at best, odd. At worst, it seems like a signal that the IESG desires to do a mass update in the future, but does not wish to deal with the political fall-out of saying so at the same time as the publication of the document. I draw this inference from the fact that the current section 2 does not require any IETF-wide Last Call. If this is meant to say that after 2 years, any IESG member may put forward a Last Call for any document to be advanced, then I believe that the IESG member is simply taking the role of community member set forward in Section 1, and no further section is needed. IESG review, Last Call, and approval would still go forward according section 1. In case this is not clear, I do not think a mass update is valuable or desirable. Many of the critical RFCs are pre-Track and no one much seems to mind. At most, I think saying that Internet Standards are permitted to reference Draft Standards is needed. (This can be inferred now from the fact that Proposed Standards may be referenced, but it wouldn't hurt to update that in section 4). I also strongly believe that this proposal will not have the intended effect without concerted efforts by the IESG and WG Chairs to adhere to the new Proposed Standard vision. As a new WG Chair, I plan to push that vision for my own group, and I hope that the IESG will support that effort as this document intends. I am lost here. Based on a previous version of the Internet-Draft, the question was raised by Brian Carpenter about documents that were stuck in a state Draft Standard after that label is abandoned. There was discussion on the list, and some people felt that it was neither confusing nor harmful, while others thought that it would lead to confusion. This proposal is intended to let the IESG decide, If it is not considered a problem, they can do nothing. If it is considered a problem, they can move the Draft Standard DOWN to Proposed Standard. Your use of be advanced makes me wonder if you got a different interpretation. Russ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-two-maturity-levels-06.txt (Reducing the Standards Track to Two Maturity Levels) to BCP
As I have stated before, I do not think that this proposal will achieve anything useful since it will not change anything related to the underlying causes of few Proposed Standards advancing on the standards track. I see it as window dressing and, thus, a diversion from the technical work the IETF should focus on. If it were up to me, I would not approve this ID for publication as a RFC (of any type) Scott ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-two-maturity-levels-06.txt (Reducing the Standards Track to Two Maturity Levels) to BCP
On Thu, May 5, 2011 at 11:21 AM, Russ Housley hous...@vigilsec.com wrote: I strongly object to this text in Section 5: 2) At any time after two years from the approval of this document as a BCP, the IESG may choose to reclassify any Draft Standard document as Proposed Standard. Section 1 already provides a method for any interested party to request that a document advance from Draft to Internet Standard. Creating another, less stringent method to be employed only after 2 years is, at best, odd. At worst, it seems like a signal that the IESG desires to do a mass update in the future, but does not wish to deal with the political fall-out of saying so at the same time as the publication of the document. I draw this inference from the fact that the current section 2 does not require any IETF-wide Last Call. If this is meant to say that after 2 years, any IESG member may put forward a Last Call for any document to be advanced, then I believe that the IESG member is simply taking the role of community member set forward in Section 1, and no further section is needed. IESG review, Last Call, and approval would still go forward according section 1. In case this is not clear, I do not think a mass update is valuable or desirable. Many of the critical RFCs are pre-Track and no one much seems to mind. At most, I think saying that Internet Standards are permitted to reference Draft Standards is needed. (This can be inferred now from the fact that Proposed Standards may be referenced, but it wouldn't hurt to update that in section 4). I also strongly believe that this proposal will not have the intended effect without concerted efforts by the IESG and WG Chairs to adhere to the new Proposed Standard vision. As a new WG Chair, I plan to push that vision for my own group, and I hope that the IESG will support that effort as this document intends. I am lost here. Based on a previous version of the Internet-Draft, the question was raised by Brian Carpenter about documents that were stuck in a state Draft Standard after that label is abandoned. There was discussion on the list, and some people felt that it was neither confusing nor harmful, while others thought that it would lead to confusion. This proposal is intended to let the IESG decide, If it is not considered a problem, they can do nothing. If it is considered a problem, they can move the Draft Standard DOWN to Proposed Standard. Your use of be advanced makes me wonder if you got a different interpretation. I did misread this, sorry. I still don't think it is a good idea, but I will drop from strongly object to object. I think we should acknowledge that we had an era in which Draft Standards existed and leave it at that. Updates from Draft to Internet Standard make some sense, because in at least some cases they would have been updated to Standard. But the only way under our current process to force something from Draft to Proposed is to re-cycle it, and I don't think that should change. I think a mass update (in any direction) would be a mistake. At the core of that belief is a conviction that any change that didn't result from a re-cycle should require a Last Call to the community. Up, Down, Sidewise--these should be community decisions that the IESG approves, not IESG decisions without community input. Thanks for your quick reply, Ted Russ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-housley-two-maturity-levels-06.txt (Reducing the Standards Track to Two Maturity Levels) to BCP
Speaking for myself only, I believe that this proposal does attempt to address some issues relating to advancement, so that it is not entirely window dressing. For example, I believe that the changes with respect to down references (Section 4) and annual review (Section 3) are constructive, and long overdue. Implementation reports are a more difficult topic since they constitute both an obstacle to advancement as well as an important step on the road to development of interoperable standards. In particular, the development of implementation reports, while cumbersome, provides objective evidence of progress. It is difficult to simultaneously lower the barriers to advancement while keeping most of the value (and objectivity) that implementation reports provide. I am not sure that the document currently has this balance quite right. Section 2.2 states: Note that the distinct requirement from RFC 2026 [1] for reports of interoperability testing among two or more independent implementations is intentionally subsumed by the requirement for actual deployment and use of independent and interoperable implementations. The Last Call is intended to identify unused portions of the specification that greatly increase implementation complexity without burdensome implementation testing and documentation. Today it is quite common within WGs to see conflicting claims about protocol implementations and interoperability. IMHO one of the critical purposes served by implementation reports is to require proponents to produce the evidence backing their claims. The above paragraph left me wondering what the burden of proof would be in practice. For example, I would not want to see the IESG put in the position of adjudicating he said, she said arguments made during Last Call. As a result, I cannot endorse the approval of this ID as it exists today, but could see it being changed to address these concerns. To: ietf@ietf.org Subject: Re: Last Call: draft-housley-two-maturity-levels-06.txt (Reducing the Standards Track to Two Maturity Levels) to BCP Date: Thu, 5 May 2011 14:33:51 -0400 From: s...@harvard.edu CC: i...@ietf.org As I have stated before, I do not think that this proposal will achieve anything useful since it will not change anything related to the underlying causes of few Proposed Standards advancing on the standards track. I see it as window dressing and, thus, a diversion from the technical work the IETF should focus on. If it were up to me, I would not approve this ID for publication as a RFC (of any type) Scott ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-two-maturity-levels-06.txt (Reducing the Standards Track to Two Maturity Levels) to BCP
I think this draft may do a little good, but mostly based on the attention it brings to the issue. If it is actually desired to make it easier to become a Proposed Standard, it would be quite easy and straightforward to take real steps that would make a real different. For example, to *prohibit* the requirement of multiple interoperable implementations, a requirement sometimes applied in an inconsistent and haphazard manner to candidates for Proposed Standard. On STD numbers, they were an interesting experiment but I believe, as currently implemented, they have been proven to add only confusion and bureaucracy. It would be quite easy and straightforward to have a different document sequence for Standards. For success in this, it would be essential to assure that they do *not* have RFC numbers. History shows that, regardless of other labels, if a document has an RFC #, most references to it will be via that number. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street Milford, MA 01757 USA d3e...@gmail.com On Thu, May 5, 2011 at 2:33 PM, Scott O. Bradner s...@harvard.edu wrote: As I have stated before, I do not think that this proposal will achieve anything useful since it will not change anything related to the underlying causes of few Proposed Standards advancing on the standards track. I see it as window dressing and, thus, a diversion from the technical work the IETF should focus on. If it were up to me, I would not approve this ID for publication as a RFC (of any type) 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: Last Call: draft-housley-two-maturity-levels-06.txt (Reducing the Standards Track to Two Maturity Levels) to BCP
I support publishing this document as a BCP. While I understand that this does not solve all conceivable problems with the world, nonetheless I see this as a small but significant step in the right direction. Thanks, Ross -Original Message- From: ietf-announce-boun...@ietf.org [mailto:ietf-announce- boun...@ietf.org] On Behalf Of The IESG Sent: 05 May 2011 17:13 To: IETF-Announce Subject: Last Call: draft-housley-two-maturity-levels-06.txt (Reducing the Standards Track to Two Maturity Levels) to BCP The IESG has received a request from an individual submitter to consider the following document: - 'Reducing the Standards Track to Two Maturity Levels' draft-housley-two-maturity-levels-06.txt as a BCP The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-06-02. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-housley-two-maturity-levels/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-housley-two-maturity-levels/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-two-maturity-levels-06.txt (Reducing the Standards Track to Two Maturity Levels) to BCP
On May 5, 2011, at 12:50 PM, Ross Callon wrote: I support publishing this document as a BCP. While I understand that this does not solve all conceivable problems with the world, nonetheless I see this as a small but significant step in the right direction. Hear, hear. +1. Melinda ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-two-maturity-levels-06.txt (Reducing the Standards Track to Two Maturity Levels) to BCP
Donald Eastlake d3e...@gmail.com wrote: If it is actually desired to make it easier to become a Proposed Standard, it would be quite easy and straightforward to take real steps that would make a real different. For example, to *prohibit* the requirement of multiple interoperable implementations, a requirement sometimes applied in an inconsistent and haphazard manner to candidates for Proposed Standard. +1 I suppose where such requirements are dropped, a warning-label such as Not considered safe for widespread deployment deserves to be attached; but IMHO we'd be much better off with explicit warning labels than with implicit expectiations which are poorly documented. Proposed Standard _used_to_ imply May not be safe for widespread deployment; but I'm afraid that whole mindset has disappeared over the years. I would suggest a serious effort to list mission-creep that has found its way into requirements for Proposed Standard; and to work out what sort of warning labels we could use instead. Otherwise, I see escalating mission-creep, regardless of the number of maturity levels. -- John Leslie j...@jlc.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-two-maturity-levels-06.txt (Reducing the Standards Track to Two Maturity Levels) to BCP
Folks, On 5/5/2011 11:33 AM, Scott O. Bradner wrote: As I have stated before, I do not think that this proposal will achieve anything useful since it will not change anything related to the underlying causes of few Proposed Standards advancing on the standards track. We currently have a standards process that largely ignores two of its stages. At the least, our community should be embarrassed about this cruft and should want to streamline things and make them more likely to be fully exercised. I happen to be skeptical abut the one motivation offered in the document, that that the proposed changes will affect how working groups or the IESG handle criteria for achieving Proposed (modulo the downref change.) There are folks who have some faith that this change will make it easier to get to Proposed. I don't understand their logic, but what the heck, it's a substantial constituency that believes it. I lobbied with Russ to expand the list of benefits so that the evaluation of the proposed change would not rely /only/ on that one issue. I think there is an array of benefits that plausibly can accrue from this change and that we need not rely on only one: 1. The criteria for the second stage are significantly clarified and rely exclusively on actual adoption and use (again, modulo some important nuances.) Whatever happens with the practice of getting to Proposed, this should make it more predictable and easier to get to (Full) Internet Standard, based solely on actual success of the specification. 2. The model is cleaned up, in my opinion significantly. This improves transparency of the process a bit. Also, I think Draft made sense when our whole endeavor was less mature and we needed to help the community understand what is needed for achieving interoperable deployments. Today we need the /practice/ of interop efforts, but we do not need it in the formal process, as demonstrated by how few specs get to Draft in spite of becoming entirely successful community services.[1] 3. The changes are likely to remove bits of community confusion about the IETF standards labels. Not entirely of course, because people are creative. But the proposed changes make a very clean distinction between the initial technical work and the later adoption/deployment/use work. We should be careful not to latch onto a non-normative detail in the doc as the basis for accepting or rejecting it. What should matter is whether the changes make sense. d/ [1] There is an argument that doing the work of getting to Draft makes for better specs. I have no trouble believing that. Were it widely practiced, we'd probably have a better Internet. But the fact that there is a majority practice of staying at Proposed renders the minority practice of diligently qualifying for Draft irrelevant, IMO. -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-housley-two-maturity-levels-06.txt (Reducing the Standards Track to Two Maturity Levels) to BCP
The IESG has received a request from an individual submitter to consider the following document: - 'Reducing the Standards Track to Two Maturity Levels' draft-housley-two-maturity-levels-06.txt as a BCP The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2011-06-02. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-housley-two-maturity-levels/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-housley-two-maturity-levels/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
