RE: [newtrk] Re: List of Old Standards to be retired
[mailto:[EMAIL PROTECTED] On Behalf Of Eric Rosen Eliot Even if someone *has* implemented the telnet TACACS user Eliot option, would a user really want to use it? Eric I don't know. Do you? Eliot Yes, I do. Many of us do. And that's the point. I'm sure you think you know, but I don't know that you know, which means that a lot of people have to waste a lot of time preventing you from doing damage. Are you also the one who knows that OSPF demand circuits are never used? . newtrk Should the fact that someone uses something mean that it should be considered a standard? If so the MARID group was a mistake, SPF should simply have been accepted as is without discussion. Lets do a thought experiment, should EBCDIC be considered a 'standard'? It is certainly used but there is no imaginable sense in which anyone would ever suggest building on top of it. The whole point of standards is that you are narrowing down the range of design choices. That means discarding standards that are of antiquarian interest only. The number of Internet users is now approaching or may have reached a billion. Please make an effort to recognize your responsibility to the 99% of those users for which the debate on legacy technology is irrelevant but have some very real and very urgent issues with the technology they are faced with using. What is meant by taking a spec off standard is that it will no longer be maintained. This means no more updates, but it also means that future specs will not be constrained by it either. This is important for two reasons, first there is simply too much junk that is too badly organized that people demand backwards compatibility for. The early ASRG discussions had folk prattling on about the need to continue to support UUCP. The second reason is the opposite of the first, there are some very important dependencise that should be maintained but are not because they get lost in the sheer volume of irrelevant cruft. As Larry King's first boss told him: This is a communications business. Like it or not the Internet is now the Web and the influence any party can have is dependent on their ability to communicate a coherent message. The IETF has been unable to communicate a coherent message about its work. Take a look at the IETF web site and compare it to the W3C and OASIS sites. Finding out what the IETF has done through the web site takes a lot of effort. W3C and OASIS tell you their list of achievements straight up on their front door. Each one of the crufty irrelevant specicfications is diluting the IETF message. If you continue to tell people that backwards compatibility with obsolete mainframe terminals based on specifications from the punch card age is important while failing to tell people that stopping the current Internet crime wave is important then it is very easy for people to dismiss you. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [newtrk] Why old-standards (Re: List of Old Standards to be retired)
On Fri, Dec 17, 2004 11:47:10AM -0500, John C Klensin allegedly wrote: Harald, while I agree in principle, I would suggest that some of the comments Eric, Bill, and others have pointed out call for the beginnings of an evaluation of your experiment. I further suggest that evaluation is appropriate at almost any time, once data start to come in. I hope it can be a relatively sloppy process. Let's not insist on perfection. An RFC is identified as possibly outdated, the suggestion is posted, and people respond -- just as is happening now. Sometimes the suggestions are wrong. The experiment is going fine as long as you realize it's an experiment in process as much as discovering how much cleaning is possible. My recent response to Pekka's analysis of the CIDR documents is one suggestion about where such an evaluation might lead. And, of course, this whole firestorm of discussion on the IETF list, while a welcome distraction from hairsplitting debates about administrative structures, adds strength to the position of those who argued in newtrk that this effort might not be worth the amount of community energy it would take up. Yup. The jury is still out on whether it's worthwhile. Let's be forgiving of the first attempt, and let it run for a little longer and see if it becomes more polished. Scott ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Why old-standards (Re: List of Old Standards to be retired)
Date: Fri, 17 Dec 2004 13:16:25 +0100 From: Harald Tveit Alvestrand [EMAIL PROTECTED] Subject: Why old-standards (Re: List of Old Standards to be retired) Message-ID: [EMAIL PROTECTED] In 1994, the IETF community resolved to make the following procedure into IETF law through RFC 1602: When a standards-track specification has not reached the Internet Standard level but has remained at the same status level for twenty-four (24) months, and every twelve (12) months thereafter until the status is changed, the IESG shall review the viability of the standardization effort responsible for that specification. Following each such review, the IESG shall approve termination or continuation of the development. This decision shall be communicated to the IETF via electronic mail to the IETF mailing list, to allow the Internet community an opportunity to comment. This provision is not intended to threaten a legitimate and active Working Group effort, but rather to provide an administrative mechanism for terminating a moribund effort. In 1996, through RFC 2026, it reconfirmed that decision. By the end of 1994, RFCs through 1735 had been published (plus or minus a few stragglers). Currently, we have more than double that number, and it is likely that the acceleration will continue. In 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003 and 2004, various people cricticized the IESG for not following the process as written; the standard answer was this is not the most important thing for the IESG to be doing. What the IETF community may have thought to be feasible in 1994 evidently turned out not to be practical. I suspect that there are several contributing issues: 1. annual review of hundreds or thousands of standards in an organization comprised primarily of volunteers is not practical. IEEE had, in the mid-90s, a 5-year review policy (as I understand it, tied to an ANSI cycle tied to an ISO cycle), and was rather far behind in its efforts to review (and reaffirm, supersede, or obsolete) old standards (some which were still deemed useful had vacuum-tube circuit diagrams as examples of implementation). The effort required by the review period needs to be consistent with the availability of qualified and motivated worker bees that will perform the review. 2. RFC 2026 specifies some specific requirements for advancement along the Standards Track. In a few cases (e.g. where a Proposed Standard includes an unencumbered reference implementation) the combination of various forces (market size, legal issues, etc.) may result in multiple interoperable implementations based in part on a single code base derived from a single (implicit or explicit) license. As I understand RFC 2026 section 4.1.2, it precludes such a case from advancing to Draft Standard (i.e. there is no provision for IESG or IAB waiver for the two independent implementations requirement). 3. In many cases, once a Proposed Standard has been developed by a WG, the WG's official work is finished and the WG is disbanded. That leaves no responsible group to field questions, take on the tasks of documenting independent interoperable implementations (as required for advancement to Draft Standard) etc. And that's still true. Beware the implicit positive feedback path (no, that's NOT a good thing!); as the backlog of RFCs needing review grows, and the rate at which that backlog grows accelerates, a we have more important things to do attitude quickly results in the enormity of the task growing beyond the ability to cope with it. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Why old-standards (Re: List of Old Standards to be retired)
Hi - From: Bruce Lilly [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, December 20, 2004 10:49 AM Subject: Re: Why old-standards (Re: List of Old Standards to be retired) ... 1. annual review of hundreds or thousands of standards in an organization comprised primarily of volunteers is not practical. IEEE had, in the mid-90s, a 5-year review policy (as I understand it, tied to an ANSI cycle tied to an ISO cycle), and was rather far behind in its efforts to review (and reaffirm, supersede, or obsolete) old standards (some which were still deemed useful had vacuum-tube circuit diagrams as examples of implementation). The effort required by the review period needs to be consistent with the availability of qualified and motivated worker bees that will perform the review. ... Obviously, YMMV. In INCITS T3, the periodic review of ISO standards didn't require too much effort. The ISO periodic review simply required answering a very short list of mostly yes-no questions, like Is this standard in use in industry, concluded with a retain/revise/withdraw recommendation. With the exception of the withdrawal of ASN.1 in favor of what many of us no-so-jokingly called ASN.2, it worked fairly well, at least in the areas where I was active. However, I think it's a mistake to compare this effort to the ISO periodic review. Procedurally, this is much more comparable to the rules for progressing from CD / FCD to DIS (and eventually to IS). Randy ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Why old-standards (Re: List of Old Standards to be retired)
--On lørdag, desember 18, 2004 13:04:52 -0500 William Allen Simpson [EMAIL PROTECTED] wrote: So, here's my promise to you. I'll track down McGregor, and we'll write something up. I will work on moving my Proposed Standards, assuming that the IESG is actually _interested_ in doing its job. The proof will be in the pudding. In earlier times, I expected to go from internet-draft to Proposed Standard in 2 IETF meetings, and to Full Standard in under 1 year on average, 2 years for extremely controversial items. Did you ever get what you expected? Yes, certainly. And when I didn't, I helped lead the effort to reform the structure of the IETF That worked for a couple more years. (Without reorganization, we couldn't even have a IPSec WG. Steve Kent prevented it.) The reason why I was asking was that I've heard statements that we were much faster before a number of times, while I've also heard lots of stories of things that took years to accomplish before. So I'd rather ask again, explicitly: - Which standards did you push from first I-D to PS in 2 IETF meetings? - Which standards (apart from the ones that were born that way) reached Full Standard 1 year after going to PS? At least we'd have a common understanding of the term before... Harald ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Historic (Re: List of Old Standards to be retired)
--On lørdag, desember 18, 2004 11:51:56 -0800 Bob Braden [EMAIL PROTECTED] wrote: * * This must be some new redefinition of the meaning of a Historic RFC. * In the past, it meant don't do it this way anymore, we no longer * recommend it, there's another way to accomplish the same goal. * So, for the PPP items listed, what's the better way to accomplish the * same goal? * * No, it's the old definition of Historic. * Harald, I am puzzled by your comment. I believe that Bill Simpson is correct about the old (historic) definition of Historic category, defined by Jon Postel. Jon believed that if you have a standard defining interoperability, it is ALWAYS a standard unless there is a compelling reason to warn people away. The IETF can change the meaning of Historic, but let's not change history. With all respect to Jon Postel - the IETF's meaning of Historic is defined by reference to IETF consensus, not to Jon Postel's opinion. We may be confused by different meanings of old - I was referring to 1994. Shows how young I am, I guess :-) Harald ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [newtrk] Re: Historic (Re: List of Old Standards to be retired)
--On Sunday, December 19, 2004 12:39 PM +0100 Harald Tveit Alvestrand [EMAIL PROTECTED] wrote: --On lørdag, desember 18, 2004 11:51:56 -0800 Bob Braden [EMAIL PROTECTED] wrote: * * This must be some new redefinition of the meaning of a Historic RFC. * In the past, it meant don't do it this way anymore, we no longer * recommend it, there's another way to accomplish the same goal. * So, for the PPP items listed, what's the better way to accomplish the * same goal? * * No, it's the old definition of Historic. * Harald, I am puzzled by your comment. I believe that Bill Simpson is correct about the old (historic) definition of Historic category, defined by Jon Postel. Jon believed that if you have a standard defining interoperability, it is ALWAYS a standard unless there is a compelling reason to warn people away. The IETF can change the meaning of Historic, but let's not change history. With all respect to Jon Postel - the IETF's meaning of Historic is defined by reference to IETF consensus, not to Jon Postel's opinion. We may be confused by different meanings of old - I was referring to 1994. Shows how young I am, I guess :-) Harald, I don't think it is because of your tender age, but it seems to me that defined by reference to IETF consensus puts us into dangerous territory. The justification for this de-crufting effort seems to me to be (i) finding a relatively lightweight way to get what we are actually doing aligned with the requirements of 2026 and (ii) begin more clear to relative outsiders about just what we intend and are encouraging. That suggests two things to me... (1) A definition, whether in 2026 or earlier, or developed by some newer IETF consensus process, is useful only if the definition itself is absolutely clear. We aren't there any more, if ever we were. The language in 2026 isn't clear enough to prevent several of us from disagreeing about what it really means. There hasn't been a clear statement and a consensus call on it in the last decade or more. We aren't making progress if our definition by IETF consensus requires a royal assertion of what that consensus is, without a clear basis in IETF consideration. (2) Part of what has gotten us into this mess is that we got rid of the old required/ recommended/ not recommended categories that were orthogonal to standards maturity levels. Once upon a time, we could say X is a standard because it is interoperable and widely deployed, but we have concluded that it stinks so no one should be implementing and relying on it. That is standard, not recommended.Too much of the discussions of the last few weeks feel to me like an attempt to conflate (or avoid conflating) Historic with Not recommended and that just doesn't work very well in the edge cases... and there are lots of edge cases. john ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [Old-standards] Re: [newtrk] List of Old Standards to be retired
John == John C Klensin [EMAIL PROTECTED] writes: John Harald, John Sorry, but I've got a procedural problem with this. I-Ds John can't obsolete anything, even I-Ds approved by the IESG. John While fiddle with the RFC Editor note in the John announcement... may be the usual reason for delay, we all John know that documents sometimes change significantly between John the last-published I-D and actual RFC publication. In John theory, the announcement could be posted, the IDR WG John membership could take a look at it and conclude the AD's RFC John Editor note does not reflect WG consensus, and an appeal of John the announcement could be filed. As far as I know, that has John never happened, but the procedures clearly permit it and I John can think of a case or two when maybe it should have. While John we have safeguards to prevent it, it is even possible that a John document inadvertently would change enough during the RFC John editing process that the WG would no longer believe it was John an appropriate replacement for the earlier document. I don't think everyone believes the procedures work this way. A while back, there was a discussion on wgchairs about when the timer started for a standard moving to draft standard. My interpretation of that discussion was that it was the protocol action message that established a new standard, not the publication of the RFC. Personally I don't care how it works. I see both the points you raise and the arguments in favor of the wgchairs discussion. To me, either way of doing things would be valid. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [newtrk] List of Old Standards to be retired
William == William Allen Simpson [EMAIL PROTECTED] writes: William John C Klensin wrote: Then these need the bad designation, not just the not really interesting any more one. And that, presumably, requires a 1828/1829 considered harmful document, or at least a paragraph and a place to put it. William Well, gosh and golly gee, I wrote an ISAKMP considered William harmful about 6 years ago, and the IESG -- for the first William time in its history -- ordered it removed from the William internet-drafts repository (saying the IETF wouldn't William publish anything critical of the IETF process). I wasn't following things closely enough at the time to have an opinion on what happened then. However I do have an opinion on the current process. Things change and sometimes improve. I'd like to think the IETF and the security area in particular are more open to criticism and to the realization that we may be wrong. I believe I have some evidence for this belief. There might be some reasons why it would be appropriate to remove a document from the ID repository--most of the ons I can think of have to do with copyright issues--but I don't think a document being critical of the IETF, its processes or technology would be such a justification today. --Sam ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: List of Old Standards to be retired
Eliot Lear wrote: If you see a document on the list below and you know it to be in use, would you please reply to this message indicating the RFC number, and whether you believe the doc should be advanced beyond proposed? Also, if you know of work to update anything on the list below, please include that. A note along these lines is generally sufficient to remove a document from the list below. I am a fairly good contact point for most things TELNET. Back in June 1999 the Application Area Directors, Keith Moore and Patrik Falstrom, performed a review of TELNET RFCs to move unused ones to HISTORIC. This was done in consultation with the subscribers to the [EMAIL PROTECTED] mailing list. All of the remaining Telnet options were determined to be implemented in various widely deployed implementations. RFC0698 Telnet extended ASCII option RFC0726 Remote Controlled Transmission and Echoing Telnet option RFC0727 Telnet logout option RFC0735 Revised Telnet byte macro option RFC0736 Telnet SUPDUP option RFC0749 Telnet SUPDUP-Output option RFC0779 Telnet send-location option RFC0885 Telnet end of record option RFC0927 TACACS user identification Telnet option RFC0933 Output marking Telnet option RFC0946 Telnet terminal location number option RFC1041 Telnet 3270 regime option RFC1043 Telnet Data Entry Terminal option: DODIIS implementation RFC1053 Telnet X.3 PAD option RFC1372 Telnet Remote Flow Control Option Since the requirement for moving to historic under the cruft draft is that it is not widely implemented, all of these options must remain. If there is desire to move these options to historic, then the guideline must be altered. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [newtrk] Why old-standards (Re: List of Old Standards to be retired)
John, Harald, while I agree in principle, I would suggest that some of the comments Eric, Bill, and others have pointed out call for the beginnings of an evaluation of your experiment. I further suggest that evaluation is appropriate at almost any time, once data start to come in. First a reminder of what the procedure for this experiment is, before we talk about modifying it: 1. Start with the list of RFCs prior to RFC 2001 and marked PS. 2. Remove all RFCs known to still be relevant where new implmenetations might be necessary. Be liberal in what we accept for removal purposes. 3. Take the list to the IETF and other relevant mailing lists so that as wide an audience as possible can have a say. 4. Present the list to the IETF and the NEWTRK WG in Minneapolis. 5. Here things depend on the state of the Johns draft. If it's ready and takes into account cruft, then we follow that procedure. Otherwise, extended WG last call, extended IETF last call, IESG consideration, and then take one of the following two steps: 6. Either reclassify documents as Historic and write up BCP. or Don't and write up failed experiment. This follows the WG milestones: Dec 04 If the consensus was to create a new RFC cleanup process then initiate a trial of the cleanup process based on the description in teh Internet Draft Mar 05 Determine if there is WG consensus tha the trial of the RFC cleanup process was successful enough to proceed to finalize the process. Jul 05 If there was WG consensus that the trial of the RFC cleanup process was successful submit an ID describing the process to IESG for publication as a BCP RFC Now to your points: 1. Nobody in the IETF *has* to participate in this experiment. The fewer who do, the more likely we'll end up with a substandard list, and the less likely the IESG will buy the list. We don't seem to be having this problem at the moment. 2. Changing the procedure should only be necessary if we can identify specific flaws in the procedure. The objections I hear right this very moment fall into two categories: [a] There's obviously a lot of trash out there so can't you just focus on that? [vjs, others] The working group agreed to Larry Masinter's suggestion that we make people take the most minimum step of having to send an email to request a document remain PS. [b] This whole effort is a waste of time, and you could do more damage than good. [braden, rosen, perhaps you] Other than stopping the procedure I agreed to carry out without WG consensus is not something I would consider short a family or health emergency. Eliot ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Why old-standards (Re: List of Old Standards to be retired)
--On fredag, desember 17, 2004 11:49:04 -0500 William Allen Simpson [EMAIL PROTECTED] wrote: So, here's my promise to you. I'll track down McGregor, and we'll write something up. I will work on moving my Proposed Standards, assuming that the IESG is actually _interested_ in doing its job. The proof will be in the pudding. In earlier times, I expected to go from internet-draft to Proposed Standard in 2 IETF meetings, and to Full Standard in under 1 year on average, 2 years for extremely controversial items. Did you ever get what you expected? ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [newtrk] Why old-standards (Re: List of Old Standards to be retired)
No disagreement on any of this. I was just responding to what I took to be suggestions that in-flight partial evaluation was inappropriate. john --On Saturday, 18 December, 2004 04:23 -0500 Scott W Brim [EMAIL PROTECTED] wrote: On Fri, Dec 17, 2004 11:47:10AM -0500, John C Klensin allegedly wrote: Harald, while I agree in principle, I would suggest that some of the comments Eric, Bill, and others have pointed out call for the beginnings of an evaluation of your experiment. I further suggest that evaluation is appropriate at almost any time, once data start to come in. I hope it can be a relatively sloppy process. Let's not insist on perfection. An RFC is identified as possibly outdated, the suggestion is posted, and people respond -- just as is happening now. Sometimes the suggestions are wrong. The experiment is going fine as long as you realize it's an experiment in process as much as discovering how much cleaning is possible. My recent response to Pekka's analysis of the CIDR documents is one suggestion about where such an evaluation might lead. And, of course, this whole firestorm of discussion on the IETF list, while a welcome distraction from hairsplitting debates about administrative structures, adds strength to the position of those who argued in newtrk that this effort might not be worth the amount of community energy it would take up. Yup. The jury is still out on whether it's worthwhile. Let's be forgiving of the first attempt, and let it run for a little longer and see if it becomes more polished. Scott ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Why old-standards (Re: List of Old Standards to be retired)
Harald Tveit Alvestrand wrote: --On fredag, desember 17, 2004 11:49:04 -0500 William Allen Simpson [EMAIL PROTECTED] wrote: So, here's my promise to you. I'll track down McGregor, and we'll write something up. I will work on moving my Proposed Standards, assuming that the IESG is actually _interested_ in doing its job. The proof will be in the pudding. In earlier times, I expected to go from internet-draft to Proposed Standard in 2 IETF meetings, and to Full Standard in under 1 year on average, 2 years for extremely controversial items. Did you ever get what you expected? Yes, certainly. And when I didn't, I helped lead the effort to reform the structure of the IETF That worked for a couple more years. (Without reorganization, we couldn't even have a IPSec WG. Steve Kent prevented it.) Sadly, the IETF changed from an organization where Vint Cerf, even as he was being criticized, could wear a bathing suit under his perpetual 3-piece wear. A sense of humor and camaraderie has been lost. -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [Old-standards] Re: [newtrk] List of Old Standards to be retired
On Thu, 16 Dec 2004, William Allen Simpson wrote: Folks, I took a look at the first posting, and was surprised at those where I'm personally knowledgable. RFC1378 The PPP AppleTalk Control Protocol (ATCP) It was widely implemented. I still use this. My $1000 HP LaserJet 4ML works fine, it hasn't run out its original cartridge, but I need appletalk for it. RFC1552 The PPP Internetworking Packet Exchange Control Protocol (IPXCP) RFC1553 Compressing IPX Headers Over WAN Media (CIPX) Again, widely implemented. Sure, IPX wasn't a very good protocol, but I'm aware of rather a large number of sites that still run it. Sure, Novell refused to divulge the contents of some of the fields, so we just had to carry undifferentiated bytes around, but it worked RFC1598 PPP in X.25 RFC1618 PPP over ISDN At one time, these were incredibly important in the 3rd world, and some parts of Europe and Japan. Is X.25 completely non-existant today? Heck, folks were running X.25 over ISDN D-channels, and those still exist on every PRI circuit There's certainly no illusion that these protocols are not being used in some part(s) of the universe. The question is really whether the IETF is interested in maintaining them any longer, and whether we expect significant new deployments of these protocols. Marking the document historic does not take it away from deployment -- marking document as historic doesn't hurt at all (except procedurally, when used as a normative reference, but then we have to do some work in any case if the reference was outdated). -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [Old-standards] Re: [newtrk] List of Old Standards to be retired
On Dec 16 2004, at 18:13 Uhr, Harald Tveit Alvestrand wrote: please read draft-ietf-newtrk-cruft-00.txt, in particular section 3.2, Ah good, I did. o Usage. A standard that is widely used should probably be left alone (better it should be advanced, but that is beyond the scope of this memo). Case closed (talking about 1618). Now Bill (the author) and I (and whoever else is into that corner of the technology attic) probably should start talking about whether to put in work to advance it. (This should have been done in 1999.) Gruesse, Carsten ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [Old-standards] Re: [newtrk] List of Old Standards to be retired
--On torsdag, desember 16, 2004 16:37:09 +0100 Eliot Lear [EMAIL PROTECTED] wrote: RFC1269 Definitions of Managed Objects for the Border Gateway Protocol: Version 3 Why would this be cruft? The BGP4 MIB was just recently approved... Good thing too. Take a good look at 1269. I don't think it would pass a MIB compiler test today. If you approved the BGP4-MIB, ought not that have obsoleted this guy? draft-ietf-idr-bgp4-mib-15.txt says: This document obsoletes RFC 1269 and RFC 1657. and the I-D tracker says: In State: Approved-announcement to be sent :: Point Raised - writeup needed which usually means that the shepherding AD needs to fiddle with the RFC Editor note in the announcement before sending it. It's one of the oddities of the way we process data that it's quite hard to know that something's already obsoleted between the time the obsoleting document is approved and the publication of the RFC. But I think the old-standards team can take RFC 1269 off the list with a note saying obsoleted by draft-ietf-idr-bgp4-mib, no action necessary. Good! Harald ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Why old-standards (Re: List of Old Standards to be retired)
Since the IETF list is obviously in rehash-of-WG-discussion mode today, I thought I'd contribute to the flamage, and rehash the logic behind the list of old standards that arrived in your inboxes a few days ago. Let's look back on what the IETF has decided previously. In 1994, the IETF community resolved to make the following procedure into IETF law through RFC 1602: When a standards-track specification has not reached the Internet Standard level but has remained at the same status level for twenty-four (24) months, and every twelve (12) months thereafter until the status is changed, the IESG shall review the viability of the standardization effort responsible for that specification. Following each such review, the IESG shall approve termination or continuation of the development. This decision shall be communicated to the IETF via electronic mail to the IETF mailing list, to allow the Internet community an opportunity to comment. This provision is not intended to threaten a legitimate and active Working Group effort, but rather to provide an administrative mechanism for terminating a moribund effort. In 1996, through RFC 2026, it reconfirmed that decision. In 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003 and 2004, various people cricticized the IESG for not following the process as written; the standard answer was this is not the most important thing for the IESG to be doing. And that's still true. In March 2004, having gone through yet another of those debates, I decided to see if I could write down some words on how this COULD be done without being an undue burden on the IESG. I recruited Eliot Lear to lead the effort, and together we created what's currently draft-ietf-newtrk-cruft-00. At the NEWTRK WG meeting in San Diego in August, I explained my motivation for pursuing this: This is the lightest-way process for doing what RFC 2026 mandates that I have been able to imagine. Now, we should either execute on that process, OR STOP TALKING ABOUT MOVING TO HISTORIC. The argument that Bob Braden is making, and you seem to be making - that we should not move crufty things to Historic at all - is a rational argument. But in that case, WE SHOULD UPDATE RFC 2026 TO SAY EXACTLY THAT. flame HAVING THE IETF CONTINUE TO SAY ONE THING AND DO ANOTHER IS NOT A GOOD THING FOR THE INTERNET. /flame OK, finished shouting. Eric and Bob: the NEWTRK list is waiting for your contribution on the principle involved, and your internet-draft suggesting the change to RFC 2026 to get rules aligned with reality. It's possible that that contribution will overturn the consensus of the WG to run this experiment. But in the meantime - please get out of the way and let us who want to try run the experiment and evaluate the result. Harald --On torsdag, desember 16, 2004 14:00:13 -0500 Eric Rosen [EMAIL PROTECTED] wrote: I see this exercise has already reached the point of absurdity. How can it possibly be worth anyone's time to look at each telnet option and determine whether it is deployed? What possible purpose could be achieved by changing the standards status of some telnet option? Is there some chance that someone is going to implement one of these by mistake somehow? A similar comment applies to the FDDI MIB. Are we trying to make sure that no one implements that MIB by mistake? Or that no one implements FDDI by mistake, just because he thinks there's an IETF standard about it? Let me echo Bob Braden's if it's not broken, why break it? query. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [newtrk] List of Old Standards to be retired
On Thu, Dec 16, 2004 at 10:50:41AM -0500, George Swallow [EMAIL PROTECTED] wrote a message of 17 lines which said: Maybe we need a new category STABLE? I don't think that would be a good name since it might imply that others are INSTABLE ;-). Perhaps FROZEN, STATIC, MATURE? BORING? ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [newtrk] Re: List of Old Standards to be retired
Eliot Even if someone *has* implemented the telnet TACACS user option, Eliot would a user really want to use it? Eric I don't know. Do you? Eliot Yes, I do. Many of us do. And that's the point. I'm sure you think you know, but I don't know that you know, which means that a lot of people have to waste a lot of time preventing you from doing damage. Are you also the one who knows that OSPF demand circuits are never used? ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [Old-standards] Re: [newtrk] List of Old Standards to be retired
Pekka Savola wrote: There's certainly no illusion that these protocols are not being used in some part(s) of the universe. The question is really whether the IETF is interested in maintaining them any longer, and whether we expect significant new deployments of these protocols. Marking the document historic does not take it away from deployment -- marking document as historic doesn't hurt at all (except procedurally, when used as a normative reference, but then we have to do some work in any case if the reference was outdated). This must be some new redefinition of the meaning of a Historic RFC. In the past, it meant don't do it this way anymore, we no longer recommend it, there's another way to accomplish the same goal. So, for the PPP items listed, what's the better way to accomplish the same goal? The IPSec items have another way. Indeed, we had a better way at the time of publication, but couldn't get the IESG to publish 3DES or SHA1 or any other more robust algorithm as a Proposed Standard. -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Historic (Re: List of Old Standards to be retired)
--On 17. desember 2004 10:21 -0500 William Allen Simpson [EMAIL PROTECTED] wrote: Marking the document historic does not take it away from deployment -- marking document as historic doesn't hurt at all (except procedurally, when used as a normative reference, but then we have to do some work in any case if the reference was outdated). This must be some new redefinition of the meaning of a Historic RFC. In the past, it meant don't do it this way anymore, we no longer recommend it, there's another way to accomplish the same goal. So, for the PPP items listed, what's the better way to accomplish the same goal? No, it's the old definition of Historic. The definition Historic = Bad is a change that has been encouraged by the practice of not routinely making documents Historic. This is, to my mind, no more sensible than the twisting of Experimental = Kiss of Death that was the vogue some years ago, which we seem to have successfully untwisted. I think it makes sense for Historic to mean what RFC 2026 said it was. And if it does not, we should explicitly decide to say otherwise. Harald ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [newtrk] Re: List of Old Standards to be retired
--On Friday, 17 December, 2004 07:32 +0200 Pekka Savola [EMAIL PROTECTED] wrote: Hi, On Thu, 16 Dec 2004, John C Klensin wrote: [...] I suggest that the RFC Editor's traditional rule about normative references from standards track documents to things of a lower maturity level should apply here as well, even going backwards. If you think there is value in RFC 1517, and it makes normative reference to 1518 and 1519 (which it does-- I just checked), then 1518 and 1519 are live documents. If one reclassifies them to historic, one risks really confusing users/readers and doing a world of harm. If you think it is worth keeping the content of 1517 while removing 1518 and 1519 from the standards track, then I think you need to arrange to replace (obsolete) 1517 with a new document that stands alone, without those normative references. Such a document could, of course, obsolete all three of 1517-1519, which would eliminate the need for any processing in the cruft arrangements. Correct, though 1517 only has a single References section, giving the RFC-editor/IESG some leeway which ones to consider normative. Not exactly. It means one needs to look at the text to determine whether the statements and requirements of the text are well-defined and clear without the other documents. In the case of a document that is written as an applicability statement on the earlier documents, that is trivially false: the documents about which the applicability statement is written are, almost by definition, normative for it. If that is what it takes, a 5 page document -- based on RFC1517 -- could be easily written which would convey the CIDR principles without having to normatively reference the other documents. I think I agree with you that we cannot just recycle 1517 (or any other CIDR document) to DS, it'll require some polishing. But here is where we get into trouble, IMO. The purpose of the cruft-cleaning exercise was described, I think, as permitting us to identify documents that we could just move to historic or otherwise lose because doing do didn't depend on making fine distinctions or generating new documents to pick up the few remaining useful pieces of old standards-track documents that have become largely, but not completely, obsolete. We have always had the possibility of writing new documents that say obsolete that, or update that by removing the requirement for X, or even this is the applicability statement by which that specification should be interpreted, with always dating to long before 2026 (and, if I recall, predating the IETF). The problem with those approaches to most of these older documents has been that no one has had the motivation to do the work, hence, I've assumed, the cruft proposal. If a non-trivial fraction of the putative-cruft documents are going to require this level of examination by the community, and then lead to the conclusion that it would be pretty easy to write a new document to clean up the specific mess, then my own inference would be that we have demonstrated that there are no quick fixes and that a rethinking of how we identify and document what is standard and what is not is really required. john ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [newtrk] Why old-standards (Re: List of Old Standards to be retired)
--On Friday, 17 December, 2004 13:16 +0100 Harald Tveit Alvestrand [EMAIL PROTECTED] wrote: Since the IETF list is obviously in rehash-of-WG-discussion mode today, I thought I'd contribute to the flamage, and rehash the logic behind the list of old standards that arrived in your inboxes a few days ago. Let's look back on what the IETF has decided previously. In 1994, the IETF community resolved to make the following procedure into IETF law through RFC 1602: ... OK, finished shouting. Eric and Bob: the NEWTRK list is waiting for your contribution on the principle involved, and your internet-draft suggesting the change to RFC 2026 to get rules aligned with reality. It's possible that that contribution will overturn the consensus of the WG to run this experiment. But in the meantime - please get out of the way and let us who want to try run the experiment and evaluate the result. Harald, while I agree in principle, I would suggest that some of the comments Eric, Bill, and others have pointed out call for the beginnings of an evaluation of your experiment. I further suggest that evaluation is appropriate at almost any time, once data start to come in. My recent response to Pekka's analysis of the CIDR documents is one suggestion about where such an evaluation might lead. And, of course, this whole firestorm of discussion on the IETF list, while a welcome distraction from hairsplitting debates about administrative structures, adds strength to the position of those who argued in newtrk that this effort might not be worth the amount of community energy it would take up. john ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Why old-standards (Re: List of Old Standards to be retired)
Harald Tveit Alvestrand wrote: At the NEWTRK WG meeting in San Diego in August, I explained my motivation for pursuing this: This is the lightest-way process for doing what RFC 2026 mandates that I have been able to imagine. Now, we should either execute on that process, OR STOP TALKING ABOUT MOVING TO HISTORIC. The argument that Bob Braden is making, and you seem to be making - that we should not move crufty things to Historic at all - is a rational argument. But in that case, WE SHOULD UPDATE RFC 2026 TO SAY EXACTLY THAT. flame HAVING THE IETF CONTINUE TO SAY ONE THING AND DO ANOTHER IS NOT A GOOD THING FOR THE INTERNET. /flame OK, I see that you are trying to make the IETF less moribund, and that might be a good thing, and I applaud you for it. Actually, the IESG riding herd on the standardization process TO SPEED IT UP is exactly what we thought it should do circa '92-'94. It just didn't do it very well. Instead, they mostly SLOWED things down, since they all want to be architects -- instead of just steering, a pretty boring clerical job, they want to be captains, mostly of the debate team -- and there were the usual politics associated with human beings. For example, while you are picking on PPP in particular, I'll draw your attention to RFC-1332 of 1992. Still at Proposed Standard!?!? Gosh, perhaps there weren't enough interoperable implementations? Or, nobody uses the PPP Internet Protocol CP any more??? Actually, of course, it was reasonably well written, but it turned out that it couldn't be implemented without asking questions on the PPP list -- and folks did, and things got done, and products shipped. So, that wisdom needs to be added to the document, but McGregor wasn't around anymore (he told me he came to IETF last December once again -- I hadn't heard from him in a decade, and haven't heard from him since). The kind of things that happen in a volunteer organization. Also, there was no sense of urgency, since it was all going to be replaced by IPv6 soon (for the past decade). So, the WG wasted its time on IPv6 So, here's my promise to you. I'll track down McGregor, and we'll write something up. I will work on moving my Proposed Standards, assuming that the IESG is actually _interested_ in doing its job. The proof will be in the pudding. In earlier times, I expected to go from internet-draft to Proposed Standard in 2 IETF meetings, and to Full Standard in under 1 year on average, 2 years for extremely controversial items. You see, I disagree with one of your earlier statements. The IESG really DOESN'T have anything more important to do -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Why old-standards (Re: List of Old Standards to be retired)
At 13:16 17/12/2004, Harald Tveit Alvestrand wrote: flame HAVING THE IETF CONTINUE TO SAY ONE THING AND DO ANOTHER IS NOT A GOOD THING FOR THE INTERNET. /flame OK, finished shouting. Eric and Bob: the NEWTRK list is waiting for your contribution on the principle involved, and your internet-draft suggesting the change to RFC 2026 to get rules aligned with reality. Great. This is a good statement and the first step ahead! While updating RFC 2026, better also to make the second step and say that having the IETF continue to do one thing according to the RFCs and the rest of the world doing something else is not a good thing either for the Internet (what ever the Internet may then mean since IETF says it is the adherence to its Internet documents). Then may be someone will consider publishing the Internet Book were the consequences of the valid standards and RFC would be maintained in an orderly maner and translated into the various working languages of the world. This would solve the obsolesence issue: if an RFC is not quoted in the Internet Book and no one protests for one year or more, it becomes historic. jfc ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [Old-standards] Re: [newtrk] List of Old Standards to be retired
--On Friday, 17 December, 2004 12:39 +0100 Harald Tveit Alvestrand [EMAIL PROTECTED] wrote: --On torsdag, desember 16, 2004 16:37:09 +0100 Eliot Lear [EMAIL PROTECTED] wrote: RFC1269 Definitions of Managed Objects for the Border Gateway Protocol: Version 3 Why would this be cruft? The BGP4 MIB was just recently approved... Good thing too. Take a good look at 1269. I don't think it would pass a MIB compiler test today. If you approved the BGP4-MIB, ought not that have obsoleted this guy? draft-ietf-idr-bgp4-mib-15.txt says: This document obsoletes RFC 1269 and RFC 1657. and the I-D tracker says: In State: Approved-announcement to be sent :: Point Raised - writeup needed which usually means that the shepherding AD needs to fiddle with the RFC Editor note in the announcement before sending it. It's one of the oddities of the way we process data that it's quite hard to know that something's already obsoleted between the time the obsoleting document is approved and the publication of the RFC. But I think the old-standards team can take RFC 1269 off the list with a note saying obsoleted by draft-ietf-idr-bgp4-mib, no action necessary. Harald, Sorry, but I've got a procedural problem with this. I-Ds can't obsolete anything, even I-Ds approved by the IESG. While fiddle with the RFC Editor note in the announcement... may be the usual reason for delay, we all know that documents sometimes change significantly between the last-published I-D and actual RFC publication. In theory, the announcement could be posted, the IDR WG membership could take a look at it and conclude the AD's RFC Editor note does not reflect WG consensus, and an appeal of the announcement could be filed. As far as I know, that has never happened, but the procedures clearly permit it and I can think of a case or two when maybe it should have. While we have safeguards to prevent it, it is even possible that a document inadvertently would change enough during the RFC editing process that the WG would no longer believe it was an appropriate replacement for the earlier document. Moreover, it isn't the I-D that obsoletes the older document, it is the I-D, plus any RFC Editor notes, plus the editing process, plus any corrections made in 49 hour last call... a set of considerable uncertainties. Work already in progress to supercede this document, hence off the list would be a reasonable statement (and that would be a reasonable statement if such work were at a much earlier stage of some WG process). But obsoleted by draft-ietf-... is not, IMO. john ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [newtrk] List of Old Standards to be retired
--On Thursday, 16 December, 2004 22:30 -0500 Robert Moskowitz [EMAIL PROTECTED] wrote: At 05:53 PM 12/16/2004, William Allen Simpson wrote: RFC1828 IP Authentication using Keyed MD5 RFC1829 The ESP DES-CBC Transform Now *THESE* were historic when written! Due to US government pressure, it took years (and big plenary protests) for them to be published! Especially without the 40-bit export restrictions! The attack against these was presented at the Danvers IETF. I had requested that they go to historic (along with 1827) once the 2401 series of IPsec RFCs were published. The request fell through the bit mask. Then these need the bad designation, not just the not really interesting any more one. And that, presumably, requires a 1828/1829 considered harmful document, or at least a paragraph and a place to put it. john ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [newtrk] List of Old Standards to be retired
John C Klensin wrote: Then these need the bad designation, not just the not really interesting any more one. And that, presumably, requires a 1828/1829 considered harmful document, or at least a paragraph and a place to put it. Well, gosh and golly gee, I wrote an ISAKMP considered harmful about 6 years ago, and the IESG -- for the first time in its history -- ordered it removed from the internet-drafts repository (saying the IETF wouldn't publish anything critical of the IETF process). It was published as a Usenix ;login: feature article instead I suspect Bob and I could have something in days! -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Historic (Re: List of Old Standards to be retired)
Harald Tveit Alvestrand wrote: Marking the document historic does not take it away from deployment -- marking document as historic doesn't hurt at all (except procedurally, when used as a normative reference, but then we have to do some work in any case if the reference was outdated). This must be some new redefinition of the meaning of a Historic RFC. In the past, it meant don't do it this way anymore, we no longer recommend it, there's another way to accomplish the same goal. So, for the PPP items listed, what's the better way to accomplish the same goal? No, it's the old definition of Historic. Good. For clarity, as I did the above response from decade old memory, that would be: * A TS that is considered to be inappropriate for general use is labeled Not Recommended. This may be because of its limited functionality, specialized nature, or historic status. [RFC-2026 p 11] * has been superceded by a more recent specification [RFC-2026 p 16] * or is for any other reason considered to be obsolete [RFC-2026 p 16] The definition Historic = Bad is a change that has been encouraged by the practice of not routinely making documents Historic. This is, to my mind, no more sensible than the twisting of Experimental = Kiss of Death that was the vogue some years ago, which we seem to have successfully untwisted. I think it makes sense for Historic to mean what RFC 2026 said it was. And if it does not, we should explicitly decide to say otherwise. We must be in agreement, although for some odd reason I thought you were disagreeing with me. That no confused me. ;-) -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [Old-standards] Re: [newtrk] List of Old Standards to be retired
--On fredag, desember 17, 2004 11:56:43 -0500 John C Klensin [EMAIL PROTECTED] wrote: But I think the old-standards team can take RFC 1269 off the list with a note saying obsoleted by draft-ietf-idr-bgp4-mib, no action necessary. Harald, Sorry, but I've got a procedural problem with this. You're right, of course. It should be Under active development, as evidenced by draft-ietf-idr-bgp4-mib, which has been approved by the IESG. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [Old-standards] Re: [newtrk] List of Old Standards to be retired
--On Friday, 17 December, 2004 22:31 +0100 Harald Tveit Alvestrand [EMAIL PROTECTED] wrote: --On fredag, desember 17, 2004 11:56:43 -0500 John C Klensin [EMAIL PROTECTED] wrote: But I think the old-standards team can take RFC 1269 off the list with a note saying obsoleted by draft-ietf-idr-bgp4-mib, no action necessary. Harald, Sorry, but I've got a procedural problem with this. You're right, of course. It should be Under active development, as evidenced by draft-ietf-idr-bgp4-mib, which has been approved by the IESG. That would be fine, thanks. Although I would encourage taking anything off the list that a WG is even looking at, rather than requiring that the WG and IESG be substantially finished with it. john ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
List of Old Standards to be retired
Hello, This is an update from the Old Standards experiment. Below are a list of proposed standards that are candidates to be obsoleted. The old standards mailing list has vetted out a good number, but still a good number remains. We are looking for experts who can say affirmatively whether a standard is implemented and in use. In particular, many of the docs class into four categories: - telnet options - MIBs (for X.25, 802.5, FDDI, and other) - SOCKS - Interaction with other protocol stacks (ISO, IPX, Appelalk, SNA, etc) If you see a document on the list below and you know it to be in use, would you please reply to this message indicating the RFC number, and whether you believe the doc should be advanced beyond proposed? Also, if you know of work to update anything on the list below, please include that. A note along these lines is generally sufficient to remove a document from the list below. RFC0698 Telnet extended ASCII option RFC0726 Remote Controlled Transmission and Echoing Telnet option RFC0727 Telnet logout option RFC0735 Revised Telnet byte macro option RFC0736 Telnet SUPDUP option RFC0749 Telnet SUPDUP-Output option RFC0779 Telnet send-location option RFC0885 Telnet end of record option RFC0927 TACACS user identification Telnet option RFC0933 Output marking Telnet option RFC0946 Telnet terminal location number option RFC1041 Telnet 3270 regime option RFC1043 Telnet Data Entry Terminal option: DODIIS implementation RFC1053 Telnet X.3 PAD option RFC1234 Tunneling IPX traffic through IP networks RFC1239 Reassignment of experimental MIBs to standard MIBs RFC1269 Definitions of Managed Objects for the Border Gateway Protocol: Version 3 RFC1276 Replication and Distributed Operations extensions to provide an Internet Directory using X.500 RFC1277 Encoding Network Addresses to Support Operation over Non-OSI Lower Layers RFC1285 FDDI Management Information Base RFC1314 A File Format for the Exchange of Images in the Internet RFC1328 X.400 1988 to 1984 downgrading RFC1370 Applicability Statement for OSPF RFC1372 Telnet Remote Flow Control Option RFC1378 The PPP AppleTalk Control Protocol (ATCP) RFC1381 SNMP MIB Extension for X.25 LAPB RFC1382 SNMP MIB Extension for the X.25 Packet Layer RFC1397 Default Route Advertisement In BGP2 and BGP3 Version of The Border Gateway Protocol RFC1414 Identification MIB RFC1415 FTP-FTAM Gateway Specification RFC1418 SNMP over OSI RFC1419 SNMP over AppleTalk RFC1420 SNMP over IPX RFC1421 Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures RFC1422 Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management RFC1423 Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers RFC1424 Privacy Enhancement for Internet Electronic Mail: Part IV: Key Certification and Related Services RFC1461 SNMP MIB extension for Multiprotocol Interconnect over X.25 RFC1469 IP Multicast over Token-Ring Local Area Networks RFC1471 The Definitions of Managed Objects for the Link Control Protocol of the Point-to-Point Protocol RFC1472 The Definitions of Managed Objects for the Security Protocols of the Point-to-Point Protocol RFC1473 The Definitions of Managed Objects for the IP Network Control Protocol of the Point-to-Point Protocol RFC1474 The Definitions of Managed Objects for the Bridge Network Control Protocol of the Point-to-Point Protocol RFC1478 An Architecture for Inter-Domain Policy Routing RFC1479 Inter-Domain Policy Routing Protocol Specification: Version 1 RFC1494 Equivalences between 1988 X.400 and RFC-822 Message Bodies RFC1496 Rules for downgrading messages from X.400/88 to X.400/84 when MIME content-types are present in the messages RFC1502 X.400 Use of Extended Character Sets RFC1512 FDDI Management Information Base RFC1513 Token Ring Extensions to the Remote Network Monitoring MIB RFC1518 An Architecture for IP Address Allocation with CIDR RFC1519 Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy RFC1525 Definitions of Managed Objects for Source Routing Bridges RFC1552 The PPP Internetworking Packet Exchange Control Protocol (IPXCP) RFC1553 Compressing IPX Headers Over WAN Media (CIPX) RFC1582 Extensions to RIP to Support Demand Circuits RFC1584 Multicast Extensions to OSPF RFC1598 PPP in X.25 RFC1618 PPP over ISDN
Re: List of Old Standards to be retired
On Dec 16 2004, at 12:46 Uhr, Eliot Lear wrote: RFC1618 PPP over ISDN We had a short discussion about this in pppext. The gist was: The document is pretty bad (partly because things were murky in 1994, but also because it was written by Martians that had no space ship to take them to the ISDN planet), but some parts of it do describe what currently shipping, actively marketed products do (and should do) in this domain. Having done some ISDN work in the late 80s/early 90s, I all but volunteered during this discussion to do a DS version of the thing (probably by striking 80 % of the text and rewriting the rest). If this is what it takes to keep an active standards-track specification about IP over ISDN, I'll do that tiny amount of work. Or we could leave it where it is. Gruesse, Carsten ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: List of Old Standards to be retired
I'm initially really surprised 1518/1519 is on this list. Wasn't there recent talk (like last week) of extending CIDR? And if this is true, shouldn't that work be completed before the existing docs are moved out to the pasture? At 12:46 PM 12/16/2004 +0100, Eliot Lear wrote: Hello, This is an update from the Old Standards experiment. Below are a list of proposed standards that are candidates to be obsoleted. The old standards mailing list has vetted out a good number, but still a good number remains. We are looking for experts who can say affirmatively whether a standard is implemented and in use. In particular, many of the docs class into four categories: - telnet options - MIBs (for X.25, 802.5, FDDI, and other) - SOCKS - Interaction with other protocol stacks (ISO, IPX, Appelalk, SNA, etc) If you see a document on the list below and you know it to be in use, would you please reply to this message indicating the RFC number, and whether you believe the doc should be advanced beyond proposed? Also, if you know of work to update anything on the list below, please include that. A note along these lines is generally sufficient to remove a document from the list below. RFC0698 Telnet extended ASCII option RFC0726 Remote Controlled Transmission and Echoing Telnet option RFC0727 Telnet logout option RFC0735 Revised Telnet byte macro option RFC0736 Telnet SUPDUP option RFC0749 Telnet SUPDUP-Output option RFC0779 Telnet send-location option RFC0885 Telnet end of record option RFC0927 TACACS user identification Telnet option RFC0933 Output marking Telnet option RFC0946 Telnet terminal location number option RFC1041 Telnet 3270 regime option RFC1043 Telnet Data Entry Terminal option: DODIIS implementation RFC1053 Telnet X.3 PAD option RFC1234 Tunneling IPX traffic through IP networks RFC1239 Reassignment of experimental MIBs to standard MIBs RFC1269 Definitions of Managed Objects for the Border Gateway Protocol: Version 3 RFC1276 Replication and Distributed Operations extensions to provide an Internet Directory using X.500 RFC1277 Encoding Network Addresses to Support Operation over Non-OSI Lower Layers RFC1285 FDDI Management Information Base RFC1314 A File Format for the Exchange of Images in the Internet RFC1328 X.400 1988 to 1984 downgrading RFC1370 Applicability Statement for OSPF RFC1372 Telnet Remote Flow Control Option RFC1378 The PPP AppleTalk Control Protocol (ATCP) RFC1381 SNMP MIB Extension for X.25 LAPB RFC1382 SNMP MIB Extension for the X.25 Packet Layer RFC1397 Default Route Advertisement In BGP2 and BGP3 Version of The Border Gateway Protocol RFC1414 Identification MIB RFC1415 FTP-FTAM Gateway Specification RFC1418 SNMP over OSI RFC1419 SNMP over AppleTalk RFC1420 SNMP over IPX RFC1421 Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures RFC1422 Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management RFC1423 Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers RFC1424 Privacy Enhancement for Internet Electronic Mail: Part IV: Key Certification and Related Services RFC1461 SNMP MIB extension for Multiprotocol Interconnect over X.25 RFC1469 IP Multicast over Token-Ring Local Area Networks RFC1471 The Definitions of Managed Objects for the Link Control Protocol of the Point-to-Point Protocol RFC1472 The Definitions of Managed Objects for the Security Protocols of the Point-to-Point Protocol RFC1473 The Definitions of Managed Objects for the IP Network Control Protocol of the Point-to-Point Protocol RFC1474 The Definitions of Managed Objects for the Bridge Network Control Protocol of the Point-to-Point Protocol RFC1478 An Architecture for Inter-Domain Policy Routing RFC1479 Inter-Domain Policy Routing Protocol Specification: Version 1 RFC1494 Equivalences between 1988 X.400 and RFC-822 Message Bodies RFC1496 Rules for downgrading messages from X.400/88 to X.400/84 when MIME content-types are present in the messages RFC1502 X.400 Use of Extended Character Sets RFC1512 FDDI Management Information Base RFC1513 Token Ring Extensions to the Remote Network Monitoring MIB RFC1518 An Architecture for IP Address Allocation with CIDR RFC1519 Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy RFC1525 Definitions of Managed Objects for Source Routing Bridges RFC1552 The PPP
Re: List of Old Standards to be retired
James M. Polk wrote: I'm initially really surprised 1518/1519 is on this list. Obviously, it's a bug. Of the Proposed Standards that the Internet runs on, those are among the most important. I believe this was pointed out on the old-standards list already, but it must have got lost. Brian ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [newtrk] List of Old Standards to be retired
On Dec 16 2004, at 14:02 Uhr, Margaret Wasserman wrote: RFC0885 Telnet end of record option This option was, at least at one time, used for telnet clients that connected to IBM mainframes... It was used to indicate the end of a 3270 datastream. ... and 5250 (RFC2877). Note that there was a draft-murphy-iser-telnet-02.txt attempt at RFC2877bis as recent as May 2004, which still uses EOR. RFC1576 (which is cited in the PS document RFC2355 as traditional TN3270) says: Currently, support for 3270 terminal emulation over Telnet is accomplished by the de facto standard of negotiating three separate Telnet Options - Terminal-Type [2], Binary Transmission [3], and End of Record [4]. This negotiation and the resulting data flow will be described below. [...] [4] Postel, J., Telnet End of Record Option, RFC 885, USC/Information Sciences Institute, December 1983. It's probably necessary to do a full dependency analysis to do this right. OMG, what a visit to the technology attic. Gruesse, Carsten ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [newtrk] List of Old Standards to be retired
On 16-dec-04, at 14:55, Carsten Bormann wrote: It's probably necessary to do a full dependency analysis to do this right. OMG, what a visit to the technology attic. Why do we care if there are still implementations that are based on these documents in use? The important question is whether there are going to be new or revised implementations based on these documents. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [newtrk] List of Old Standards to be retired
Why do we care if there are still implementations that are based on these documents in use? The important question is whether there are going to be new or revised implementations based on these documents. A new implementation for tn5250 is about as likely as a new implementation for NTP. Standards have been invented for creating markets. If the market is mature, you may not see many new entrants, but the existing players still need the standard to keep the market intact. (Of course, tn5250 is a strange market as it is ancillary to one created by a specific vendor, but that's not my point.) Maybe we need a new category STABLE? (But even that is not the case for tn5250, as evidenced by draft-murphy-iser-telnet-02.txt.) So what does HISTORIC mean? -- bad protocol (advice is to get rid of it), as in RIPv1 -- bad specification, but the protocol is alright -- an underlying/related technology is dying out slowly -- an underlying/related technology is used mainly in parts of the world many IETFers don't visit that often -- the market is stable, so there won't be new implementations -- existing open source implementations are doing well, so there won't be new implementations -- there is unlikely to be new development about this standard, as in IPv4 Gruesse, Carsten ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [newtrk] List of Old Standards to be retired
Margaret, Thanks for your note. Please see below for responses: Margaret Wasserman wrote: RFC0885 Telnet end of record option This option was, at least at one time, used for telnet clients that connected to IBM mainframes... It was used to indicate the end of a 3270 datastream. I don't know if it is still used in that fashion, but Bob Moskowitz might know. Thanks. It sounds about right. I'm sure tn3270 is out there and used but I don't know what options it uses. RFC1041 Telnet 3270 regime option I'm not sure what this was ever used for, but again Bob Moskowitz would be a good person to ask if this is still in-use. Right. RFC1269 Definitions of Managed Objects for the Border Gateway Protocol: Version 3 Why would this be cruft? The BGP4 MIB was just recently approved... Good thing too. Take a good look at 1269. I don't think it would pass a MIB compiler test today. If you approved the BGP4-MIB, ought not that have obsoleted this guy? RFC1518 An Architecture for IP Address Allocation with CIDR RFC1519 Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy CIDR is still in-use and rather frequently discussed in other documents. Are there newer references or something? Yah. Something slipped here. One of these two docs is cruftier than the other, and while we don't have a newer reference, we're likely to cruftify one of them and recommend that the other be revised and advanced. Eliot ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [newtrk] List of Old Standards to be retired
Maybe we need a new category STABLE? I don't think that would be a good name since it might imply that others are INSTABLE ;-). Perhaps FROZEN, STATIC, MATURE? ...George George Swallow Cisco Systems (978) 936-1398 1414 Massachusetts Avenue Boxborough, MA 01719 ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC1269 - [was: RE: [newtrk] List of Old Standards to be retired]
Bert, I'll remove it from the list with the expectation that the new MIB will obsolete the old one. However, I note that is currently not stated in the header of the draft. Eliot Wijnen, Bert (Bert) wrote: W.r.t. RFC1269 Definitions of Managed Objects for the Border Gateway Protocol: Version 3 Why would this be cruft? The BGP4 MIB was just recently approved... Good thing too. Take a good look at 1269. I don't think it would pass a MIB compiler test today. If you approved the BGP4-MIB, ought not that have obsoleted this guy? The new doc (in IESG evaluation status) is draft-ietf-idr-bgp4-mib-15.txt And its abstract says it all: Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community In particular, it describes managed objects used for managing the Border Gateway Protocol Version 4 or lower. The origin of this memo is from RFC 1269 Definitions of Managed Objects for the Border Gateway Protocol (Version 3), which was updated to support BGP-4 in RFC 1657. This memo fixes errors introduced when the MIB module was converted to use the SMIv2 language. This memo also updates references to the current SNMP framework documents. This memo is intended to document deployed implementations of this MIB module in a historical context, provide clarifications of some items and also note errors where the MIB module fails to fully represent the BGP protocol. Work is currently in progress to replace this MIB module with a new one representing the current state of the BGP protocol and its extensions. This document obsoletes RFC 1269 and RFC 1657. Distribution of this memo is unlimited. Please forward comments to [EMAIL PROTECTED] So 1269 will soon be made OBSOLETED I will look at other MIB related documents next week. Bert ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: List of Old Standards to be retired
The way we've been running the experiment, if there is a portion of the doc that is still useful then we leave it alone but recommend an update. In other words no status change until someone takes further action. Having said that, I will remove RFC 1618 from the list, but it would be great if you did the update and in the process then obsoleted RFC 1618. Eliot Carsten Bormann wrote: On Dec 16 2004, at 12:46 Uhr, Eliot Lear wrote: RFC1618 PPP over ISDN We had a short discussion about this in pppext. The gist was: The document is pretty bad (partly because things were murky in 1994, but also because it was written by Martians that had no space ship to take them to the ISDN planet), but some parts of it do describe what currently shipping, actively marketed products do (and should do) in this domain. Having done some ISDN work in the late 80s/early 90s, I all but volunteered during this discussion to do a DS version of the thing (probably by striking 80 % of the text and rewriting the rest). If this is what it takes to keep an active standards-track specification about IP over ISDN, I'll do that tiny amount of work. Or we could leave it where it is. Gruesse, Carsten ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [newtrk] List of Old Standards to be retired
* * It's probably necessary to do a full dependency analysis to do this * right. * If it's not broken, why break it? Bob Braden ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [newtrk] List of Old Standards to be retired
* Standards have been invented for creating markets. That's strange, all these years I thought standards were for interoperability. Bob Braden * Gruesse, Carsten * * * ___ * Ietf mailing list * [EMAIL PROTECTED] * https://www1.ietf.org/mailman/listinfo/ietf * ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: List of Old Standards to be retired
I see this exercise has already reached the point of absurdity. How can it possibly be worth anyone's time to look at each telnet option and determine whether it is deployed? What possible purpose could be achieved by changing the standards status of some telnet option? Is there some chance that someone is going to implement one of these by mistake somehow? A similar comment applies to the FDDI MIB. Are we trying to make sure that no one implements that MIB by mistake? Or that no one implements FDDI by mistake, just because he thinks there's an IETF standard about it? Let me echo Bob Braden's if it's not broken, why break it? query. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: List of Old Standards to be retired
Eliot Lear wrote: This is an update from the Old Standards experiment. Below are a list of proposed standards that are candidates to be obsoleted. RFC1793 Extending OSPF to Support Demand Circuits the NEMO Basic Support protocol http://www.ietf.org/internet-drafts/draft-ietf-nemo-basic-support-03.txt has a reference to RFC 1793. a Mobile Router could run OSPF with its Home Agent from a remote location through a tunnel to the Home Agent. the NEMO spec recommends that the tunnel between the Home Agent and the Mobile Router be treated as a demand circuit. there is no implementation of this, however, AFAIK. Vijay ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [newtrk] Re: List of Old Standards to be retired
Eric Rosen wrote: Let me echo Bob Braden's if it's not broken, why break it? query. Because maybe it is broke. Even if someone *has* implemented the telnet TACACS user option, would a user really want to use it? The process is broke. We say in 2026 that proposed standards should hang around and there is good reason why they shouldn't. The stuff that does hang around falls into three categories: 1. that which works so well that we just never got around to advancing it 2. that which was useful at some point but is no longer 3. that which was never useful, and what we really had was a failed experiment. In both [2] and [3] if someone lacking experience decides to (re)implement one of these that person is likely in for a snoot full of trouble by way of security and interoperability owing to the fact that the world has changed since many of these documents were written. And if something wasn't useful in the first place, perhaps smarter people than that someone figured out why. This is a simple way to simply do what we said we were going to do. Eliot ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [newtrk] Re: List of Old Standards to be retired
On Thu, 16 Dec 2004, Brian E Carpenter wrote: James M. Polk wrote: I'm initially really surprised 1518/1519 is on this list. Obviously, it's a bug. Of the Proposed Standards that the Internet runs on, those are among the most important. I believe this was pointed out on the old-standards list already, but it must have got lost. Not really a bug. Note that the to-be-historic list does not mention this: RFC1517 Applicability Statement for the Implementation of Classless Inter-Domain Routing (CIDR) This is the best document to use as a basis for respinning the concept of CIDR, AFAICS. 1518/1519 are full of address assignment etc. details which were out of date or inappropriate for a standards track document already 5 years ago. There's very small amount of useful information to salvage from those. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: List of Old Standards to be retired
Carsten Bormann wrote: RFC1618 PPP over ISDN We had a short discussion about this in pppext. The gist was: The document is pretty bad (partly because things were murky in 1994, but also because it was written by Martians that had no space ship to take them to the ISDN planet), (sorry, I've given up reading IETF lists regularly, but I was pointed at this comment.) The document was written in 1992-1993 based on using real equipment over Ameritech lines in Ann Arbor, Michigan. In those days, I was so personally dedicated to the IETF that I actually moved to Ann Arbor to test and use it, as it was the first place in the state to offer ISDN. I've heard that things differ in other places in the world. But other places in the world participated in the lively design and implementation discussion. Without that discussion, it would have been octet-sync only, but others felt the need for bit-sync. Moreover, that bit-sync be preferred over octet-sync, as some places in the world would actually lose octet alignment over time. Horrors! Now that backbones use fiber this probably happens a lot less, but those were the realities of the day. The specification was implemented by me in at least 2 product lines. I've heard that it was implemented by others as well. But, I've never seen results of any interoperability testing, and thus it was never advanced toward standard. Most folks seemed to just buy the same vendor for both ends of the link. but some parts of it do describe what currently shipping, actively marketed products do (and should do) in this domain. And that needs to be documented on the PPP list. I found the nroff, and would be happy to document interoperability, should there be any. -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [newtrk] Re: List of Old Standards to be retired
This is a simple way to simply do what we said we were going to do. The worries about this whole anti-cruft business have always been (a) the likelihood that it would do more harm than good, and (b) the likelihood that it would waste enormous amounts of time on issues of no importance. The initial foray into this area doesn't do much to relieve these worries. Even if someone *has* implemented the telnet TACACS user option, would a user really want to use it? I don't know. Do you? How do we go about answering a question like that? How much time should the IETF spend determining the answer to this question? It's just better to leave well enough alone. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [newtrk] List of Old Standards to be retired
Bob Braden wrote: If it's not broken, why break it? * Standards have been invented for creating markets. That's strange, all these years I thought standards were for interoperability. Hear, Hear! Folks, I took a look at the first posting, and was surprised at those where I'm personally knowledgable. RFC1378 The PPP AppleTalk Control Protocol (ATCP) It was widely implemented. I still use this. My $1000 HP LaserJet 4ML works fine, it hasn't run out its original cartridge, but I need appletalk for it. RFC1552 The PPP Internetworking Packet Exchange Control Protocol (IPXCP) RFC1553 Compressing IPX Headers Over WAN Media (CIPX) Again, widely implemented. Sure, IPX wasn't a very good protocol, but I'm aware of rather a large number of sites that still run it. Sure, Novell refused to divulge the contents of some of the fields, so we just had to carry undifferentiated bytes around, but it worked RFC1598 PPP in X.25 RFC1618 PPP over ISDN At one time, these were incredibly important in the 3rd world, and some parts of Europe and Japan. Is X.25 completely non-existant today? Heck, folks were running X.25 over ISDN D-channels, and those still exist on every PRI circuit Admittedly, some of this may be nostalgia, as X.25 was the second protocol I ever implemented, circa 1978 before so much cruft was saddled upon it through the standardization process. It seems to me that besides the ossification of the IETF that keeps it from getting much of anything worthwhile done, some folks have lost sight of the inter part of networking. RFC1828 IP Authentication using Keyed MD5 RFC1829 The ESP DES-CBC Transform Now *THESE* were historic when written! Due to US government pressure, it took years (and big plenary protests) for them to be published! Especially without the 40-bit export restrictions! At the time, I advocated Triple-DES to be the Proposed Standard, since we already knew 56-bit DES was broken. I requested Historic status for these many years ago -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [newtrk] List of Old Standards to be retired
At 05:53 PM 12/16/2004, William Allen Simpson wrote: RFC1828 IP Authentication using Keyed MD5 RFC1829 The ESP DES-CBC Transform Now *THESE* were historic when written! Due to US government pressure, it took years (and big plenary protests) for them to be published! Especially without the 40-bit export restrictions! The attack against these was presented at the Danvers IETF. I had requested that they go to historic (along with 1827) once the 2401 series of IPsec RFCs were published. The request fell through the bit mask. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [newtrk] Re: List of Old Standards to be retired
Hi, On Thu, 16 Dec 2004, John C Klensin wrote: [...] I suggest that the RFC Editor's traditional rule about normative references from standards track documents to things of a lower maturity level should apply here as well, even going backwards. If you think there is value in RFC 1517, and it makes normative reference to 1518 and 1519 (which it does-- I just checked), then 1518 and 1519 are live documents. If one reclassifies them to historic, one risks really confusing users/readers and doing a world of harm. If you think it is worth keeping the content of 1517 while removing 1518 and 1519 from the standards track, then I think you need to arrange to replace (obsolete) 1517 with a new document that stands alone, without those normative references. Such a document could, of course, obsolete all three of 1517-1519, which would eliminate the need for any processing in the cruft arrangements. Correct, though 1517 only has a single References section, giving the RFC-editor/IESG some leeway which ones to consider normative. If that is what it takes, a 5 page document -- based on RFC1517 -- could be easily written which would convey the CIDR principles without having to normatively reference the other documents. I think I agree with you that we cannot just recycle 1517 (or any other CIDR document) to DS, it'll require some polishing. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [newtrk] Re: List of Old Standards to be retired
Eric Rosen wrote: Even if someone *has* implemented the telnet TACACS user option, would a user really want to use it? I don't know. Do you? Yes, I do. Many of us do. And that's the point. How do we go about answering a question like that? We will spend less time discussing that option then we will the meta conversation, it seems. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [Old-standards] Re: [newtrk] List of Old Standards to be retired
Carsten, please read draft-ietf-newtrk-cruft-00.txt, in particular section 3.2, and see if it answers your question this has been a major discussion source Harald --On 16. desember 2004 15:40 +0100 Carsten Bormann [EMAIL PROTECTED] wrote: So what does HISTORIC mean? -- bad protocol (advice is to get rid of it), as in RIPv1 -- bad specification, but the protocol is alright -- an underlying/related technology is dying out slowly -- an underlying/related technology is used mainly in parts of the world many IETFers don't visit that often -- the market is stable, so there won't be new implementations -- existing open source implementations are doing well, so there won't be new implementations -- there is unlikely to be new development about this standard, as in IPv4 ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [newtrk] List of Old Standards to be retired
RFC0885 Telnet end of record option This option was, at least at one time, used for telnet clients that connected to IBM mainframes... It was used to indicate the end of a 3270 datastream. I don't know if it is still used in that fashion, but Bob Moskowitz might know. RFC1041 Telnet 3270 regime option I'm not sure what this was ever used for, but again Bob Moskowitz would be a good person to ask if this is still in-use. RFC1269 Definitions of Managed Objects for the Border Gateway Protocol: Version 3 Why would this be cruft? The BGP4 MIB was just recently approved... RFC1518 An Architecture for IP Address Allocation with CIDR RFC1519 Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy CIDR is still in-use and rather frequently discussed in other documents. Are there newer references or something? Margaret ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: List of Old Standards to be retired
Eliot Lear wrote: RFC1277 Encoding Network Addresses to Support Operation over Non-OSI Lower Layers This is still in use. draft-melnikov-nsap-ipv6-00.txt references it and in theory it can be updated to include bits of RFC 1277 which are still relevant. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
RFC1269 - [was: RE: [newtrk] List of Old Standards to be retired]
W.r.t. RFC1269 Definitions of Managed Objects for the Border Gateway Protocol: Version 3 Why would this be cruft? The BGP4 MIB was just recently approved... Good thing too. Take a good look at 1269. I don't think it would pass a MIB compiler test today. If you approved the BGP4-MIB, ought not that have obsoleted this guy? The new doc (in IESG evaluation status) is draft-ietf-idr-bgp4-mib-15.txt And its abstract says it all: Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community In particular, it describes managed objects used for managing the Border Gateway Protocol Version 4 or lower. The origin of this memo is from RFC 1269 Definitions of Managed Objects for the Border Gateway Protocol (Version 3), which was updated to support BGP-4 in RFC 1657. This memo fixes errors introduced when the MIB module was converted to use the SMIv2 language. This memo also updates references to the current SNMP framework documents. This memo is intended to document deployed implementations of this MIB module in a historical context, provide clarifications of some items and also note errors where the MIB module fails to fully represent the BGP protocol. Work is currently in progress to replace this MIB module with a new one representing the current state of the BGP protocol and its extensions. This document obsoletes RFC 1269 and RFC 1657. Distribution of this memo is unlimited. Please forward comments to [EMAIL PROTECTED] So 1269 will soon be made OBSOLETED I will look at other MIB related documents next week. Bert ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [newtrk] List of Old Standards to be retired
* From [EMAIL PROTECTED] Thu Dec 16 05:23:25 2004 * Mime-Version: 1.0 * Date: Thu, 16 Dec 2004 08:02:44 -0500 * To: Eliot Lear [EMAIL PROTECTED], IETF Discussion [EMAIL PROTECTED] * From: Margaret Wasserman [EMAIL PROTECTED] * X-Spam-Score: 0.1 (/) * X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 * Cc: '[EMAIL PROTECTED]' [EMAIL PROTECTED], *[EMAIL PROTECTED] * Subject: Re: [newtrk] List of Old Standards to be retired * List-Id: IETF-Discussion ietf.ietf.org * X-ISI-4-32-5-MailScanner: Found to be clean * X-ISI-4-30-3-MailScanner: Found to be clean * X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham *version=2.64 * * * RFC0885 Telnet end of record option * * This option was, at least at one time, used for telnet clients that * connected to IBM mainframes... It was used to indicate the end of a * 3270 datastream. I don't know if it is still used in that fashion, * but Bob Moskowitz might know. * I don't see that usage matters in the least. The EOR option provides a function that was useful at one time and may be useful again. It is not technically unsound. I don't see any excuse to change the category of this document. Bob Braden (speaking for himself) ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: List of Old Standards to be retired
From: Eric Rosen [EMAIL PROTECTED] I see this exercise has already reached the point of absurdity. How can it possibly be worth anyone's time to look at each telnet option and determine whether it is deployed? What possible purpose could be achieved by changing the standards status of some telnet option? Is there some chance that someone is going to implement one of these by mistake somehow? A similar comment applies to the FDDI MIB. Are we trying to make sure that no one implements that MIB by mistake? Or that no one implements FDDI by mistake, just because he thinks there's an IETF standard about it? Let me echo Bob Braden's if it's not broken, why break it? query. Spending time revising old RFCs of living protocols is unlikely to do much good and has potential for plenty of harm. It's hard to avoid the temptation to fix things (parts of RFC 1668 and RFC 1661 tempt me), but such fix-it efforts usually produce incompatible protocols. The IETF definition or RIPv1 was compatible only because it was a strict subset of the real protocol. The IETF version of the printer protocol was just plain broken. Other targets of this exercise describe protocols that were never implemented and should never have been allowed on the standards track. Why not scale back the exercise to attack only obvioulsy dead or stillborn protocols? Vernon Schryver[EMAIL PROTECTED] ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [newtrk] List of Old Standards to be retired
William Allen Simpson [EMAIL PROTECTED] writes: RFC1598 PPP in X.25 RFC1618 PPP over ISDN At one time, these were incredibly important in the 3rd world, and some parts of Europe and Japan. Is X.25 completely non-existant today? Heck, folks were running X.25 over ISDN D-channels, and those still exist on every PRI circuit For what it's worth, the AX.25 protocol number in IPv4 is still used by some poor souls. (Carries just about 3MB/day on the Abilene backbone and used to be several times more.) http://netflow.internet2.edu/weekly/longit/protocols93-octets.png -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ This message is designed to be viewed upside down. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [newtrk] Re: List of Old Standards to be retired
--On Thursday, 16 December, 2004 22:07 +0200 Pekka Savola [EMAIL PROTECTED] wrote: On Thu, 16 Dec 2004, Brian E Carpenter wrote: James M. Polk wrote: I'm initially really surprised 1518/1519 is on this list. Obviously, it's a bug. Of the Proposed Standards that the Internet runs on, those are among the most important. I believe this was pointed out on the old-standards list already, but it must have got lost. Not really a bug. Note that the to-be-historic list does not mention this: RFC1517 Applicability Statement for the Implementation of Classless Inter-Domain Routing (CIDR) This is the best document to use as a basis for respinning the concept of CIDR, AFAICS. 1518/1519 are full of address assignment etc. details which were out of date or inappropriate for a standards track document already 5 years ago. There's very small amount of useful information to salvage from those. Pekka and others, I suggest that the RFC Editor's traditional rule about normative references from standards track documents to things of a lower maturity level should apply here as well, even going backwards. If you think there is value in RFC 1517, and it makes normative reference to 1518 and 1519 (which it does-- I just checked), then 1518 and 1519 are live documents. If one reclassifies them to historic, one risks really confusing users/readers and doing a world of harm. If you think it is worth keeping the content of 1517 while removing 1518 and 1519 from the standards track, then I think you need to arrange to replace (obsolete) 1517 with a new document that stands alone, without those normative references. Such a document could, of course, obsolete all three of 1517-1519, which would eliminate the need for any processing in the cruft arrangements. john ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
