Re: Request for review of draft-yevstifeyev-genarea-historic-03
--On Monday, March 07, 2011 10:50 -0800 Randy Presuhn randy_pres...@mindspring.com wrote: The IAB and IESG control STD1, and have every right and in fact a responsibility to say what status they think any document has. You or anyone else can disagree and have your own list. The historicization of RFC 1227 provides an interesting example of this. Without speculating on the motivations behind that decision, I think it does provide a clear example of an explicitly experimental protocol that was actually getting significant use at the time being declared historic. This is pure speculation --if I ever knew, I've forgotten-- but it is possible that questions about the reasons for that decision and others contributed to the IESG's later conclusion/policy that changing something to Historic requires documentation in the RFC Series. I've disagreed with that conclusion from time to time on the grounds that it creates an excessively heavyweight and resource-consuming requirement. I've even proposed and advocated alternative ways to appropriately document such decisions. However, the motivation for better documentation of reclassification decisions is clear. Your comment shows why documenting these things in some easily-accessible way is appropriate and desirable. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Request for review of draft-yevstifeyev-genarea-historic-03
Ran, On the following point: On 3/3/11 4:59 PM, RJ Atkinson wrote: Fourth, it is not appropriate for the IETF (or IESG) to reclassify any RFC that was not originally published as an IETF track RFC. The IETF simply lacks authority to reclassify such RFCs, although if the original author explicitly consents in advance to the reclassification (e.g. recently for MD2/MD4) this can be done. This is particularly true for the older RFCs that appear to be the target of this I-D and I-D author. For those older RFCs, it isn't even the case the the IETF Trust (or ISoc) hold any well defined rights. The IAB and IESG control STD1, and have every right and in fact a responsibility to say what status they think any document has. You or anyone else can disagree and have your own list. Eliot ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Request for review of draft-yevstifeyev-genarea-historic-03
Hi - From: Eliot Lear l...@cisco.com To: RJ Atkinson rja.li...@gmail.com Cc: ietf@ietf.org Sent: Monday, March 07, 2011 4:06 AM Subject: Re: Request for review of draft-yevstifeyev-genarea-historic-03 ... The IAB and IESG control STD1, and have every right and in fact a responsibility to say what status they think any document has. You or anyone else can disagree and have your own list. The historicization of RFC 1227 provides an interesting example of this. Without speculating on the motivations behind that decision, I think it does provide a clear example of an explicitly experimental protocol that was actually getting significant use at the time being declared historic. Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Request for review of draft-yevstifeyev-genarea-historic-03
On 05 Mar 2011, at 01:35 , Mykyta Yevstifeyev wrote: I'd like to ask how was it done, what procedures were used. Existing IETF procedures were used, as best I understand, which shows that we do NOT need any new procedures. As I noted, that use happened to have an incorrect result, because people on the IESG were apparently unaware of the widespread use of that specification (albeit within private networks on nearly all continents, rather than on the global Internet). Many protocols are used primarily or exclusively within private networks. As many people have already said here, it is impossible to measure such usage, which means mistakes are likely. Better to leave things alone. I agree with you here - IETF does not have the authority on the RFCs from other streams. For IAB, IRTF and IS streams it is clear, but as for pre-IETF ones? Also quite clear. Pre-IETF RFCs should be left alone. Again, I do not believe this document is fixable. I think it should be dropped, as should further discussion of publishing this document. Yours, Ran ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Request for review of draft-yevstifeyev-genarea-historic-03
-Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Joel M. Halpern Sent: Thursday, March 03, 2011 7:41 AM To: Mykyta Yevstifeyev Cc: IETF Discussion; Scott O. Bradner Subject: Re: Request for review of draft-yevstifeyev-genarea-historic-03 Our current definition for historic, and our current choices for when to move things, have worked sufficiently well. I have not seen any evidence that there is a problem that needs solving. I have also not seen any evidence that the changes you propose to the definitions would help anything. +1 -MSK ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Request for review of draft-yevstifeyev-genarea-historic-03
I agree with you that it is really hard and even impossible to determine what is going on in the Internet regarding some technology, protocol, etc. If we set the impossible criterion for the Historic documents, this will really make very few sense. So, as I have been pointed out, I find removing the regulation about 'out-of-use' technology at all quite acceptable. Do you agree? It strikes me that we are spending time debating this to little result, and we're missing one aspect of rough consensus, of which Dave is always wont to remind me: someone has to agree with something in order to make a start at moving to consensus. So far, we've had several people chiming in to disagree with the need for this document. I propose this: If anyone (other than the author) thinks this document *is* necessary, please say so. Until someone does, the rest of us may go about our other work. Lacking affirmative support, this document should go away. If support arrives, we can resume the debate. Barry ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Request for review of draft-yevstifeyev-genarea-historic-03
03.03.2011 17:41, Joel M. Halpern wrote: No, I do not agree with you. Our current definition for historic, and our current choices for when to move things, have worked sufficiently well. I have not seen any evidence that there is a problem that needs solving. But I see. IMO this is the absence of procedures either for reclassification of RFCs to Historic or bare publication of Historic RFCs (I mean such cases as RFC 6123 or RFC 6037, that is even an Independent Submission). I have also not seen any evidence that the changes you propose to the definitions would help anything. Yes, there are problems with our current definitions. Those problems serve to keep us from declaring something historic when we shouldn't. They do, as a side effect, make it harder to declare things historic even if they actually are? I will even agree that there is a small cost to that. Users of our standards may sometimes think some things are relevant that aren't. But changing the definitions to make it easier to change the status does not actually change the problem. The problem is that it is hard for anyone (the IETF, vendors, operators) to reliably know what is actually in use. I agree with this. But this is what we can already find in RFC 2026 - I mean the word 'obsolete' that is a synonym to the word 'out-of-use'. If we think that is is really impossible to track this, we should update this definition. Yours, Joel PS: I have actually noticed with several specifications I worked with that it can easily take 5 or 10 years for the actual usage (often not the initially expected usage) for a standards track or experimental protocol to emerge. So premature declaration taht something is historic can do actual damage. Mykyta Yevstifeyev On 3/3/2011 10:28 AM, Mykyta Yevstifeyev wrote: Joel, I agree with you that it is really hard and even impossible to determine what is going on in the Internet regarding some technology, protocol, etc. If we set the impossible criterion for the Historic documents, this will really make very few sense. So, as I have been pointed out, I find removing the regulation about 'out-of-use' technology at all quite acceptable. Do you agree? And as for the comment from Dave. 03.03.2011 17:18, Dave CROCKER wrote: On 3/3/2011 7:11 AM, Joel M. Halpern wrote: The first point, to echo Andrew Sullivan, is that even if a protocol is in use on the public Internet, it is not always easy to detect. ... The second point is that enterprise uses and other private network uses are still valid uses. The fact that a protocol may be used only inside a virtual private network, or only inside a corporate data center, or in only within a military facility, does NOT mean that it is not used. Such limited use is still valid use and should not result in our declaring something obsolete. +1 Declaration of historic needs to be based on affirmative data. The declaration is actually only important to make for protocols that are known to be problematic. This is already covered by the 'deprecated' criteria in my draft. All the best, Mykyta Yevstifeyev Issuing a declaration for mere non-use is a matter of convenience, not need, IMO. d/ 03.03.2011 17:11, Joel M. Halpern wrote: There are, in my opinion, two problems with Mr. Yevstifeyev's assertion below that it is easy to determine when things are out of use. The first point, to echo Andrew Sullivan, is that even if a protocol is in use on the public Internet, it is not always easy to detect. It may be used in only some portions of the net. It may be used inside some other protocol that makies detection ahrder. The second point is that enterprise uses and other private network uses are still valid uses. The fact that a protocol may be used only inside a virtual private network, or only inside a corporate data center, or in only within a military facility, does NOT mean that it is not used. Such limited use is still valid use and should not result in our declaring something obsolete. Yours, Joel On 3/3/2011 4:27 AM, Mykyta Yevstifeyev wrote: Hello Eliot, Thank you for reading the document. Pleas efind some comments in-line. 2011/3/2, Eliot Learl...@cisco.com: ... I bring to your attention RFC-4450, in which we made a bulk status change of a bunch of PS to Historic precisely because we couldn't find anyone using those protocols. However, such observations are imprecise. For one, it is hard to observe what is going on on the Internet, and those who do don't usually share their data (there is some, but it is often regionally based, like the GINORMOUS store at ETHZ). Another issue is that a protocol that is not detectable on the Internet might be in use on private networks. When we say 'out-of-use' we consider the usage of something in the overall Internet. It is mostly not very difficault to find this out via those people who take part in the IETF. ... ___ Ietf mailing list
Re: Request for review of draft-yevstifeyev-genarea-historic-03
03.03.2011 17:59, RJ Atkinson wrote: Earlier, Joel Halpern wrote: The first point, to echo Andrew Sullivan, is that even if a protocol is in use on the public Internet, it is not always easy to detect. It may be used in only some portions of the net. It may be used inside some other protocol that makes detection ahrder. The second point is that enterprise uses and other private network uses are still valid uses. The fact that a protocol may be used only inside a virtual private network, or only inside a corporate data center, or in only within a military facility, does NOT mean that it is not used. Such limited use is still valid use and should not result in our declaring something obsolete. +1 to all of the above. As an example of the 2nd point above, earlier this decade the IESG erroneously reclassified RFC-1108 as Historic, apparently because they perceived it as not in use, even though it probably has more deployment and broader implementation now than 10 or 15 years ago. I'd like to ask how was it done, what procedures were used. And then look at RFC 4450, that uses other procedures for the same purpose. RFC 6037. eg. has the third choice. Should this continue? Here are 3 examples of modern products that support it: - Cisco IOS still supports RFC-1108, and has since the early 1990s. http://www.cisco.com/en/US/docs/ios/sec_data_plane/configuration/guide/sec_cfg_ip_security.html - Oracle (Sun) Solaris supports it, although they call it RIPSO. http://download.oracle.com/docs/cd/E19109-01/tsolaris8/816-1048/6m7gaddht/index.html - Trusted Linux/SE Linux also supports it. http://www.nsa.gov/research/selinux/list-archive/0605/thread_body18.shtml A third issue is that one of the apparent objectives is to reclassify a large number of RFCs that pre-date the IETF, and/or that were NOT published as IETF track RFCs. What we now call the Individual Submission track is the oldest track of all, since the IETF did not even exist until the middle 1980s, yet RFCs go back to 1969. Fourth, it is not appropriate for the IETF (or IESG) to reclassify any RFC that was not originally published as an IETF track RFC. The IETF simply lacks authority to reclassify such RFCs, although if the original author explicitly consents in advance to the reclassification (e.g. recently for MD2/MD4) this can be done. This is particularly true for the older RFCs that appear to be the target of this I-D and I-D author. For those older RFCs, it isn't even the case the the IETF Trust (or ISoc) hold any well defined rights. I agree with you here - IETF does not have the authority on the RFCs from other streams. For IAB, IRTF and IS streams it is clear, but as for pre-IETF ones? I also agree that IETF has the authority to define procedures for their own RFCs - in this way we should permit other streams' authorities do this on their own discretion. So the document also needs to clearly say that only IETF track RFCs are within the scope of this document, and that the document does not apply to RFCs which pre-date the IETF existence or that were not published as IETF-track RFCs. Agreed - I'll make the corresponding changes. Mykyta Yevstifeyev Yours, Ran ___ 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: Request for review of draft-yevstifeyev-genarea-historic-03
Hello Eliot, Thank you for reading the document. Pleas efind some comments in-line. 2011/3/2, Eliot Lear l...@cisco.com: Thank you for the opportunity to review this draft. I do so merely as an individual. It might be a good idea to provide some additional clarity on when to market something Historic, but your document requires a bit of clarity on its own as to what your motivating logic is. Why, for instance, do you believe it is important to split deprecated and obsoleted? In my opinion, the term 'obsoleted' means that it is out-of-use while 'deprected' means that it not recommended to be used and implemented because of some reason. Also, Scott had to choose some language to describe Historic. He probably did not mean for us to get hung up on the word superceded, a problem from which this draft seems to suffer. RFC 2026 says that Historic is for RFCs that has been superseded by a more recent specification or is for any other reason considered to be obsolete. However some recent observations have shown that everyone has their own thoughts on what the word 'obsolete' means. Some think that it is the synonym yo the word 'superseded' while other consider it to be 'deprectaed' as well. I propose to provide the clarity on this terms. I bring to your attention RFC-4450, in which we made a bulk status change of a bunch of PS to Historic precisely because we couldn't find anyone using those protocols. However, such observations are imprecise. For one, it is hard to observe what is going on on the Internet, and those who do don't usually share their data (there is some, but it is often regionally based, like the GINORMOUS store at ETHZ). Another issue is that a protocol that is not detectable on the Internet might be in use on private networks. When we say 'out-of-use' we consider the usage of something in the overall Internet. It is mostly not very difficault to find this out via those people who take part in the IETF. You've also given me the idea to mention the criterion for 'obsoleted' documents such as it is the retired or revised Internet standard, per RFC 2026. I'll make this change in my working copy of the draft. All the best, Mykyta Yevstifeyev Eliot ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Request for review of draft-yevstifeyev-genarea-historic-03
On Thu, Mar 03, 2011 at 11:27:21AM +0200, Mykyta Yevstifeyev wrote: 2011/3/2, Eliot Lear l...@cisco.com: imprecise. For one, it is hard to observe what is going on on the Internet, and those who do don't usually share their data (there is some, but it is often regionally based, like the GINORMOUS store at ETHZ). Another issue is that a protocol that is not detectable on the Internet might be in use on private networks. When we say 'out-of-use' we consider the usage of something in the overall Internet. It is mostly not very difficault to find this out via those people who take part in the IETF. If I read the above exchange correctly, Eliot Lear points out that it is difficult to observe what's going on all over the Internet, on the premise that the Internet is a bunch of interconnected networks and you can't be sure that you've actually observed all of those networks (some of which might be closed to you). In response, Mykyta Yevstifeyev says, Oh, that's not hard. People at the IETF know. This has no supporting argument for it at all. I would like to suggest that the former position is the better one to take. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Request for review of draft-yevstifeyev-genarea-historic-03
03.03.2011 13:56, Andrew Sullivan wrote: On Thu, Mar 03, 2011 at 11:27:21AM +0200, Mykyta Yevstifeyev wrote: 2011/3/2, Eliot Learl...@cisco.com: imprecise. For one, it is hard to observe what is going on on the Internet, and those who do don't usually share their data (there is some, but it is often regionally based, like the GINORMOUS store at ETHZ). Another issue is that a protocol that is not detectable on the Internet might be in use on private networks. When we say 'out-of-use' we consider the usage of something in the overall Internet. It is mostly not very difficault to find this out via those people who take part in the IETF. If I read the above exchange correctly, Eliot Lear points out that it is difficult to observe what's going on all over the Internet, on the premise that the Internet is a bunch of interconnected networks and you can't be sure that you've actually observed all of those networks (some of which might be closed to you). In response, Mykyta Yevstifeyev says, Oh, that's not hard. People at the IETF know. This has no supporting argument for it at all. I would like to suggest that the former position is the better one to take. Andrew, in this case how do you propose to formulate this? Mykyta A ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Request for review of draft-yevstifeyev-genarea-historic-03
There are, in my opinion, two problems with Mr. Yevstifeyev's assertion below that it is easy to determine when things are out of use. The first point, to echo Andrew Sullivan, is that even if a protocol is in use on the public Internet, it is not always easy to detect. It may be used in only some portions of the net. It may be used inside some other protocol that makies detection ahrder. The second point is that enterprise uses and other private network uses are still valid uses. The fact that a protocol may be used only inside a virtual private network, or only inside a corporate data center, or in only within a military facility, does NOT mean that it is not used. Such limited use is still valid use and should not result in our declaring something obsolete. Yours, Joel On 3/3/2011 4:27 AM, Mykyta Yevstifeyev wrote: Hello Eliot, Thank you for reading the document. Pleas efind some comments in-line. 2011/3/2, Eliot Learl...@cisco.com: ... I bring to your attention RFC-4450, in which we made a bulk status change of a bunch of PS to Historic precisely because we couldn't find anyone using those protocols. However, such observations are imprecise. For one, it is hard to observe what is going on on the Internet, and those who do don't usually share their data (there is some, but it is often regionally based, like the GINORMOUS store at ETHZ). Another issue is that a protocol that is not detectable on the Internet might be in use on private networks. When we say 'out-of-use' we consider the usage of something in the overall Internet. It is mostly not very difficault to find this out via those people who take part in the IETF. ... ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Request for review of draft-yevstifeyev-genarea-historic-03
On 3/3/2011 7:11 AM, Joel M. Halpern wrote: The first point, to echo Andrew Sullivan, is that even if a protocol is in use on the public Internet, it is not always easy to detect. ... The second point is that enterprise uses and other private network uses are still valid uses. The fact that a protocol may be used only inside a virtual private network, or only inside a corporate data center, or in only within a military facility, does NOT mean that it is not used. Such limited use is still valid use and should not result in our declaring something obsolete. +1 Declaration of historic needs to be based on affirmative data. The declaration is actually only important to make for protocols that are known to be problematic. Issuing a declaration for mere non-use is a matter of convenience, not need, IMO. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Request for review of draft-yevstifeyev-genarea-historic-03
On 3/3/11 8:18 AM, Dave CROCKER wrote: On 3/3/2011 7:11 AM, Joel M. Halpern wrote: The first point, to echo Andrew Sullivan, is that even if a protocol is in use on the public Internet, it is not always easy to detect. ... The second point is that enterprise uses and other private network uses are still valid uses. The fact that a protocol may be used only inside a virtual private network, or only inside a corporate data center, or in only within a military facility, does NOT mean that it is not used. Such limited use is still valid use and should not result in our declaring something obsolete. +1 Declaration of historic needs to be based on affirmative data. The declaration is actually only important to make for protocols that are known to be problematic. Issuing a declaration for mere non-use is a matter of convenience, not need, IMO. And, further, probably it would not be worth the trouble to investigate whether a protocol is not actually used (proving a negative is hard). Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Request for review of draft-yevstifeyev-genarea-historic-03
Joel, I agree with you that it is really hard and even impossible to determine what is going on in the Internet regarding some technology, protocol, etc. If we set the impossible criterion for the Historic documents, this will really make very few sense. So, as I have been pointed out, I find removing the regulation about 'out-of-use' technology at all quite acceptable. Do you agree? And as for the comment from Dave. 03.03.2011 17:18, Dave CROCKER wrote: On 3/3/2011 7:11 AM, Joel M. Halpern wrote: The first point, to echo Andrew Sullivan, is that even if a protocol is in use on the public Internet, it is not always easy to detect. ... The second point is that enterprise uses and other private network uses are still valid uses. The fact that a protocol may be used only inside a virtual private network, or only inside a corporate data center, or in only within a military facility, does NOT mean that it is not used. Such limited use is still valid use and should not result in our declaring something obsolete. +1 Declaration of historic needs to be based on affirmative data. The declaration is actually only important to make for protocols that are known to be problematic. This is already covered by the 'deprecated' criteria in my draft. All the best, Mykyta Yevstifeyev Issuing a declaration for mere non-use is a matter of convenience, not need, IMO. d/ 03.03.2011 17:11, Joel M. Halpern wrote: There are, in my opinion, two problems with Mr. Yevstifeyev's assertion below that it is easy to determine when things are out of use. The first point, to echo Andrew Sullivan, is that even if a protocol is in use on the public Internet, it is not always easy to detect. It may be used in only some portions of the net. It may be used inside some other protocol that makies detection ahrder. The second point is that enterprise uses and other private network uses are still valid uses. The fact that a protocol may be used only inside a virtual private network, or only inside a corporate data center, or in only within a military facility, does NOT mean that it is not used. Such limited use is still valid use and should not result in our declaring something obsolete. Yours, Joel On 3/3/2011 4:27 AM, Mykyta Yevstifeyev wrote: Hello Eliot, Thank you for reading the document. Pleas efind some comments in-line. 2011/3/2, Eliot Learl...@cisco.com: ... I bring to your attention RFC-4450, in which we made a bulk status change of a bunch of PS to Historic precisely because we couldn't find anyone using those protocols. However, such observations are imprecise. For one, it is hard to observe what is going on on the Internet, and those who do don't usually share their data (there is some, but it is often regionally based, like the GINORMOUS store at ETHZ). Another issue is that a protocol that is not detectable on the Internet might be in use on private networks. When we say 'out-of-use' we consider the usage of something in the overall Internet. It is mostly not very difficault to find this out via those people who take part in the IETF. ... ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Request for review of draft-yevstifeyev-genarea-historic-03
No, I do not agree with you. Our current definition for historic, and our current choices for when to move things, have worked sufficiently well. I have not seen any evidence that there is a problem that needs solving. I have also not seen any evidence that the changes you propose to the definitions would help anything. Yes, there are problems with our current definitions. Those problems serve to keep us from declaring something historic when we shouldn't. They do, as a side effect, make it harder to declare things historic even if they actually are? I will even agree that there is a small cost to that. Users of our standards may sometimes think some things are relevant that aren't. But changing the definitions to make it easier to change the status does not actually change the problem. The problem is that it is hard for anyone (the IETF, vendors, operators) to reliably know what is actually in use. Yours, Joel PS: I have actually noticed with several specifications I worked with that it can easily take 5 or 10 years for the actual usage (often not the initially expected usage) for a standards track or experimental protocol to emerge. So premature declaration taht something is historic can do actual damage. On 3/3/2011 10:28 AM, Mykyta Yevstifeyev wrote: Joel, I agree with you that it is really hard and even impossible to determine what is going on in the Internet regarding some technology, protocol, etc. If we set the impossible criterion for the Historic documents, this will really make very few sense. So, as I have been pointed out, I find removing the regulation about 'out-of-use' technology at all quite acceptable. Do you agree? And as for the comment from Dave. 03.03.2011 17:18, Dave CROCKER wrote: On 3/3/2011 7:11 AM, Joel M. Halpern wrote: The first point, to echo Andrew Sullivan, is that even if a protocol is in use on the public Internet, it is not always easy to detect. ... The second point is that enterprise uses and other private network uses are still valid uses. The fact that a protocol may be used only inside a virtual private network, or only inside a corporate data center, or in only within a military facility, does NOT mean that it is not used. Such limited use is still valid use and should not result in our declaring something obsolete. +1 Declaration of historic needs to be based on affirmative data. The declaration is actually only important to make for protocols that are known to be problematic. This is already covered by the 'deprecated' criteria in my draft. All the best, Mykyta Yevstifeyev Issuing a declaration for mere non-use is a matter of convenience, not need, IMO. d/ 03.03.2011 17:11, Joel M. Halpern wrote: There are, in my opinion, two problems with Mr. Yevstifeyev's assertion below that it is easy to determine when things are out of use. The first point, to echo Andrew Sullivan, is that even if a protocol is in use on the public Internet, it is not always easy to detect. It may be used in only some portions of the net. It may be used inside some other protocol that makies detection ahrder. The second point is that enterprise uses and other private network uses are still valid uses. The fact that a protocol may be used only inside a virtual private network, or only inside a corporate data center, or in only within a military facility, does NOT mean that it is not used. Such limited use is still valid use and should not result in our declaring something obsolete. Yours, Joel On 3/3/2011 4:27 AM, Mykyta Yevstifeyev wrote: Hello Eliot, Thank you for reading the document. Pleas efind some comments in-line. 2011/3/2, Eliot Learl...@cisco.com: ... I bring to your attention RFC-4450, in which we made a bulk status change of a bunch of PS to Historic precisely because we couldn't find anyone using those protocols. However, such observations are imprecise. For one, it is hard to observe what is going on on the Internet, and those who do don't usually share their data (there is some, but it is often regionally based, like the GINORMOUS store at ETHZ). Another issue is that a protocol that is not detectable on the Internet might be in use on private networks. When we say 'out-of-use' we consider the usage of something in the overall Internet. It is mostly not very difficault to find this out via those people who take part in the IETF. ... ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Request for review of draft-yevstifeyev-genarea-historic-03
Earlier, Joel Halpern wrote: The first point, to echo Andrew Sullivan, is that even if a protocol is in use on the public Internet, it is not always easy to detect. It may be used in only some portions of the net. It may be used inside some other protocol that makes detection ahrder. The second point is that enterprise uses and other private network uses are still valid uses. The fact that a protocol may be used only inside a virtual private network, or only inside a corporate data center, or in only within a military facility, does NOT mean that it is not used. Such limited use is still valid use and should not result in our declaring something obsolete. +1 to all of the above. As an example of the 2nd point above, earlier this decade the IESG erroneously reclassified RFC-1108 as Historic, apparently because they perceived it as not in use, even though it probably has more deployment and broader implementation now than 10 or 15 years ago. Here are 3 examples of modern products that support it: - Cisco IOS still supports RFC-1108, and has since the early 1990s. http://www.cisco.com/en/US/docs/ios/sec_data_plane/configuration/guide/sec_cfg_ip_security.html - Oracle (Sun) Solaris supports it, although they call it RIPSO. http://download.oracle.com/docs/cd/E19109-01/tsolaris8/816-1048/6m7gaddht/index.html - Trusted Linux/SE Linux also supports it. http://www.nsa.gov/research/selinux/list-archive/0605/thread_body18.shtml A third issue is that one of the apparent objectives is to reclassify a large number of RFCs that pre-date the IETF, and/or that were NOT published as IETF track RFCs. What we now call the Individual Submission track is the oldest track of all, since the IETF did not even exist until the middle 1980s, yet RFCs go back to 1969. Fourth, it is not appropriate for the IETF (or IESG) to reclassify any RFC that was not originally published as an IETF track RFC. The IETF simply lacks authority to reclassify such RFCs, although if the original author explicitly consents in advance to the reclassification (e.g. recently for MD2/MD4) this can be done. This is particularly true for the older RFCs that appear to be the target of this I-D and I-D author. For those older RFCs, it isn't even the case the the IETF Trust (or ISoc) hold any well defined rights. So the document also needs to clearly say that only IETF track RFCs are within the scope of this document, and that the document does not apply to RFCs which pre-date the IETF existence or that were not published as IETF-track RFCs. Yours, Ran ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Request for review of draft-yevstifeyev-genarea-historic-03
--On Thursday, March 03, 2011 10:41 -0500 Joel M. Halpern j...@joelhalpern.com wrote: No, I do not agree with you. Our current definition for historic, and our current choices for when to move things, have worked sufficiently well. I have not seen any evidence that there is a problem that needs solving. I have also not seen any evidence that the changes you propose to the definitions would help anything. Yes, there are problems with our current definitions. Those problems serve to keep us from declaring something historic when we shouldn't. ... I pretty much agree with Joel (and others), but suggest that there is another, better, solution to this problem (or at least the version of it I understand). Ultimately, whether under 2026 or your proposal, there are ultimately two reasons for making something historic (this is different from your Section 2 list; more about that below): (i) No one is using the protocol and no one cares any more about it. (ii) The protocol contains elements or defects that, in retrospect, make it dangerous. With the exceptions that are already covered by the existing Obsoleted by category, the first is, as Joel points out, hard to identify and get agreement about. As other have suggested, no one cares means no one cares, i.e., that putting significant energy into trying to identify and classify those documents is probably not a good use of community resources. Reaching formal agreement about the second effectively requires publication of an RFC that describes the problem, at which point Obsoletes can be used and there is no reason to develop new procedures. For the few cases that are actually worth it, we do have the ability to approve and publish documents that identify a protocol as not recommended. We don't use stand-alone Applicability Statements very often any more, especially for that purpose, but, if a particular protocol deserved the effort, it would be lots easier --and lots less wear and tear on the community in review and the RFC Editor in publication-- to write an I-D that said the protocol described in RFC has turned out to be a bad idea because... Its use is Not Recommended. than to republish or historicize as you suggest. Trying to turn Historic even more into an ambiguous synonym for old, unused, uninteresting, or bad just does not strike me as a good idea, especially with the possibility of applicability statements that are orthogonal to maturity level classification on the books. FWIW, your republication as historic approach is not feasible for documents more than a few years old. The rules about information to be included in RFCs, how that information is structured, IPR statements, etc., have evolved over the years. Permitting republication of an old RFC in facsimile would often break those rules. Figuring out the mechanisms for getting around that would cost far more in resources than the community is, I believe, willing to invest. If I thought that another iteration would improve this proposal enough to make it acceptable, I'd recommend that your Section 3.1 should be required to address republication of new documents with identical technical content with old ones in the light of those rules. But I don't think that is the case. On a note of sadness rather than as a sales pitch, the community has discussed several ways of dealing with what I think it the underlying problem you are trying to address -- getting readers of RFCs the most up to date information possible about those documents and the status of the protocols they describe. At least some of them would have worked better than this, with less load on the community. For whatever reasons, none of them have achieved sufficient consensus to move forward. Against that background, I can't imagine what would cause us to adopt a weaker proposal that required more work. regards, john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Request for review of draft-yevstifeyev-genarea-historic-03
On Thu, Mar 03, 2011 at 04:57:39PM +0200, Mykyta Yevstifeyev wrote: Andrew, in this case how do you propose to formulate this? Mykyta Not? The goal you appear to have in this is to make the RFC series tidy. As the co-chair of a WG with an old and decidedly messy set of protocol documents, I understand and value that desire. But as the same co-chair, I have to tell you that any assertion that some feature (even if you think it is a dumb one that nobody ever should have used anywhere for any reason) is unused is the sort of thing that leads you into discussions of angels and pin-heads, trees falling in forests with no-one to hear, and so no. Heck, over in DNS land, we are barely willing to rely on features of the protocol if we know that there is a 10 year old but once widely-deployed piece of software that violated or didn't implement that feature. Setting up criteria that are formally nice but for which it is impossible to construct a test is a bad idea. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Request for review of draft-yevstifeyev-genarea-historic-03
Thank you for the opportunity to review this draft. I do so merely as an individual. It might be a good idea to provide some additional clarity on when to market something Historic, but your document requires a bit of clarity on its own as to what your motivating logic is. Why, for instance, do you believe it is important to split deprecated and obsoleted? Also, Scott had to choose some language to describe Historic. He probably did not mean for us to get hung up on the word superceded, a problem from which this draft seems to suffer. I bring to your attention RFC-4450, in which we made a bulk status change of a bunch of PS to Historic precisely because we couldn't find anyone using those protocols. However, such observations are imprecise. For one, it is hard to observe what is going on on the Internet, and those who do don't usually share their data (there is some, but it is often regionally based, like the GINORMOUS store at ETHZ). Another issue is that a protocol that is not detectable on the Internet might be in use on private networks. Eliot ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
