IESG review of RFC Editor documents - take 2
The following draft is in large measure based on reading the discussions on the IESG list. Two important notes: 1) It is not *possible* to write a document that everyone agrees with. This draft is based on a considered judgment of what's best for the IETF, after reading and thinking about all your comments. Thank you! 2) There are important parts of the RFC publication process that are NOT described here, because they are outside of IESG scope, such as the criteria and the review mechanisms the RFC Editor uses, or indeed whether independent submissions should be published or not. These are proper material for discussion with the RFC Editor, the IAB and the NEWTRK WG. But their omission from this document is NOT an accident. Unless this document is found fatally flawed in some way, I intend to ask for a 4-week Last Call for BCP this week. Thank you all for your review, and keep them coming! Harald 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-01.txt Pages : 7 Date: 2004-4-9 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-01.txt
Re: IESG review of RFC Editor documents
--On 27. mars 2004 15:53 -0800 Paul Hoffman / VPNC [EMAIL PROTECTED] wrote: 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. The concept of boilerplate disclaimers is already in there. Are you suggesting alternate text for the disclaimers? Do you intend to point to draft-iesg-rfced-documents when it's published, or to some other resource? - 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. Requirement on the RFC Editor - doesn't sound unreasonable, but out of scope for this document. - 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. I don't quite see the point of this, but anyway think that such a disclaimer belongs on the RFC Editor's pages, not in this document
Re: IESG review of RFC Editor documents
At 7:32 AM -0800 3/30/04, Harald Tveit Alvestrand wrote: --On 27. mars 2004 15:53 -0800 Paul Hoffman / VPNC [EMAIL PROTECTED] wrote: 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. The concept of boilerplate disclaimers is already in there. Are you suggesting alternate text for the disclaimers? I'm suggesting that this be added to, not replace, the current boilerplate for non-IESG-reviewed RFCs. Do you intend to point to draft-iesg-rfced-documents when it's published, or to some other resource? To the RFC that comes from draft-iesg-rfced-documents. - 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. Requirement on the RFC Editor - doesn't sound unreasonable, but out of scope for this document. Not really. Currently, when the IESG reviews non-standards-track documents, it makes a decision (or approves a request) for the status. This document puts that decision into the RFC Editor's hands. It would be good to give on-record advice for how the RFC Editor should make that decision, particularly since the recent experiences with making things Experimental are not consistent with the wording in 2026. - 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. I don't quite see the point of this, but anyway think that such a disclaimer belongs on the RFC Editor's pages, not in this document Probably true. Just taking another opportunity to try to reduce the work load of the IETF... --Paul Hoffman, Director --VPN Consortium
Re: IESG review of RFC Editor documents
At 12:29 PM -0800 3/30/04, Harald Tveit Alvestrand wrote: --On 30. mars 2004 09:51 -0800 Paul Hoffman / VPNC [EMAIL PROTECTED] wrote: Requirement on the RFC Editor - doesn't sound unreasonable, but out of scope for this document. Not really. Currently, when the IESG reviews non-standards-track documents, it makes a decision (or approves a request) for the status. This document puts that decision into the RFC Editor's hands. It would be good to give on-record advice for how the RFC Editor should make that decision, particularly since the recent experiences with making things Experimental are not consistent with the wording in 2026. it would be good, but that's not the IESG's role it is the IAB's. Ah, good point. Nevermind... --Paul Hoffman, Director --VPN Consortium
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. Interesting analogy. Though I'll note that there are different approaches to the use of fossil fuels in different parts of the world, one of which is use as much as you can afford and we'll do our best to keep prices low for the whole country and another is tax the worst wastage of fossil fuels and use the taxes to fund public transportation which has less impact on the environment, and the latter is at least arguably saner. In other words, if some practice causes harm when that practice is widespread, then _some_ kind of caution or restraint might be in order. Pretending that the problem doesn't exist doesn't seem wise. 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. I disagree with the statement as writen, but more importantly, with the implications of the statement. IETF cannot possibly be a home for all protocol development on the Internet. There are simply too many protocols. After all the Internet is supposed to be a general-purpose communications framework that can support an arbitrary number of applications. So a lot of protocol development will always be done outside of IETF, and this is a Good Sign. If we ever get to the point that protocol development can only be done within IETF (perhaps because the network imposes so many constraints that IETF is the only place they can be sorted out), we will have failed miserably. Furthermore there will always be vendors who prefer to let the market decide which protocol will be used than to let IETF decide for reasons that have nothing to do with IETF being too risk averse. Any vendor which has a substantial lead in market share will in general prefer to deploy first and later insist that IETF (or other standards-making body) either rubber-stamp or fix the bugs in its de facto standard - thus ensuring that they keep the competition in catch-up mode. There's nothing new about that, it's been happening for years. I'd also argue that much of the value that IETF adds (if it is doing its job right) consists of risk minimization - specifically minimizing the risk that customers who invest in deploying IETF standards will have substantial incentive to have to completely discard that investment within a short time. Now, clearly there's such a thing as being too risk averse, but I don't think that's our main problem. I am more concerned that we don't pay attention to some substantial risks until very late in our processes - when it's too late to fix the problems. 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. Maybe the problem is not just being risk averse, but our development style. Something tells me that having random, unstructured conversations for months on end and gaining consensus by exhaustion are not good ways to do protocol development. And only after the WG is exhausted do we do any serious external review. But it's not fair to blame the reviewers for being too risk averse when the WG failed to pay attention to those risks in the first place. Now the *perception* might be that we're too risk averse, just because we take so long to get protocols out the door. But while there are lots of ways to speed up the process, to simply be less risk adverse is to fail to do our jobs. 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. Those wars would have cropped up anywhere else that didn't simply cave in to pressure from one faction. You can't force people to agree, particularly when they think they gain a competitive advantage from not agreeing. 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. Face it, there's no way that the RFC series could have continued to be the Engineering Notebook for the Internet for all this time. The Internet has long since become too large and too diverse. The RFC series structure could never have accommodated it. Maybe something like a Wiki, but even that's a stretch. For that matter, no matter what the structure,
Re: IESG review of RFC Editor documents
A general opinion: I am incline towards looking for ways reduce the workload of the RFC editors and if possible the IESG. The size of the IETF these days does not allows us to function in the old ways without substainable support. As such, I believe a review of RFC 1543 may be useful. I mean, most people only see I-Ds and RFCs and have largely ignore the other STDs and BCPs. Maybe we just have too many classification under RFC series and perhaps we should consider having something between I-D and RFC for Informational and Experimental doc. Such class may be published with little review from IESG and less work on RFC Editors (so long the std templates and copyrights are in place) -James Seng Harald Tveit Alvestrand wrote: --On 28. mars 2004 01:35 +0800 James Seng [EMAIL PROTECTED] wrote: Few questions: Thanks, James! 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? Experimental documents are not (in themselves) candidates for any level of Internet Standard. Revisions of the ideas therein may be - and the same thing can happen to Informationals. This needs to be clearer. (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. It wasn't very clear to me either when I wrote it. Beside, wasn't individual submission already (maybe) subjected to 4 weeks last call? Does this qualify as 'IETF review'? No - the Last Call is only done for standards-track and BCP, not for the Info and Experimental sent in via the RFC Editor. (sometimes we've done it in the past, but it's unlikely to happen under this procedure.) and yes, a 4-week Last Call + the procedure that led an AD to conclude that it was ready for last call *does* qualify as IETF review!
Re: Naming crap (Re: IESG review of RFC Editor documents)
On 29-mrt-04, at 6:16, Donald Eastlake 3rd wrote: To me it seems that the IETF can't make up its mind: are RFCs just drafts that don't expire, or are they hugely important documents that must be absolutely perfect before they are published? Why does it have to be one of your two alternatives? Above I'm not describing what should be, or even what is, but what it seems like to me. RFC's are like books. No book is perfect. Almost all books undergo significant review, copy editing, etc,, before publication. The book analogy can work up to a point, but for certain types of documents it makes very little sense. A book can't be changed after it has been printed, so it reflects knowledge at a certain point in time by its nature (and also often times by design). However, true engineering documents change from time to time, no matter how hard the push is to get it right the first time. There is no copyediting like trying to implement a protocol... It would of course help if RFC authors would stick to the point of their RFC rather than discuss all the potential ways in which their protocol could be useful. Draft authors are even worse, 75% of most drafts is spent justifying the draft. The problem is version control. We're engineers. That means we are, more so than mere mortals, doomed never to get anything right the first time out. However, the RFC publishing model doesn't really allow for incremental changes: you have to write a completely new RFC, which then gets a new number that has no relation to the original RFC. While it is normally the case that an RFC is revised by the publication of a new RFC which obsoletes the old, this is not necessarily the only way to do it. If there are a significant volume of changes but still only a small amount compated to the size of the original RFC, it is possible to publish and updating RFC, at least for Informational RFCs. See RFC 2801 and 3504. There is also an errata mechanism maintained by the RFC Editor. Then explain to me the existence of RFC 1918 with regards to RFC 1597. What we need is a way to add information to RFCs whithout the need to rewrite the original RFC or make the new information a full-blown RFC of its own. There is clearly no way to do what you want with printed books, which are what RFCs are modelled after. And email is modeled after letter writing, so what's up with this quoting thing that we're doing here??? To get the effect you want, people would need to go to a web resource or the like. But if they are willing to do that, then they can almost as eaily find out about errata and whether the RFC they are looking for has been obsoleted. The alternative is that they use a printout of an RFC. Anyone willing to create such a printout can just as easily print the whole family of documents that make up a standard. I also notice that you ignore all the problems of fluid specifications that constantly change on line so that no two people/implementers can be sure they are working from the same spec unless they agreed on a time stamp, etc. Oh yes, the current situation where people implement drafts, RFCs continue to have small but potentially lethal errors in them and new replacement RFCs are published in a way that is impossible to determine from looking at the RFC they're replacing is so much better. I suggest we form a task force of people who all implemented at least three RFCs times as many RFCs as they authored and let them tell us what's right and what's wrong here.
Re: IESG review of RFC Editor documents
Keith Moore wrote: Okay, I read draft-iesg-rfced-documents-00.txt regarding a proposed change in IESG policy regarding RFC-Ed documents. I'm opposed to the change, because I believe it would make it too easy for harmful documents to be published as RFCs. As someone who has been waiting over a year to publish an informational RFC, I could not disagree more. The RFC-Editor (disclaimer - also at ISI) has sufficient authority to reject submissions which are either 'clearly bogus' or do not cross the hurdle from marketing blurb to protocol spec. ... A big part of the problem is that the proposed policy would only allow IESG to object to the publication of a document in the case where there was an active working group in an area, or where the document would violate a pre-established procedure. To the extent that the IESG has done otherwise in the past, IMO it has violated its authority. I appreciate that the IESG has 'voted' to do otherwise, but I don't recall how it ever got the authority to act as TPC for individual submissions in the first place. ... Since working groups are typically chartered to work on a narrow topic and for a limited time, at any given time many technical subject areas are not covered by a working group, and many new protocols would not conflict with any particular working group even if they would conflict with (for instance) the operation of established protocols. Alternatively - speaking from experience - new protocols or techinques could be developed and circulate ad-infinitum among the churn of emerging WGs, in a continuing effort to avoid perceived potential overlap. -In order to be considered worthy of review, any individual submission must first have the support of two (maybe three) members of the group consisting of all current IESG members,all current IAB members,and all current WG chairs. Sometimes these docs are 'reviewed' by 'informed' ADs who request WG review - of a WG to whom the document _has already been repeatedly presented_. Asking for the consensus of any UNANIMOUS snapshot of IESG, IAB, and WG chairs would certainly cut down on the published RFCs. We might end up with none. These proposals further don't consider the historical value of minority opinions or alternative approaches. Those docs won't ever be published if unanimous consent is required. IMO, the IESG already has a series over which it has complete editorial control - standards track. Leave something for the rest of the Internet community, please. Joe signature.asc Description: OpenPGP digital signature
Re: Naming crap (Re: IESG review of RFC Editor documents)
Far too obvious! jfc At 09:17 29/03/04, David Morris wrote: On Sun, 28 Mar 2004, Donald Eastlake 3rd wrote: There is clearly no way to do what you want with printed books, which are what RFCs are modelled after. To get the effect you want, people would need to go to a web resource or the like. But if they are willing to do that, then they can almost as eaily find out about errata and whether the RFC they are looking for has been obsoleted. I also notice that you ignore all the problems of fluid specifications that constantly change on line so that no two people/implementers can be sure they are working from the same spec unless they agreed on a time stamp, etc. Without changing any of the publication process, RFC identification could be changed to more clearly show the history and make it very clear what the current RFC version was by using a -N suffix (where N is an incremental version following the original). No external index would be required to document that RFC xxx-2 supercedes RFC xxx-1. There is a small loss of the obvious time series relationship one can now determine from the simple number. A penalty I'd gladly pay to have obvious documentation of relationships. In the case where an RFC (e.g. abc-3) was superceded by another RFC (e.g., bcd), then RFC abc-4 could be published to be a small placeholder reference to RFC bcd. Whether HTTP/1.1 superceded HTTP/1.0 or was a new -number should be determined by the IESG on the recommendation of the WG/AD. Dave Morris
Re: Naming crap (Re: IESG review of RFC Editor documents)
On 27-mrt-04, at 18:36, Harald Tveit Alvestrand wrote: 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. [...] I don't think anonymous, class-based criticism will get us much further. We need to be specific about what our problems are. To me it seems that the IETF can't make up its mind: are RFCs just drafts that don't expire, or are they hugely important documents that must be absolutely perfect before they are published? The problem is version control. We're engineers. That means we are, more so than mere mortals, doomed never to get anything right the first time out. However, the RFC publishing model doesn't really allow for incremental changes: you have to write a completely new RFC, which then gets a new number that has no relation to the original RFC. What we need is a way to add information to RFCs whithout the need to rewrite the original RFC or make the new information a full-blown RFC of its own.
RE: Naming crap (Re: IESG review of RFC Editor documents)
In the spirit of well, if highlighting a difference of opinion is the first step toward resolving it, then we're on our way.: Can we can ask Amazon to include RFCs in their product listings, and then let reviewers, consumers, proponents and objectors to use product rating mechanisms to help guide potential readers of documents as to their value. The IESG could provide an editor's rating. I am more than half serious (in terms of architecture, implementation could be different). regards, peterf
RE: Naming crap (Re: IESG review of RFC Editor documents)
| -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On | Behalf Of Iljitsch van Beijnum | Sent: Sunday, March 28, 2004 9:38 PM | To: Harald Tveit Alvestrand | Cc: IETF Discussion | Subject: Re: Naming crap (Re: IESG review of RFC Editor documents) | | On 27-mrt-04, at 18:36, Harald Tveit Alvestrand wrote: | | 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. | | [...] | | I don't think anonymous, class-based criticism will get us much | further. We need to be specific about what our problems are. | | To me it seems that the IETF can't make up its mind: are | RFCs just drafts that don't expire, or are they hugely | important documents that must be absolutely perfect before | they are published? | | The problem is version control. We're engineers. That means | we are, more so than mere mortals, doomed never to get | anything right the first time out. However, the RFC | publishing model doesn't really allow for incremental | changes: you have to write a completely new RFC, which then | gets a new number that has no relation to the original RFC. | | What we need is a way to add information to RFCs whithout | the need to rewrite the original RFC or make the new | information a full-blown RFC of its own. Personally and from observation it would appear RFCs are stand alone documents that do not get revised. They get superseded by new RFCs covering the same topic. Perhaps the way to approach this particular issue is to provide better navigation aids through the various RFCs so that it is easier for users to find all the related documents showing the relationship (timeline and validity) between the documents. A more involved and comprehensive document management system. Darryl (Dassa) Lynch
Re: Naming crap (Re: IESG review of RFC Editor documents)
From: Dassa [EMAIL PROTECTED] To: 'Iljitsch van Beijnum' [EMAIL PROTECTED]; 'Harald Tveit Alvestrand' [EMAIL PROTECTED] Cc: 'IETF Discussion' [EMAIL PROTECTED] Sent: Sunday, March 28, 2004 3:37 PM Subject: RE: Naming crap (Re: IESG review of RFC Editor documents) Personally and from observation it would appear RFCs are stand alone documents that do not get revised. They get superseded by new RFCs covering the same topic. Perhaps the way to approach this particular issue is to provide better navigation aids through the various RFCs so that it is easier for users to find all the related documents showing the relationship (timeline and validity) between the documents. A more involved and comprehensive document management system. Yes, exactly, and if anyone following this thread has not read http://www.ietf.org/internet-drafts/draft-loughney-what-standards-01.txt yet, that's unfortunate. John Loughney is faithfully working this issue, without a lot of feedback, positive or negative, and he is SO right. My suggestion is to read this draft and provide feedback on Newtrk (http://darkwing.uoregon.edu/~llynch/newtrk.html). Thanks, Spencer
Re: Naming crap (Re: IESG review of RFC Editor documents)
On Sun, 28 Mar 2004, Iljitsch van Beijnum wrote: Date: Sun, 28 Mar 2004 13:38:13 +0200 From: Iljitsch van Beijnum [EMAIL PROTECTED] Cc: IETF Discussion [EMAIL PROTECTED] ... To me it seems that the IETF can't make up its mind: are RFCs just drafts that don't expire, or are they hugely important documents that must be absolutely perfect before they are published? Why does it have to be one of your two alternatives? RFC's are like books. No book is perfect. Almost all books undergo significant review, copy editing, etc,, before publication. The problem is version control. We're engineers. That means we are, more so than mere mortals, doomed never to get anything right the first time out. However, the RFC publishing model doesn't really allow for incremental changes: you have to write a completely new RFC, which then gets a new number that has no relation to the original RFC. While it is normally the case that an RFC is revised by the publication of a new RFC which obsoletes the old, this is not necessarily the only way to do it. If there are a significant volume of changes but still only a small amount compated to the size of the original RFC, it is possible to publish and updating RFC, at least for Informational RFCs. See RFC 2801 and 3504. There is also an errata mechanism maintained by the RFC Editor. What we need is a way to add information to RFCs whithout the need to rewrite the original RFC or make the new information a full-blown RFC of its own. There is clearly no way to do what you want with printed books, which are what RFCs are modelled after. To get the effect you want, people would need to go to a web resource or the like. But if they are willing to do that, then they can almost as eaily find out about errata and whether the RFC they are looking for has been obsoleted. I also notice that you ignore all the problems of fluid specifications that constantly change on line so that no two people/implementers can be sure they are working from the same spec unless they agreed on a time stamp, etc. Thanks, Donald == Donald E. Eastlake 3rd [EMAIL PROTECTED] 155 Beaver Street +1-508-634-2066(h) +1-508-786-7554(w) Milford, MA 01757 USA [EMAIL PROTECTED]
Re: IESG review of RFC Editor documents
--On 27. mars 2004 13:12 -0500 Scott Bradner [EMAIL PROTECTED] wrote: 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? yes!
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
Re: IESG review of RFC Editor documents
Copy of the announcement below. One quick question Harald - am I right that the new procedure applies only to RFCs, not I-Ds? Any plans in the works for changing the way I-Ds are reviewed?
Re: IESG review of RFC Editor documents
Harald, As you know, I favor moving in this general direction. Three comments on specifics: (1) The standard IESG note discussed in section 4 seems tailored to documents that specify protocols or operational procedures and, for that purpose, the notes suggested seem plausible. However, a some proportion of the independent submission documents submitted to the RFC Editor are of the nature of commentary, without proposing an Internet protocol or the equivalent. A somewhat toned-down version of the note might be appropriate for that purpose. (2) We have, for many years, provided for the publication of the work of other standards bodies or groups for the convenience of the IETF community. For that case, the standard IESG note may not be quite right and might actually be taken as insulting to the other group. Instead, some statement noting that the document is a document of group X, was published with their permission (or at their request), and that publication is for the convenience of the Internet (or IETF) community but does not constitute endorsement or approval by the IETF would seem to me to be quite sufficient. (3) The traditional exception for April 1 RFCs should probably be reflected in this document. This could most easily be accomplished, IMO, by modifying the first paragraph of section 3 to indicate that the IESG and RFC Editor (or the IAB and RFC Editor, see immediately below) may agree on classes of documents that are not subject to this review. (4) The document ignores the traditional path of a document from the IAB to the RFC Editor, in which IESG review has been treated as an optional courtesy, not a requirement. It is also not clear that the IESG should request or recommend the rather strongly-worded disclaimers of section 4 for IAB documents. In any event, it is not, IMO, within the authority of the IESG to change the relationship between the RFC Editor and IAB. This could, of course, be subsumed under the classes of documents exception proposed above if the agreement involved the IAB and RFC Editor. Nice job. john --On Friday, 26 March, 2004 06:51 -0800 Harald Tveit Alvestrand [EMAIL PROTECTED] wrote: 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).
Re: IESG review of RFC Editor documents
--On 26. mars 2004 10:26 -0500 Susan Harris [EMAIL PROTECTED] wrote: Copy of the announcement below. One quick question Harald - am I right that the new procedure applies only to RFCs, not I-Ds? Any plans in the works for changing the way I-Ds are reviewed? Susan, not sure I understand you. all RFCs are I-Ds before they become RFCs, and review only makes sense before they become RFCs. There's no proposal to change the way I-Ds get published, and this proposal does not affect the treatment of I-Ds that are worked on within the IETF. Harald
IESG review of RFC Editor documents
Okay, I read draft-iesg-rfced-documents-00.txt regarding a proposed change in IESG policy regarding RFC-Ed documents. I'm opposed to the change, because I believe it would make it too easy for harmful documents to be published as RFCs. Part of the problem is the familiar one that RFCs are often used as standards even when they carry the Informational or Experimental label. Publishing an Informational RFC is therefore a way to get the appearance of standardization and IETF imprimatur without actually having to produce a sound technical design, achieve rough consensus, and endure review from IESG and interested parties. A big part of the problem is that the proposed policy would only allow IESG to object to the publication of a document in the case where there was an active working group in an area, or where the document would violate a pre-established procedure. Since working groups are typically chartered to work on a narrow topic and for a limited time, at any given time many technical subject areas are not covered by a working group, and many new protocols would not conflict with any particular working group even if they would conflict with (for instance) the operation of established protocols. Many believe it's unreasonable for IESG to spend its time reviewing documents for which there is no broad support. However, if it is unreasonable to expect IESG volunteers to perform adequate technical review on documents for which there is no broad support, surely it is even less reasonable to expect the RFC Editor (which appears to have even more limited resources and less breadth than the IESG) to perform such review. And while the RFC Editor could (and I assume does) enlist volunteers to assist it in such review, this amounts to an approval process for IETF publications that isn't accountable to the IETF community, not even with a noncom-like mechanism. I do think we need to find a better way to deal with individual submissions. I don't think that for IESG to simply say this is the RFC Editor's problem is sufficient. Here's an alternate proposal: - In order to be considered worthy of review, any individual submission must first have the support of two (maybe three) members of the group consisting of all current IESG members, all current IAB members, and all current WG chairs. - Such proposals are then subject to a 4-week Last Call for Informational or Experimental. - A significant show of support in the form of Last Call comments would normally be required for publication. - Review of such proposals and their Last Calls would be conducted by a panel of volunteers appointed by IESG. For instance, each AD could appoint one person. The review panel could vote on whether to recommend publication, request revisions in light of Last Call or reviewers' comments, or to recommend against publication in light of Last Call comments (or lack of support). - If the review board recommends publications, the RFC Editor would perform the same functions on these documents that it performs for WG Informational and/or Experimental documents. - Decisions of the review board would be subject to appeal to IESG.
Re: IESG review of RFC Editor documents
I disagree with Keith and think the document should be moved forward (with John's caveats about the notes for different types of documents). However, to address one of Keith's specific points: On 3/26/04 at 4:21 PM -0500, Keith Moore wrote: A big part of the problem is that the proposed policy would only allow IESG to object to the publication of a document in the case where there was an active working group in an area, or where the document would violate a pre-established procedure. Since working groups are typically chartered to work on a narrow topic and for a limited time, at any given time many technical subject areas are not covered by a working group, and many new protocols would not conflict with any particular working group even if they would conflict with (for instance) the operation of established protocols. No, there is one other item mentioned which covers this case: o 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. If the IESG thinks that a protocol would conflict with the operation of established protocols, they can recommend rejection on that basis. And while the RFC Editor could (and I assume does) enlist volunteers to assist it in such review, this amounts to an approval process for IETF publications that isn't accountable to the IETF community, not even with a noncom-like mechanism. Of course, even in the current de facto system of IESG review, the RFC Editor has the ability (under the current written rules) to ignore the IESG even if it recommends against publication and publish anyway. As far as I know, we've never come to that particular constitutional crisis. Suffice it to say, I think Keith's suggested alternative proposal is just wrongheaded. -- Pete Resnick http://www.qualcomm.com/~presnick/ QUALCOMM Incorporated
Re: IESG review of RFC Editor documents
a few comments on the IESG proposal: from draft-iesg-rfced-documents-00.txt 2. Background material The review of independent submissions by the IESG was prescribed by RFC 2026 [1] section 4.2.3 and RFC 2418 [2] section 8. RFC 3710 [3] section 5.2.2 describes the spring 2003 review process; with the publication of this document, that section is no longer relevant to documents submitted via the RFC Editor. fwiw - I think that this proposal is completely compatible with the intent of RFC 2026 section 4.2.3 and with the practice of the IESG at the time that RFC 2026 was approved. 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). 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. I think this is a good retro-move. Scott
Re: IESG review of RFC Editor documents
Thanks John - I will incorporate words based on your concerns in the next revision! Harald --On 26. mars 2004 10:46 -0500 John C Klensin [EMAIL PROTECTED] wrote: Harald, As you know, I favor moving in this general direction. Three comments on specifics:
Re: IESG review of RFC Editor documents
Keith, Okay, I read draft-iesg-rfced-documents-00.txt regarding a proposed change in IESG policy regarding RFC-Ed documents. I'm opposed to the change, because I believe it would make it too easy for harmful documents to be published as RFCs. As I'm sure you well know, the RFC Editor takes very seriously their obligations to provide thorough review of non-IETF documents. In fact, what makes you think that the IESG is more conservative than the RFC Editor? Eliot
Re: IESG review of RFC Editor documents
And while the RFC Editor could (and I assume does) enlist volunteers to assist it in such review, this amounts to an approval process for IETF publications that isn't accountable to the IETF community, not even with a noncom-like mechanism. Of course, even in the current de facto system of IESG review, the RFC Editor has the ability (under the current written rules) to ignore the IESG even if it recommends against publication and publish anyway. As far as I know, we've never come to that particular constitutional crisis. IIRC it happened at least twice while I was on IESG.
Re: IESG review of RFC Editor documents
Okay, I read draft-iesg-rfced-documents-00.txt regarding a proposed change in IESG policy regarding RFC-Ed documents. I'm opposed to the change, because I believe it would make it too easy for harmful documents to be published as RFCs. As I'm sure you well know, the RFC Editor takes very seriously their obligations to provide thorough review of non-IETF documents. not in my experience. Keith
Re: IESG review of RFC Editor documents
Keith, Pete has covered most of what I would have said, but I want to address one other issue with your comments/ suggestions. It seems to me that at least latent in your suggestions is the assumption that the RFC Editor should publish only IETF consensus documents or documents that are in general agreement with IETF consensus. My sense is almost exactly the opposite. The IESG is not omniscient and wouldn't be omniscient even if they had a lot more time. The IETF isn't omniscient either. And nothing in our process, including the appeals process, is designed to deal effectively with something that has consensus, including IESG consensus, but is still wrong-headed. IMO, one of the most valuable types of documents the RFC Editor could publish would be an independent, in-depth analysis of why some standards-track document was an operational hazard and generally a complete crock of excrement. Now I would expect that a very high editorial and technical standard would be applied to the arguments of such a document. I would expect it to be excruciatingly clear that the positions it was taking were in disagreement with an IETF Standards-Track procedure. But I would hope it would be publishable, and, given those document quality standards, published, even if every single member of the IESG disagreed with its stated position. Clearly-stated dissent is not harmful. Indeed, I suggest that it is healthy. And the procedure you propose would tend to suppress such dissent, no matter how well reasoned that dissent was. More broadly, our standards process has an almost-unique property relative to most other standards groups in the information technology area (and relative to all of those I would consider even moderately successful). In their processes, there comes a point in the approval process in which people who disagree with the proposed document are explicitly identified along with their disagreements and, in some form, exactly what it would take to get them to agree. Then there is a very serious process to try to resolve the disagreements and, if that fails, often nearly-automatic appeals on the substance of the proposal, documentation of the disagreements, and so on. That model has some advantages and many disadvantages but the important thing is that we don't use it. Instead, we use the notion of rough consensus to essentially run over dissent by small minorities, even small minority dissent that is well-reasoned and has significant merit. And our appeals is useless in dealing with that issue because the rough consensus really does exist. And that makes the ability for the dissenters to write a dissent, and have it published in near proximity to the official/standard specification, really important to preserving the openness and honesty of the system. Without it, all sorts of theories about cabals become very plausible. Now we haven't used that mechanism very much. In my personal opinion, we haven't used it nearly often enough -- especially in the last several years, the losing dissenters have tended to just go away rather than documenting their positions --but that is another issue. But taking it away, which I think your suggestion would ultimately do, could ultimately be extremely harmful to our standardization model. john --On Friday, 26 March, 2004 16:21 -0500 Keith Moore [EMAIL PROTECTED] wrote: Okay, I read draft-iesg-rfced-documents-00.txt regarding a proposed change in IESG policy regarding RFC-Ed documents. I'm opposed to the change, because I believe it would make it too easy for harmful documents to be published as RFCs. ...
Re: IESG review of RFC Editor documents
It seems to me that at least latent in your suggestions is the assumption that the RFC Editor should publish only IETF consensus documents or documents that are in general agreement with IETF consensus. Actually, my assumption is that only documents for which there is a significant supporting constituency should be considered for publication as RFCs. So for instance, if a different well-recognized standards body wants to publish something as an RFC, I don't have a problem with that, as long as it's clearly labeled as being from that standards body. Or if a WG specification doesn't manage to meet the requirements for standards track but the WG wants to publish that specification as an Informational RFC, as a record of the work that was done in case the problems can be solved in the future, I don't have a problem with that either, as long as it's clearly marked and the identified problems are also mentioned in the document. 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. My sense is almost exactly the opposite. The IESG is not omniscient and wouldn't be omniscient even if they had a lot more time. The IETF isn't omniscient either. Nor, for that matter, is the RFC Editor. But IESG is IMHO much more likely to catch problems in an individual submission than the RFC Editor. And unlike RFC Editor decisions, IESG decisions can be appealed. IMO, one of the most valuable types of documents the RFC Editor could publish would be an independent, in-depth analysis of why some standards-track document was an operational hazard and generally a complete crock of excrement. Now I would expect that a very high editorial and technical standard would be applied to the arguments of such a document. I would expect it to be excruciatingly clear that the positions it was taking were in disagreement with an IETF Standards-Track procedure. But I would hope it would be publishable, and, given those document quality standards, published, even if every single member of the IESG disagreed with its stated position. I don't have an inherent problem with that either. However I haven't seen any defined very high editorial and technical standard for such documents, which makes me wonder if this amounts to the whim of the RFC Editor. I think we're long past the day when any two or three people, no matter how intelligent or experienced, can profess to understand Internet protocols in enough breadth to be the sole judge of what should merit publication on behalf of IETF. And like it or not, if there is no other well-identified supporting consistency for an RFC, it's assumed by the public to have IETF backing. Clearly-stated dissent is not harmful. Indeed, I suggest that it is healthy. And the procedure you propose would tend to suppress such dissent, no matter how well reasoned that dissent was. Clearly-stated dissent is not harmful. But inflating it to appear to have equal or near-equal standing with community consensus can be misleading. I can think of a number of topics for which I'd like to get on a soap box and have my clearly-stated dissent published as RFCs: scoped addressing, encoding routing policy in address bits, and autoconfiguration systems being a few of the interesting and timely topics that come to mind. However I don't think I have the right to demand that the RFC Editor provide, and ISOC fund, a soap box that appears to give my personal opinion near-equal weight to the consensus of IETF. And I don't think it scales very well. OTOH, I would certainly like to see a process that allowed well-supported minority opinions to get some recognition. Instead, we use the notion of rough consensus to essentially run over dissent by small minorities, even small minority dissent that is well-reasoned and has significant merit. And our appeals is useless in dealing with that issue because the rough consensus really does exist. And that makes the ability for the dissenters to write a dissent, and have it published in near proximity to the official/standard specification, really important to preserving the openness and honesty of the system. Without it, all sorts of theories about cabals become very plausible. Now we haven't used that mechanism very much. In my personal opinion, we haven't used it nearly often enough -- especially in the last several years, the losing dissenters have tended to just go away rather than documenting their positions --but that is another issue. But taking it away, which I think your suggestion would ultimately do, could ultimately be extremely harmful to our standardization model. My opinion is that if we're going to
Re: IESG review of RFC Editor documents
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. In what case was there not a last call? Eliot
Re: IESG review of RFC Editor documents
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. But my point, in regards to this proposal, is that the bar for Informational/Experimental is not half-baked nor won't cause harm nor crap, but whether it provides information is of reasonable use to the Internet technical community and meets the (low) editorial/technical standards for RFCs. 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. In what case was there not a last call? WG documents submitted for Informational and Experimental publication are not necessarily subject to IETF Last Call. Also note that IESG review of such document is minimal (per RFC 2418). Kurt
Re: IESG review of RFC Editor documents
At 07:06 PM 3/26/2004, Keith Moore wrote: But my point, in regards to this proposal, is that the bar for Informational/Experimental is not half-baked nor won't cause harm nor crap, but whether it provides information is of reasonable use to the Internet technical community and meets the (low) editorial/technical standards for RFCs. For information to be of reasonable use it needs to be reasonably accurate. I disagree. A document which has significant technical errors and omissions can still be reasonable useful to the technical community. The document need only be meet general editorial and technical standards, it need not nor should be subjected to anything more than a minimal review (beyond that provided by its producers). Opinions can also be useful, if nothing else to students of history, if the opinions are clearly labeled as such, and if they help illustrate a historically important debate. I have no objection to labels (e.g., Experimental) and standardized disclaimers in such memos. These days, for a protocol specification to be of reasonable use on a wide scale it needs to avoid causing harm. Experimental and Informational memos need not be engineered for wide scale use. They might just detail an small scale experiment or detail an existing limited-use protocol. The standardized disclaimer should caution readers that the document may not be suitable for implementation/use on the Internet. 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. I consider this part of the Informational/Experimental v Standard Track trade-off. In having a series with minimal review, we accept risk that such documents will have not adequately address various considerations. 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. I agree that it hard to distinguish IETF-produced RFCs from individually-produced RFCs (this seems to be somewhat by design) and, I think, a separate issue from crap on the RFC series. The only distinction I see is that the IETF can produce (by WG or individual submission to it) crap on any track and Individuals can only produce crap on Informational/Experimental. While detailed review focused on the latter might reduce the latter, I don't see it nearly as problematic as the former. A certain amount of crap RFCs is to be expected and reasonable especially on Informational and Experimental tracks (regardless of producer). Minimal review has been, IMO, sufficient to keep the amount of crap to acceptable amount. It also costs money which could be better put to other uses. Personally, I believe the money spent doing minimal review is money well spent. However, I would be supportive of use of volunteer minimal reviewers to cut review costs. Kurt
