dear
-- Virus Warning Message (on ietf-mx) Found virus WORM_NETSKY.C in file mydate.pif (in mydate.zip) The uncleanable file is deleted. - your job? (I found that!) -- Virus Warning Message (on ietf-mx) mydate.zip is removed from here because it contains a virus. -
Re: IESG review of RFC Editor documents
From: Kurt D. Zeilenga [EMAIL PROTECTED] I prefer to keep the bar low. I, frankly, don't see a problem with there being more crap published as RFCs, whether produced by WGs or produced by individuals. I'm going to side with Keith here, right down the line (for once :-). The issues of security, scaling, money, credibility etc all weigh towards being careful with RFC's. As to the information propogation argument, we have this wonderful thing called the WWW that allows anyone to publish anything they want, in a way that almost anyone can get it trivially. We also have I-D's, which allow people to actively bring their stuff to other people's attention (although so many I-D's come out now that I expect most people don't even carefully read all the announcements any more). So I reckon that disposes of that point; it might have been valid in 1974, but not in 2004. Noel
Re: IESG review of RFC Editor documents
On Sat, Mar 27, 2004 08:50:29AM -0500, Noel Chiappa allegedly wrote: I'm going to side with Keith here, right down the line (for once :-). The issues of security, scaling, money, credibility etc all weigh towards being careful with RFC's. As to the information propogation argument, we have this wonderful thing called the WWW that allows anyone to publish anything they want, in a way that almost anyone can get it trivially. We also have I-D's, which allow people to actively bring their stuff to other people's attention (although so many I-D's come out now that I expect most people don't even carefully read all the announcements any more). So I reckon that disposes of that point; it might have been valid in 1974, but not in 2004. Yes on both counts.
Re: IESG review of RFC Editor documents
Few questions: 1. Section 4 say that For documents that are independent of the IETF process: This document is not a candidate for any level of Internet Standard. Does this means that an individual submission can only be Informational only? ie. not even experimental? If so, how does this fit into what happened in IMAA BoF in Seoul? (The conclusion is no working group, but wrap up and docs some of the implementations as possibly experimental RFCs via individual submissions) 2. Section 3 talks about the various IESG responses. Most of it makes sense but the last one: The IESG thinks that this document extends an IETF protocol in a way that requires IETF review, and should therefore not be published without IETF review. It wasn't very clear when will the above apply. Beside, wasn't individual submission already (maybe) subjected to 4 weeks last call? Does this qualify as 'IETF review'? Or 'IETF review' implies review by a IETF Working Group? -James Seng - Original Message - From: Harald Tveit Alvestrand [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, March 26, 2004 10:51 PM Subject: IESG review of RFC Editor documents The IESG has proposed a change in its present review procedures for IESG review of documents submitted directly to the RFC Editor for publication. The IESG will be discussing this in detail, and with the RFC Editor, next week - the input document for that discussion is published as an I-D below Your input is welcome! Copy of the announcement below. (note - between solutions, icar, poised and the IETF list, I chose the IETF list - I will post notes to the 3 other lists saying that I've asked for discussion of this on the IETF list judgment call). Harald Harald Alvestrand -- Forwarded Message -- Date: 25. mars 2004 15:38 -0500 From: [EMAIL PROTECTED] To: IETF-Announce Cc: [EMAIL PROTECTED] Subject: I-D ACTION:draft-iesg-rfced-documents-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Engineering Steering Group Working Group of the IETF. Title : The IESG and RFC Editor documents: Procedures Author(s) : H. Alvestrand Filename : draft-iesg-rfced-documents-00.txt Pages : 6 Date : 2004-3-25 This document gives the IESG's procedures for handling documents submitted for RFC publication via the RFC Editor, subsequent to the changes proposed by the IESG at the Seoul IETF, March 2004. NOTE IN DRAFT: These guidelines are proposed, not adopted. Comments are welcome - please send them to [EMAIL PROTECTED] A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-iesg-rfced-documents-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username anonymous and a password of your e-mail address. After logging in, type cd internet-drafts and then get draft-iesg-rfced-documents-00.txt. A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: [EMAIL PROTECTED] In the body type: FILE /internet-drafts/draft-iesg-rfced-documents-00.txt. NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the mpack utility. To use this feature, insert the command ENCODING mime before the FILE command. To decode the response(s), you will need munpack or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with multipart MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -- End Forwarded Message --
Re: IESG review of RFC Editor documents
--On 26. mars 2004 21:59 -0500 Scott Bradner [EMAIL PROTECTED] wrote: I do worry about the harm to the Internet case (e.g., a protocol which will be used to transport large amounts of data but does not have any congestion control ability) but I'm satisfied with the process described in this ID to bring any such issue to the attention of the RFC Editor and rely on the RFC Editor to do the right thing as long as the RFC Editor maintains the model of today (an independent technically competent group). If that model changes this process might have to be reevaluated as long as the RFC Editor contunues to have s part of its mission to publish non-IETF documents (as I strongly think it should). I think we might want to begin thinking of these two functions (technical review and copy-editing) as two different functions, which are joined at the hip currently, but aren't necessarily so joined forever. nit: I do not think that RFC 2418 sec 8 has anything to do with the topic of RFC Editor documents and I think that reference should be removed from this document. not sure - 2418 sec 8 sentence 1 says The IESG reviews all documents submitted for publication as RFCs. It might be intended as a shorthand for all documents submitted by WGs for publication as RFCs - but I knew that at the time of publication, all documents, including RFC Editor submissions and individual submitted via AD, went through IESG review, so I thought it might mean what it said rather than what its context may seem to indicate... Note: The changed IESG review of RFC Editor documents does NOT change the IESG review for individual submissions to the standards track or individual submission sponsored by an AD. These get full IESG technical review, as before. I think this is a good retro-move. Seems good!
Re: IESG review of RFC Editor documents
I think we might want to begin thinking of these two functions (technical review and copy-editing) as two different functions, which are joined at the hip currently, but aren't necessarily so joined forever. agreed, but if they become disarticulated there will need to be a solid way for the copy-editing/publishing part to relate to the technical review part if the IESG is not there to act as a 2nd pass of technical review. so I thought it might mean what it said rather than what its context may seem to indicate... it is correct that its a true statement that the IESG reviews all RFCs (or actually almost RFCs) pre-publication but rfc 2418 (including sec 8) only deals with WG documents so I do not think that you need a reference to 2418 in this document Note: The changed IESG review of RFC Editor documents does NOT change the IESG review for individual submissions to the standards track or individual submission sponsored by an AD. These get full IESG technical review, as before. I assumed that was the case also WG informational and experimental documents I trust? Scott
Re: Naming crap (Re: IESG review of RFC Editor documents)
At 09:36 AM 3/27/2004, Harald Tveit Alvestrand wrote: That, I think, would be counter productive. I think it fairly apparent that there is a fair amount of crap (by mine, your, or anyone's opinion) published as RFCs. I content that much of that crap was produced by the IETF. permit me to disagree. not with your core statement, but with the statement that citing examples would be counterproductive. I was attempting to make a few points: 1) the series is not intended to be crap free 2) what is crap is quite subjective 3) we need to continue to allow others to publish what we might consider to be crap. which may have been missed by some. What I personally view as crap has no bearing in regards to these points, excepting that where I feel strong enough to produce an I-D detailing why I think something is crap I should be allowed (if I can met general editorial and technical standards) to publish that opinion as an RFC even though consensus of the IETF (or Keith's review board or the RFC Editor) might be that my opinion is crap. (That opinion could be expressed in the form of an alternative protocol specification.) The statement that a fair amount of crap is published as RFCs has been repeated for so long that it's almost become a mantra. Yes. But normally its uttered as an argument to increase publishing requirements. I am arguing that we should not increase publishing requirements here. However, in my opinion, for *every single one* of those RFCs, there's a reason why it was published. If we are to change the process that produces this stuff, we HAVE to understand what the reasons are that reasonable, competent people produce things that are sub-par, broken or crap. And IMHO, we can't do that without saying what these unacceptable results of the process are. Yes. I argue that we should not change the process (as described in RFC 2026) that produces this stuff as that process is producing acceptable results (e.g., the current level of crap is acceptable). Moving from the generic to the specific might actually be an useful catharsis for the community - and just might change the community opinion from a lot of our 3000 RFCs are crap to there are 30 bad RFCs, 300 that could have been better and 3000 reasonably OK ones, or even to the quality control system does not work well enough, there are too many borderline cases. It would be interesting to see how many of documents folks consider to be crap would have been blocked under a different process. If I look at the documents that stand out to me as crap, I note that Keith's new review process would have no impact... as most of the documents I consider to be crap were produced by the IETF or underwent some IETF review. But I'm not of the opinion that the documents I consider to be crap should have been blocked (though I might argue that some of them shouldn't be on the Standard Track). I don't think anonymous, class-based criticism will get us much further. We need to be specific about what our problems are. The problem I see with being specific here is that what's crap to me is not necessarily the same as to you, and we'll just end up arguing over wether something is crap or not, and that will overshadow the key aspect of my argument that we should each be allowed to own opinions as to what is crap and be able to act on those opinions, including publication of what others might consider to be crap. Kurt
Re: Naming crap (Re: IESG review of RFC Editor documents)
Sound nice but isn't this go against the rough consensus principle? You are free to doc your opinion (even if it is not rough consensus) in the mailing list. -James Seng What I personally view as crap has no bearing in regards to these points, excepting that where I feel strong enough to produce an I-D detailing why I think something is crap I should be allowed (if I can met general editorial and technical standards) to publish that opinion as an RFC even though consensus of the IETF (or Keith's review board or the RFC Editor) might be that my opinion is crap. (That opinion could be expressed in the form of an alternative protocol specification.)
Re: IESG review of RFC Editor documents
At 4:21 PM -0500 3/26/04, Keith Moore wrote: Part of the problem is the familiar one that RFCs are often used as standards even when they carry the Informational or Experimental label. With respect to Informational RFCs, that was more true five years ago than it is now. The IETF has been largely successful at nailing vendors who try to pass off Informational RFCs as having any weight. It still happens, but is often followed by public rebuke from active IETF members. The last time someone asked me about whether or not they should try elevating the importance of an Informational RFC, my response was sure, if you want to be exposed as a liar. Experimental RFCs are unfortunately a different matter. We see Working Groups passing out fully-deployed, non-experimental protocols as Experimental due to political reasons such as lack of consensus, or as consolation prizes when a different protocol received louder hums. Noel's observation about the lack of need for RFC publication due to the easy publication on the Web is exactly right. People can find out about information Foo or experiment Bar with a quick search. The Internet might be helped by publication in the RFC series, but it also might not be. The material in draft-iesg-rfced-documents-00.txt can be greatly improved with a few changes: - Require that all documents published without IESG technical review say so explicitly in a standardized boilerplate: The technology in this document was reviewed the RFC Editor, but was not approved by the IESG or any IETF Working Group. See RFC for more information on the process used in the publication of this document This will help readers of the RFC who haven't read 2026 et. al., and will also serve as a hindrance to over-marketing the document. - Require that the RFC Editor not publish any document as an Experimental RFC unless it meets the definition on RFC 2026 or its successors. Publish a non-standards-track protocol as an Informational RFC with the above wording unless it really is a specification that is part of some research or development effort. It is the responsibility of the RFC Editor to make this determination. - Add text saying that publication as an RFC may not meet the needs of many publication requesters, and that having an RFC can actually inhibit innovation and flexibility due to the limitations of the series such as long publication times, difficulty of revision, and so on. --Paul Hoffman, Director --VPN Consortium
Re: Naming crap (Re: IESG review of RFC Editor documents)
At 03:49 PM 3/27/2004, James Seng wrote: Sound nice but isn't this go against the rough consensus principle? The rough consensus principle applies to IETF documents, not to RFCs in general. You are free to doc your opinion (even if it is not rough consensus) in the mailing list. -James Seng What I personally view as crap has no bearing in regards to these points, excepting that where I feel strong enough to produce an I-D detailing why I think something is crap I should be allowed (if I can met general editorial and technical standards) to publish that opinion as an RFC even though consensus of the IETF (or Keith's review board or the RFC Editor) might be that my opinion is crap. (That opinion could be expressed in the form of an alternative protocol specification.)
Re: Naming crap (Re: IESG review of RFC Editor documents)
Ah, that never cross my mind: I always assumed that RFCs, been a product of the IETF (since it is published by IETF copyrighted by ISOC) should also adopt the IETF principle. But you may be right..no where in 2026 and 1543 say anything about RFC needs to have rough consensus..hmm... -James Seng - Original Message - From: Kurt D. Zeilenga [EMAIL PROTECTED] To: James Seng [EMAIL PROTECTED] Cc: Harald Tveit Alvestrand [EMAIL PROTECTED]; IETF Discussion [EMAIL PROTECTED] Sent: Sunday, March 28, 2004 7:58 AM Subject: Re: Naming crap (Re: IESG review of RFC Editor documents) At 03:49 PM 3/27/2004, James Seng wrote: Sound nice but isn't this go against the rough consensus principle? The rough consensus principle applies to IETF documents, not to RFCs in general. You are free to doc your opinion (even if it is not rough consensus) in the mailing list. -James Seng What I personally view as crap has no bearing in regards to these points, excepting that where I feel strong enough to produce an I-D detailing why I think something is crap I should be allowed (if I can met general editorial and technical standards) to publish that opinion as an RFC even though consensus of the IETF (or Keith's review board or the RFC Editor) might be that my opinion is crap. (That opinion could be expressed in the form of an alternative protocol specification.)
Re: Naming crap (Re: IESG review of RFC Editor documents)
Kurt D. Zeilenga wrote: [..] The problem I see with being specific here is that what's crap to me is not necessarily the same as to you, and we'll just end up arguing over wether something is crap or not, and that will overshadow the key aspect of my argument that we should each be allowed to own opinions as to what is crap and be able to act on those opinions, including publication of what others might consider to be crap. You do have avenues for publishing 'crap' outside the RFC series. Put your content up on a website. Send it to a mailing list. Shout it from the treetops. Your argument against improved expectations of standards in the RFC publication process seems unconvincing. I see Vanity Press written all over it. cheers, gja -- Grenville Armitage http://caia.swin.edu.au I come from a LAN downunder.
Re: Naming crap (Re: IESG review of RFC Editor documents)
At 05:32 PM 3/27/2004, grenville armitage wrote: Kurt D. Zeilenga wrote: The problem I see with being specific here is that what's crap to me is not necessarily the same as to you, and we'll just end up arguing over wether something is crap or not, and that will overshadow the key aspect of my argument that we should each be allowed to own opinions as to what is crap and be able to act on those opinions, including publication of what others might consider to be crap. You do have avenues for publishing 'crap' outside the RFC series. Put your content up on a website. Send it to a mailing list. Shout it from the treetops. Yes, other avenues are available publishing independent works. However, it has been a long standard tradition of the RFC series to provide an avenue for publication of independent works (subject to minimal review). There is merit to the Internet technical community in this tradition as it combines opposing opinions into a single series of documents. I strongly believe that hindering the publication of individual submissions, as Keith suggests, will have long term negative impact upon the overall technical merit of the series. That is, you'll get want you seem to wish, individuals will go elsewhere. And I don't mean just in terms of publication avenues, but in terms of where and how Internet engineering is done. Your argument against improved expectations of standards in the RFC publication process seems unconvincing. Arguments that we should reenforce the false expectations of the quality and/or community acceptance of documents in the RFC series are unconvincing to me. We'll always have documents of different quality (including crap) and community acceptance (including none) in the series, we should focus more on how to distinguish the levels of quality and community acceptance. Attempting to restrict the series to those documents believed to be of high quality and broad community acceptance is simply infeasible (if not impossible). I see Vanity Press written all over it. Minimal review undertaken by the RFC Editor appears to be sufficient to address such concerns. Kurt
Re: Naming crap (Re: IESG review of RFC Editor documents)
[EMAIL PROTECTED] (Harald Tveit Alvestrand) writes: ... permit me to disagree. not with your core statement, but with the statement that citing examples would be counterproductive. The statement that a fair amount of crap is published as RFCs has been repeated for so long that it's almost become a mantra. i guess the fact that noone objects to this characterization is either due to everyone agreeing with it or to what else exactly are you thinking of? However, in my opinion, for *every single one* of those RFCs, there's a reason why it was published. Usually there was a supporting constituency, how about it was a measurable dayjob objective for at least one editor or because the WG was completely exhausted and the only way they could get the document out of their collective face was to fling it over the wall? when it comes to crap, few documents can compete with RFC's 2065 and 2535. i don't think that the editors or WGchairs were in any way incompetent, but even a cursory reading of either document at this stage will demonstrate that noone had actually read or tried to understand them in their submitted form. (our long-suffering AD eventually started reading our docs and asking the kind of simple questions that are really cover for did you read this yourself and were you hoping that nobody else would?) i'm one of the guilty parties -- both as a draft-editor and a positive-hummer. but it actually does seem counterproductive to me to name documents, WGs, WGchairs, ADs, authors, and editors as having produced crap. i think if we focus on the general crap-fact we can do much good to reduce overall-crap and that no special focus is needed on specific crap-fact like which docs are actually crap. and at least some opinion that publishing it was better for the Internet than not publishing it - certainly, for every standards-track RFC, there was at one time a majority view in the IESG that such was the case. well, no. the iesg at the time of 2065 was clearly out smoking pot on the back deck, there is no possible way that it could have been seen as good for the internet or even good, at all. exhaustion, dayjobs, and miasma. If we are to change the process that produces this stuff, we HAVE to understand what the reasons are that reasonable, competent people produce things that are sub-par, broken or crap. And IMHO, we can't do that without saying what these unacceptable results of the process are. to your first statement i agree. to your second i very much disagree. Moving from the generic to the specific might actually be an useful catharsis for the community - and just might change the community opinion from a lot of our 3000 RFCs are crap to there are 30 bad RFCs, 300 that could have been better and 3000 reasonably OK ones, or even to the quality control system does not work well enough, there are too many borderline cases. unfortunately there's universal/objective crap, like 2065 or 2535, and on the other hand there's subjective crap where just because i don't like it doesn't make me expect that noone else found it useful (2181, 1995). if we try to move from the generic to the specific we'll probably just bog down in nonuniversal standards for crap and i don't think that's going to help us. I don't think anonymous, class-based criticism will get us much further. We need to be specific about what our problems are. well, if highlighting a difference of opinion is the first step toward resolving it, then we're on our way. -- Paul Vixie
RE: IESG review of RFC Editor documents
Sometimes, if a half-baked idea is put on a back burner for a while it might become palatable or at least partly usable. Marge Effort does not necessarily lead to progress. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kurt D. Zeilenga Sent: Friday, March 26, 2004 8:09 PM To: Keith Moore Cc: John C Klensin; Keith Moore; IETF Discussion Subject: Re: IESG review of RFC Editor documents At 04:41 PM 3/26/2004, Keith Moore wrote: What I have a problem with is individuals demanding the right to have their half-baked specifications published as RFCs, and for the RFC Editor to publish those documents as RFCs without public review, or (as has happened in the past) even when substantial oversights or design flaws in those specifications have been pointed out to the RFC Editor. Personally, I'm more concerned by WGs demanding their right to have their half-baked specifications published as RFCs, and the for IESG to approve them without any IETF review or other community review, or (as has happened in the past) even when substantial oversights or design flaws in those specifications were pointed out by individuals. Kurt --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.642 / Virus Database: 410 - Release Date: 3/24/2004 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.642 / Virus Database: 410 - Release Date: 3/24/2004
Re: IESG review of RFC Editor documents
Keith, These days, for a protocol specification to be of reasonable use on a wide scale it needs to avoid causing harm. First, something can be of reasonable use while still causing harm. Fossil based fuels prove that. And while I agree that there are certain areas where causing harm to others needs to be considered (such as UDP-based protocols that lack well known congestion avoidance algorithms), we as a community cannot be so risk averse that we drive development elsewhere. Consider the case where someone *DID* invent a UDP-based file transfer protocol (FSP). The work was done completely outside the IETF and satisfied a demand. When that demand subsided use of that protocol diminished. And yet does not have a specification for this Historic protocol. Similarly, SOCKS went quite far before the IETF ever got a look at it. Why? Because we are no longer viewed as a place where development can seriously take place. Risk averse. You know that thing about running code? Taken too far we fail what I think part of our mission is, which is to be a place to collaborate, because everyone will have shown up with their respective running code, only to fight over whose running code (if anybody's) will become the standard. See, for instance, the XMPP/IMPP wars. There have been too many exploits of security holes and privacy holes in poorly-designed protocols. While it might be useful to publish an informational specification of a widely-deployed protocol on the theory that publishing it will make the public more aware of its limitations and help them migrate to better protocols, publishing a specification of a hazardous protocol that is not widely deployed can encourage wider deployment and increase the risk of harm. Keith is trying to raise the bar. I prefer to keep the bar low. I, frankly, don't see a problem with there being more crap published as RFCs, whether produced by WGs or produced by individuals. Publishing crap dilutes the value of the RFC series, and makes it more difficult for the public to recognize the good work that IETF does. It also costs money which could be better put to other uses. This was never the series' intent. We've attempted to warp it into this, and the result has been The Official Dogma, with a corresponding lack of development within the IETF. If we want to allow for REAL innovation WITHIN the IETF, then you have to let some crap through, and you have to trust the RFC Editor and others to hold the bar at some level. Eliot
Naming crap (Re: IESG review of RFC Editor documents)
Kurt, --On 26. mars 2004 18:14 -0800 Kurt D. Zeilenga [EMAIL PROTECTED] wrote: At 05:35 PM 3/26/2004, Eliot Lear wrote: Personally, I'm more concerned by WGs demanding their right to have their half-baked specifications published as RFCs, and the for IESG to approve them without any IETF review or other community review, or (as has happened in the past) even when substantial oversights or design flaws in those specifications were pointed out by individuals. Please cite an example. That, I think, would be counter productive. I think it fairly apparent that there is a fair amount of crap (by mine, your, or anyone's opinion) published as RFCs. I content that much of that crap was produced by the IETF. permit me to disagree. not with your core statement, but with the statement that citing examples would be counterproductive. The statement that a fair amount of crap is published as RFCs has been repeated for so long that it's almost become a mantra. However, in my opinion, for *every single one* of those RFCs, there's a reason why it was published. Usually there was a supporting constituency, and at least some opinion that publishing it was better for the Internet than not publishing it - certainly, for every standards-track RFC, there was at one time a majority view in the IESG that such was the case. If we are to change the process that produces this stuff, we HAVE to understand what the reasons are that reasonable, competent people produce things that are sub-par, broken or crap. And IMHO, we can't do that without saying what these unacceptable results of the process are. Moving from the generic to the specific might actually be an useful catharsis for the community - and just might change the community opinion from a lot of our 3000 RFCs are crap to there are 30 bad RFCs, 300 that could have been better and 3000 reasonably OK ones, or even to the quality control system does not work well enough, there are too many borderline cases. I don't think anonymous, class-based criticism will get us much further. We need to be specific about what our problems are. Harald
Re: IESG review of RFC Editor documents
Title: Converted from Rich Text Hi Eliot, Similarly, SOCKS went quite far before the IETF ever got a look at it. Why? Because we are no longer viewed as a place where development can seriously take place. Risk averse. You know that thing about running code? Taken too far we fail what I think part of our mission is, which is to be a place to collaborate, because everyone will have shown up with their respective running code, only to fight over whose running code (if anybody's) will become the standard. See, for instance, the XMPP/IMPP wars. I agree with you on this. I think we see already other groups working on IP protocols, avoiding the IETF. One could look at the example of RADIUS, for example. RADIUS was originally developed outside of the IETF, brought into the IETF, extended by a half-dozen SDOs and now the IETF is considering trying to clean up the current mess. The IETF has used individual submissions to make things a bit better, with some success. Part of the problem was that the we took so long to develop the follow-up to RADIUS - Diameter - that we completely missed the window, so the world kept extending RADIUS. John
