Re: I-D Action:draft-housley-two-maturity-levels-04.txt
Hello all, We reached the conclusion that the sunset period of 2 years for advancing DSs to FSs or downgrading of them. However there are some issues that should also be discussed, such as making references to DSs during this period, DSs already in IESG processing, etc. So, I propose to mention that: During this period Full Standards as well as Proposed Standards are allowed to make normative references to Draft Standards. Regarding DSs already in IESG processing: Upon approval of this document IESG SHALL NOT accept any requests for advancing of Proposed Standards to Draft Standards. Those documents that, at the time of publication of this document, will already be in IESG processing for advancing to Draft Standards SHOULD automatically be considered for advancing to Full Stndard; however IESG, on their own discretion, MAY decide on discarding such document for further work on it. Another question is what should be done with RFC 5657 (http://tools.ietf.org/html/rfc5657), that is related to DSs, that are terminated by the proposed document. My proposal is to make it update RFC 5657 and mention that is changes its sphere of action to advancing to FSs. Any other ideas? Mykyta Yevstifeyev ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: I-D Action:draft-housley-two-maturity-levels-04.txt
On Mar 16, 2011, at 1:08 AM, Brian E Carpenter wrote: To make clear which documents were issued under the original regime and which were issued under the new, there should probably be an obvious gap in the number range (going to 5 digit or 6 digit numbers). Oh, have you any guess how many tools will be broken by the RFC10K problem? (That is not a joke.) By looking at http://arkko.com/tools/rfcstats/pubdistr.html The RFC10K problem will hit us around 2020 (assuming the publication rate keeps increasing) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: I-D Action:draft-housley-two-maturity-levels-04.txt
On 3/15/2011 4:08 PM, Brian E Carpenter wrote: That's why my personal preference is what I already suggested - just label them all as Internet Standard. Classifying specs as full standards, when there is no evidence that the criteria for Full are satisfied, is a good way to instantly de-value Full Standard. But in fact, the proposed bar for promotion from DS to Internet Standard is pretty low. I doubt that any deserving document will lose out. You think that successful deployment and use is a low bar? Most Internet experience is that gaining real-world deployment and use is far more difficult than getting the spec published... the status of the existing documents should NOT be touched by any new rules for publishing documents as Proposed Standards. Disagree. If we don't reclassify, people will be puzzled for the next 50 years by the residual DS documents. No doubt there will be some folks are confused. But the reality is that there will always be some people who are confused, for any issue, no matter what is done to prevent it. Certainly we have plenty of demonstration that this is a universal, yet somehow we've survived and even flourished. So that doesn't make a very useful criterion. A more useful criterion would be demonstrating that the confusion causes significant problems. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: I-D Action:draft-housley-two-maturity-levels-04.txt
At 04:05 PM 3/14/2011, Brian E Carpenter wrote: There are numerous improvements in this version and I hope we can get consensus soon. Just a couple of remarks on 5. Transition to a Standards Track with Two Maturity Levels 1) Probably there should be a statement that all existing Internet Standard documents are still classified as Internet Standard. That may seem blindingly obvious, but if we don't write it down, somebody will ask. 2) More substantively, Any protocol or service that is currently at the Draft Standard maturity level may be reclassified as an Internet Standard as soon as the criteria in Section 2.2 are satisfied. This reclassification is accomplished by submitting a request to the IESG along with a description of the implementation and operational experience. I'm a bit concerned that this doesn't scale, and we will be left with a long tail of DS documents that end up in limbo. One way to avoid this is to encourage bulk reclassifications (rather like we did a bulk declassification in RFC 4450). Another way is to define a sunset date, e.g. Any documents that are still classified as Draft Standard two years after the publication of this RFC will be automatically downgraded to Proposed Standard. Brian playing devil's advocate here... Say someone submits a request for an existing DS to the IESG and it takes 6 months (or 3 months) to get through the process, but only 2 months remain before the 2 year window is up (since this RFC was published). Does that grandfather the DS into the process - meaning that document is no longer subject to this 'within 2 year notice' rule? I'm just saying that this appears to beg all DS editors to get their DS notifications into the IESG sooner rather than later, which is fine, but that also creates a heck of a workload on the IESG that they currently do not have, does it not? Something is going to be impacted. James Brian ___ 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: I-D Action:draft-housley-two-maturity-levels-04.txt
Hello, 2011/3/14, Brian E Carpenter brian.e.carpen...@gmail.com: There are numerous improvements in this version and I hope we can get consensus soon. Just a couple of remarks on 5. Transition to a Standards Track with Two Maturity Levels 1) Probably there should be a statement that all existing Internet Standard documents are still classified as Internet Standard. That may seem blindingly obvious, but if we don't write it down, somebody will ask. 2) More substantively, Any protocol or service that is currently at the Draft Standard maturity level may be reclassified as an Internet Standard as soon as the criteria in Section 2.2 are satisfied. This reclassification is accomplished by submitting a request to the IESG along with a description of the implementation and operational experience. I'm a bit concerned that this doesn't scale, and we will be left with a long tail of DS documents that end up in limbo. One way to avoid this is to encourage bulk reclassifications (rather like we did a bulk declassification in RFC 4450). Another way is to define a sunset date, e.g. Any documents that are still classified as Draft Standard two years after the publication of this RFC will be automatically downgraded to Proposed Standard. I'm personally not sure whether such operations will be acceptable. If there is a Draft Standard, it means that it is more mature that Proposed Standrad. Therefore downgrading DSs to PSs does not seem a good idea personally for me. It is better to say that DSs should remain in this maturity level until properly advanced to FS, obsoleted or moved to Historic status. Brian ___ 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: I-D Action:draft-housley-two-maturity-levels-04.txt
On Tue, Mar 15, 2011 at 3:33 AM, James M. Polk jmp...@cisco.com wrote: Brian playing devil's advocate here... Say someone submits a request for an existing DS to the IESG and it takes 6 months (or 3 months) to get through the process, but only 2 months remain before the 2 year window is up (since this RFC was published). Does that grandfather the DS into the process - meaning that document is no longer subject to this 'within 2 year notice' rule? I'm just saying that this appears to beg all DS editors to get their DS notifications into the IESG sooner rather than later, which is fine, but that also creates a heck of a workload on the IESG that they currently do not have, does it not? Something is going to be impacted. Make it a 2 year deadline for receiving requests. Problem solved. -- Website: http://hallambaker.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: I-D Action:draft-housley-two-maturity-levels-04.txt
On 3/14/2011 2:05 PM, Brian E Carpenter wrote: 2) More substantively, Any protocol or service that is currently at the Draft Standard maturity level may be reclassified as an Internet Standard as soon as the criteria in Section 2.2 are satisfied. This reclassification is accomplished by submitting a request to the IESG along with a description of the implementation and operational experience. I'm a bit concerned that this doesn't scale, and we will be left with a long tail of DS documents that end up in limbo. One way to avoid this is to encourage bulk reclassifications (rather like we did a bulk declassification in RFC 4450). Another way is to define a sunset date, e.g. Any documents that are still classified as Draft Standard two years after the publication of this RFC will be automatically downgraded to Proposed Standard. Brian, Certainly a reasonable concern. However... 1. While the accounting ugliness of leaving these untouched is obvious, I am less clear about the practical trouble they cause. We should gain some public agreement that this is seriousness enough to worry about, and why. 2. Automatic reclassification strikes me as dangerous and likely to have serious unintended consequences. I believe we do not have a history of having done anything like this, in spite of our rules, except for aging out I-Ds. 3. Your's specific proposal assumes ready availability of workers for documents that are used. In fact, the folks who use specs are often far removed from the IETF and neither aware of IETF activities nor available to contribute to them. This is an example of a downside likely to downgrade docs inappropriately, IMO. Alas, I don't have a constructive, alternative suggestion. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: I-D Action:draft-housley-two-maturity-levels-04.txt
On Wed, Mar 16, 2011 at 1:11 AM, Phillip Hallam-Baker hal...@gmail.com wrote: On Tue, Mar 15, 2011 at 3:33 AM, James M. Polk jmp...@cisco.com wrote: Brian playing devil's advocate here... Say someone submits a request for an existing DS to the IESG and it takes 6 months (or 3 months) to get through the process, but only 2 months remain before the 2 year window is up (since this RFC was published). Does that grandfather the DS into the process - meaning that document is no longer subject to this 'within 2 year notice' rule? I'm just saying that this appears to beg all DS editors to get their DS notifications into the IESG sooner rather than later, which is fine, but that also creates a heck of a workload on the IESG that they currently do not have, does it not? Something is going to be impacted. Make it a 2 year deadline for receiving requests. Problem solved. Yes, good idea. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: I-D Action:draft-housley-two-maturity-levels-04.txt
On Wed, Mar 16, 2011 at 12:03 AM, Mykyta Yevstifeyev evniki...@gmail.com wrote: Hello, 2011/3/14, Brian E Carpenter brian.e.carpen...@gmail.com: There are numerous improvements in this version and I hope we can get consensus soon. Just a couple of remarks on 5. Transition to a Standards Track with Two Maturity Levels 1) Probably there should be a statement that all existing Internet Standard documents are still classified as Internet Standard. That may seem blindingly obvious, but if we don't write it down, somebody will ask. 2) More substantively, Any protocol or service that is currently at the Draft Standard maturity level may be reclassified as an Internet Standard as soon as the criteria in Section 2.2 are satisfied. This reclassification is accomplished by submitting a request to the IESG along with a description of the implementation and operational experience. I'm a bit concerned that this doesn't scale, and we will be left with a long tail of DS documents that end up in limbo. One way to avoid this is to encourage bulk reclassifications (rather like we did a bulk declassification in RFC 4450). Another way is to define a sunset date, e.g. Any documents that are still classified as Draft Standard two years after the publication of this RFC will be automatically downgraded to Proposed Standard. I'm personally not sure whether such operations will be acceptable. If there is a Draft Standard, it means that it is more mature that Proposed Standrad. Therefore downgrading DSs to PSs does not seem a good idea personally for me. It is better to say that DSs should remain in this maturity level until properly advanced to FS, obsoleted or moved to Historic status. All our experience shows that unless we have a firm sunset date, the job will never be finished and in fifty years there will still be DS documents. If nobody cares - the document will be downgraded. What's the problem with that? It will still be on the standards track. (Automatic downgrading to Historic would be a different matter.) Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: I-D Action:draft-housley-two-maturity-levels-04.txt
On Wed, Mar 16, 2011 at 6:13 AM, Dave CROCKER d...@dcrocker.net wrote: On 3/14/2011 2:05 PM, Brian E Carpenter wrote: 2) More substantively, Any protocol or service that is currently at the Draft Standard maturity level may be reclassified as an Internet Standard as soon as the criteria in Section 2.2 are satisfied. This reclassification is accomplished by submitting a request to the IESG along with a description of the implementation and operational experience. I'm a bit concerned that this doesn't scale, and we will be left with a long tail of DS documents that end up in limbo. One way to avoid this is to encourage bulk reclassifications (rather like we did a bulk declassification in RFC 4450). Another way is to define a sunset date, e.g. Any documents that are still classified as Draft Standard two years after the publication of this RFC will be automatically downgraded to Proposed Standard. Brian, Certainly a reasonable concern. However... 1. While the accounting ugliness of leaving these untouched is obvious, I am less clear about the practical trouble they cause. We should gain some public agreement that this is seriousness enough to worry about, and why. 2. Automatic reclassification strikes me as dangerous and likely to have serious unintended consequences. I believe we do not have a history of having done anything like this, in spite of our rules, except for aging out I-Ds. 3. Your's specific proposal assumes ready availability of workers for documents that are used. In fact, the folks who use specs are often far removed from the IETF and neither aware of IETF activities nor available to contribute to them. This is an example of a downside likely to downgrade docs inappropriately, IMO. Alas, I don't have a constructive, alternative suggestion. There's a fairly obvious alternative, which is to shrug about the widespread deployment rule and promote all existing DS automatically to Internet Standard. That wouldn't shock me - and it would be a lot less work for everybody. We could still require widespread deployment for future documents. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: I-D Action:draft-housley-two-maturity-levels-04.txt
At 02:05 PM 3/15/2011, Brian Carpenter wrote: On Wed, Mar 16, 2011 at 1:11 AM, Phillip Hallam-Baker hal...@gmail.com wrote: On Tue, Mar 15, 2011 at 3:33 AM, James M. Polk jmp...@cisco.com wrote: Brian playing devil's advocate here... Say someone submits a request for an existing DS to the IESG and it takes 6 months (or 3 months) to get through the process, but only 2 months remain before the 2 year window is up (since this RFC was published). Does that grandfather the DS into the process - meaning that document is no longer subject to this 'within 2 year notice' rule? I'm just saying that this appears to beg all DS editors to get their DS notifications into the IESG sooner rather than later, which is fine, but that also creates a heck of a workload on the IESG that they currently do not have, does it not? Something is going to be impacted. Make it a 2 year deadline for receiving requests. Problem solved. Yes, good idea. thanks james Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: I-D Action:draft-housley-two-maturity-levels-04.txt
Dave CROCKER wrote: Brian E Carpenter wrote: Any documents that are still classified as Draft Standard two years after the publication of this RFC will be automatically downgraded to Proposed Standard. 1. While the accounting ugliness of leaving these untouched is obvious, I am less clear about the practical trouble they cause. We should gain some public agreement that this is seriousness enough to worry about, and why. 2. Automatic reclassification strikes me as dangerous and likely to have serious unintended consequences. I don't understand the motivation about changing anything about the status of documents that have already been published. Among the original complaints there were the two: - the IETF is confusing the non-IETFers about the standardization with its three levels of document maturity - the bar for Proposed is too high and ought to be lowered. Unless the clear intent and IETF consensus is to add - mislead _everyone_ about the real document maturity of *ALL* IETF documents, including all existing documents - penalize all folks did put effort into going to Draft Standard by completely nixing their effort two years later. the status of the existing documents should NOT be touched by any new rules for publishing documents as Proposed Standards. To make clear which documents were issued under the original regime and which were issued under the new, there should probably be an obvious gap in the number range (going to 5 digit or 6 digit numbers). -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: I-D Action:draft-housley-two-maturity-levels-04.txt
On Tue, 2011-03-15, Martin Rex wrote: Dave CROCKER wrote: Brian E Carpenter wrote: Any documents that are still classified as Draft Standard two years after the publication of this RFC will be automatically downgraded to Proposed Standard. 1. While the accounting ugliness of leaving these untouched is obvious, I am less clear about the practical trouble they cause. We should gain some public agreement that this is seriousness enough to worry about, and why. 2. Automatic reclassification strikes me as dangerous and likely to have serious unintended consequences. I don't understand the motivation about changing anything about the status of documents that have already been published. Among the original complaints there were the two: - the IETF is confusing the non-IETFers about the standardization with its three levels of document maturity - the bar for Proposed is too high and ought to be lowered. Unless the clear intent and IETF consensus is to add - mislead _everyone_ about the real document maturity of *ALL* IETF documents, including all existing documents - penalize all folks did put effort into going to Draft Standard by completely nixing their effort two years later. the status of the existing documents should NOT be touched by any new rules for publishing documents as Proposed Standards. +1 To make clear which documents were issued under the original regime and which were issued under the new, there should probably be an obvious gap in the number range (going to 5 digit or 6 digit numbers). -1 (simple sequentially increasing RFC numbers for all items is fine) -Martin -- Bill McQuillan mcqui...@pobox.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: I-D Action:draft-housley-two-maturity-levels-04.txt
On 2011-03-16 11:22, Martin Rex wrote: Dave CROCKER wrote: Brian E Carpenter wrote: Any documents that are still classified as Draft Standard two years after the publication of this RFC will be automatically downgraded to Proposed Standard. 1. While the accounting ugliness of leaving these untouched is obvious, I am less clear about the practical trouble they cause. We should gain some public agreement that this is seriousness enough to worry about, and why. 2. Automatic reclassification strikes me as dangerous and likely to have serious unintended consequences. I don't understand the motivation about changing anything about the status of documents that have already been published. Among the original complaints there were the two: - the IETF is confusing the non-IETFers about the standardization with its three levels of document maturity - the bar for Proposed is too high and ought to be lowered. Unless the clear intent and IETF consensus is to add - mislead _everyone_ about the real document maturity of *ALL* IETF documents, including all existing documents If we do the reclassification correctly, nobody will be misled. - penalize all folks did put effort into going to Draft Standard by completely nixing their effort two years later. That's why my personal preference is what I already suggested - just label them all as Internet Standard. But in fact, the proposed bar for promotion from DS to Internet Standard is pretty low. I doubt that any deserving document will lose out. There are 85 DS documents today. If each IETF Area does its own bulk promotion, that averages at 12 documents per area - not an enormous job. the status of the existing documents should NOT be touched by any new rules for publishing documents as Proposed Standards. Disagree. If we don't reclassify, people will be puzzled for the next 50 years by the residual DS documents. To make clear which documents were issued under the original regime and which were issued under the new, there should probably be an obvious gap in the number range (going to 5 digit or 6 digit numbers). Oh, have you any guess how many tools will be broken by the RFC10K problem? (That is not a joke.) Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: I-D Action:draft-housley-two-maturity-levels-04.txt
There are numerous improvements in this version and I hope we can get consensus soon. Just a couple of remarks on 5. Transition to a Standards Track with Two Maturity Levels 1) Probably there should be a statement that all existing Internet Standard documents are still classified as Internet Standard. That may seem blindingly obvious, but if we don't write it down, somebody will ask. 2) More substantively, Any protocol or service that is currently at the Draft Standard maturity level may be reclassified as an Internet Standard as soon as the criteria in Section 2.2 are satisfied. This reclassification is accomplished by submitting a request to the IESG along with a description of the implementation and operational experience. I'm a bit concerned that this doesn't scale, and we will be left with a long tail of DS documents that end up in limbo. One way to avoid this is to encourage bulk reclassifications (rather like we did a bulk declassification in RFC 4450). Another way is to define a sunset date, e.g. Any documents that are still classified as Draft Standard two years after the publication of this RFC will be automatically downgraded to Proposed Standard. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: I-D Action:draft-housley-two-maturity-levels-04.txt
On 3/14/2011 5:05 PM, Brian E Carpenter wrote: There are numerous improvements in this version and I hope we can get consensus soon. Just a couple of remarks on 5. Transition to a Standards Track with Two Maturity Levels 1) Probably there should be a statement that all existing Internet Standard documents are still classified as Internet Standard. That may seem blindingly obvious, but if we don't write it down, somebody will ask. sigh -- +1 2) More substantively, ... I'm a bit concerned that this doesn't scale, and we will be left with a long tail of DS documents that end up in limbo. One way to avoid this is to encourage bulk reclassifications (rather like we did a bulk declassification in RFC 4450). Another way is to define a sunset date, e.g. Any documents that are still classified as Draft Standard two years after the publication of this RFC will be automatically downgraded to Proposed Standard. I think both suggestions are in order. +1 and +1 Tony Hansen ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
