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: [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
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: [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
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: [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
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: [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: [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: [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
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: [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
