Re: Forbidden RFC (Was: Should the RFC Editor publish an RFC in less than 2 months?
On Dec 14, 2007, at 1:34 PM, Stephane Bortzmeyer wrote: On Thu, Dec 13, 2007 at 07:17:15PM -0500, Russ Housley [EMAIL PROTECTED] wrote a message of 31 lines which said: Another possible remedy might be to withdraw the RFC. This remedy is not as attractive because there is no procedure to do it. Is it to test the future procedure that RFC 4390 is no longer downloadable? :-) http://www.ietf.org/rfc/rfc4390.txt Forbidden You don't have permission to access /rfc/rfc4390.txt on this server. Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request. Apache/2.0.52 (Red Hat) Server at www.ietf.org Port 80 http://www.ietf.org/rfc/rfc4390 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Forbidden RFC (Was: Should the RFC Editor publish an RFC in less than 2 months?
On Thu, Dec 13, 2007 at 07:17:15PM -0500, Russ Housley [EMAIL PROTECTED] wrote a message of 31 lines which said: Another possible remedy might be to withdraw the RFC. This remedy is not as attractive because there is no procedure to do it. Is it to test the future procedure that RFC 4390 is no longer downloadable? :-) http://www.ietf.org/rfc/rfc4390.txt Forbidden You don't have permission to access /rfc/rfc4390.txt on this server. Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request. Apache/2.0.52 (Red Hat) Server at www.ietf.org Port 80 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
[Inquiry #98454] Forbidden RFC (Was: Should the RFC Editor publish an RFC in less than 2 months?
On Fri, Dec 14, 2007 at 02:10:14PM +, Roy Arends [EMAIL PROTECTED] wrote a message of 24 lines which said: http://www.ietf.org/rfc/rfc4390.txt Forbidden ... http://www.ietf.org/rfc/rfc4390 It works again now (someone probably fixed it). Nothing to do with the URL, both URL were and are fine. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Forbidden RFC (Was: Should the RFC Editor publish an RFC in less than 2 months?
On Dec 14, 2007 9:19 AM, Marshall Eubanks [EMAIL PROTECTED] wrote: I know that there is work going on today with the transfer of services from NSS to AMS, and I suspect that these errors may be connected to this. It may be, but according to Ray Pelletier (Administrative Director), the DNS changes wouldn't be started until about noon Eastern (1700 UTC). With a 404 error, it sounds like someone may have been doing some cleanup on the server. In any case, it'll be interesting to see how smoothly the transitions go, starting in about an hour and a half. -- Daniel P. Brown [Phone Numbers Go Here!] [They're Hidden From View!] If at first you don't succeed, stick to what you know best so that you can make enough money to pay someone else to do it for you. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Forbidden RFC (Was: Should the RFC Editor publish an RFC in less than 2 months?
Stephane Bortzmeyer wrote: On Thu, Dec 13, 2007 at 07:17:15PM -0500, Russ Housley [EMAIL PROTECTED] wrote a message of 31 lines which said: Another possible remedy might be to withdraw the RFC. This remedy is not as attractive because there is no procedure to do it. Is it to test the future procedure that RFC 4390 is no longer downloadable? :-) http://www.ietf.org/rfc/rfc4390.txt Forbidden Syephane - you get the same thing when you go to http://www.ietf.org/rfc.html or any RFC for that matter. I think there is a configuration problem with the server. cheers joe baptista You don't have permission to access /rfc/rfc4390.txt on this server. Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request. Apache/2.0.52 (Red Hat) Server at www.ietf.org Port 80 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf -- Joe Baptistawww.publicroot.org PublicRoot Consortium The future of the Internet is Open, Transparent, Inclusive, Representative Accountable to the Internet community @large. Office: +1 (202) 517-1593 Fax: +1 (509) 479-0084 begin:vcard fn:Joe Baptista n:Baptista;Joe org:PublicRoot Consortium adr:;;963 Ford Street;Peterborough;Ontario;K9J 5V5 ;Canada email;internet:[EMAIL PROTECTED] title:PublicRoot Representative tel;fax:+1 (509) 479-0084 tel;cell:+1 (416) 912-6551 x-mozilla-html:FALSE url:http://www.publicroot.org version:2.1 end:vcard ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Forbidden RFC (Was: Should the RFC Editor publish an RFC in less than 2 months?
* * http://www.ietf.org/rfc/rfc4390 * Or the RFC Editor web site works: http://www.rfc-editor.org/rfc/rfc4390 since the RFC Editor's archive is in fact primary. RFC Editor * ___ * Ietf mailing list * Ietf@ietf.org * https://www1.ietf.org/mailman/listinfo/ietf * ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Forbidden RFC (Was: Should the RFC Editor publish an RFC in less than 2 months?
This URL works for me ... At 08:34 AM 12/14/2007, Stephane Bortzmeyer wrote: http://www.ietf.org/rfc/rfc4390.txt ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Forbidden RFC (Was: Should the RFC Editor publish an RFC in less than 2 months?
On Fri, Dec 14, 2007 at 02:07:44PM -0500, Russ Housley [EMAIL PROTECTED] wrote a message of 4 lines which said: This URL works for me ... Yes, it has been fixed in the mean time. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
The discussion of this topic has died down, so it is time for me to make a consensus call. It is quite clear to me that the community does not want to delay the publication of RFCs. Therefore, in this note, I am asking the RFC Editor to publish RFCs as soon as Auth48 is complete. If there is a successful appeal against the approval of an Internet-Draft, then the IESG will offer a remedy. One possible remedy is to classify the RFC as Historic, and another possible remedy is to progress a new RFC that obsoletes the earlier one and contains some appropriate correction. These remedies are attractive because no new processes or procedures are needed. Another possible remedy might be to withdraw the RFC. This remedy is not as attractive because there is no procedure to do it. However, this discussion has raised a few situations where this might be considered the appropriate action. The IAB, in their oversight role, must approve the general policy followed by the RFC Editor. So, I am asking the IAB to consider the potential need to withdraw an RFC. Hopefully this will never be needed, but some thought about the way that it would be handled will be useful, just in case. Many thanks, Russ Housley IETF Chair ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
On 2007-12-02 10:38 Bob Hinden said the following: ... Based on the past record, we're talking about something that happens 0.58% of the time, or less. Of course, predicting the future from the past is iffy; there have been 10 appeals in 2006 and only one (not document related) in 2007, so it varies. Thanks for looking at the data. It seems to me that we shouldn't be delaying all new RFCs for a problem that only occurs .58% of the time. +1 Henrik ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
hmmm... Henrik Levkowetz wrote: On 2007-12-02 10:38 Bob Hinden said the following: ... Based on the past record, we're talking about something that happens 0.58% of the time, or less. Of course, predicting the future from the past is iffy; there have been 10 appeals in 2006 and only one (not document related) in 2007, so it varies. Thanks for looking at the data. It seems to me that we shouldn't be delaying all new RFCs for a problem that only occurs .58% of the time. so if we are talking about all documents; what is the percentage that is (could be) actually published before 60 days and how many days before day 60 is that (typically) /Loa +1 Henrik -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: [EMAIL PROTECTED] [EMAIL PROTECTED] This email was Anti Virus checked by Astaro Security Gateway. http://www.astaro.com ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
+1 From: Henrik Levkowetz [EMAIL PROTECTED] Date: Wed, 05 Dec 2007 13:37:05 -0800 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], ietf ietf@ietf.org, iesg [EMAIL PROTECTED] Subject: Re: Should the RFC Editor publish an RFC in less than 2 months? On 2007-12-02 10:38 Bob Hinden said the following: ... Based on the past record, we're talking about something that happens 0.58% of the time, or less. Of course, predicting the future from the past is iffy; there have been 10 appeals in 2006 and only one (not document related) in 2007, so it varies. Thanks for looking at the data. It seems to me that we shouldn't be delaying all new RFCs for a problem that only occurs .58% of the time. +1 Henrik ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
Date:Tue, 04 Dec 2007 09:04:38 +1300 From:Brian E Carpenter [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] | It's the instant of formal publication, and that changes at least | two things: | | 1. It allows other SDOs that require a normative citation to proceed | with *their* publication process, in order to meet their own deadlines. And do you really believe that some other SDO wants to proceed with their own activities, only to be told a few weeks later that the RFC has been wathdrawn after a successful appeal?Don't you expect that they're really after some kind of stability?If they really need the actual RFC, don't you think that is because they want the stability that gives - and in that case, shouldn't we be making sure that RFC publication actualy means what it has meant in the past - and not be just a temporary parking place until an appeal (rarely, for sure, but possible) causes it to be removed? For general citations, just having the data is enough. Don't you ever cite papers (your own, or others) that you know are to be published in some journal or proceedings, before he actual paper copy arrives on your desk? | 2. It triggers action by product developers and writers of RFPs, | especially those not actively involved in the IETF. Same as above. If you're issuing an RFP, wouldn't you look a bit silly if you demanded conformance to an RFC that didn't actually exist at the time the responses were due? | The RFC Editor hates to reveal RFC numbers until publication is | a certainty. Yes, Joel Halpern, in a private message, also pointed that out - I wasn't as clear as I should have been. What I meant (should have said) was that at some point in the RFC process (now, past, and no necessary reason to change this in the future - though it could be done) the RFC number is allocated. That's certainly before AUTH48, as when the authors get their copy to review, the RFC number is there. There's no reason any of that should change, or be delayed - the RFC number will still be available as soon as the RFC Editor is ready to make it available, and if that gets closer and closer to the IESG's approval action, that's just fine. There is a variable length delay (and potential termination) of the publication process now, between number allocation and actual publication - the only question is whether it makes sense for there to be some minimum delay to make sure that appeals are no longer possible. If the RFC Editor really wants to hold the number secret until the actual publication is certain, then that means altering current practice, as it is certainly possible for an RFC to be withdrawn during AUTH48. What's more, even ignoring that, if publication is made as soon as possible, the effect would be that occasionally (infrequently for sure) an RFC will get published, only to be removed later after an appeal- and I'd think that's something the RFC Editor would like even less than the occasional this RFC was never published gap in the numbering scheme, because of an allocation that ended up unused. kre ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Should the RFC Editor publish an RFC in less than 2 months?
Comment: For some implementors only peripherally involved with IETF standards and process but looking at the new RFCs as news on standards it is well a difference whether its an RFC at the time they look or not. They just wouldn't know about an informal status as being approved to be released shortly. However, I want to say that I find it excellent that the RFC Editors did make their job so good that we actually have the chance to have this problem discussion. Maybe a quite pragmatic approach: Yes, RFC Editor should hold back until end of formal period for appeals, but how about just shortening that period to about 45 days instead of 60? Tobias -Original Message- From: Harald Tveit Alvestrand [mailto:[EMAIL PROTECTED] Sent: Monday, December 03, 2007 7:41 PM To: Tom.Petch; Lixia Zhang Cc: ietf@ietf.org Subject: Re: Should the RFC Editor publish an RFC in less than 2 months? --On 3. desember 2007 10:09 +0100 Tom.Petch [EMAIL PROTECTED] wrote: At the same time, I see the benefits of having the RFC now rather than in February as minimal; early adopters adopt early and are proud to announce in their marketing material that their product conforms to I-D draft-ietf-wg-enhanced-protocol. The date of the arrival of an RFC is irelevant to them. The people who actually care about whether something is an I-D or an RFC are the people who write specifications (other bodies' standards, RFPs, government mandates wherever they need a stable identifier). For the implementors, an I-D + the fact of approval is sufficient. For those who write other documents, it's not - they need the RFC number. Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
Tobias Gondrom wrote: They just wouldn't know about an informal status as being approved to be released shortly. That's a feature, approved isn't necessarily related to be released shortly, it can take years (or forever) to resolve all normative references to not yet approved I-Ds. how about just shortening that period to about 45 days instead of 60? That's what John proposed (well, he said 42 days), but it would be a huge effort to change the rules only for this minimal effect. Doing it together with something that's worthwhile like Brian's deconstruction of RFC 2026 could make sense. Frank ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
Date:Sun, 2 Dec 2007 17:34:14 -0800 From:Hallam-Baker, Phillip [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] | Only issue I would raise here is don't expire the ID if this situation | arises... That did not really need to be said - once submitted for IESG action, I-Ds go into a limbo state where they hand around until something happens, either the IESG rejects them, or the RFC is published, during that interval (however long it is, and it has been many years in a few extreme cases) the I-D simply remains available for reference. That, and that the RFC editor allocates the RFC number as one if its first actions after receiving approval to publish (I believe) has led me to read this entire discussion with something bordering on incredulity. Everyone (almost everyone) seems to be assuming that getting the RFC published as quickly as possible is the aim. Why? What does actual appearance of the file in the directories really change? Sure, it makes access a little easier, but that's it (and I guess that now, we could have a temporary placeholder installed, a file called rfc.2b or something, containing the URL of the I-D that will become the RFC when the editing process is finished - I personally doubt it is necessary, but it could be done). Certainly having the RFC editor reduce the publication delays is a laudable goal, if it RFCs are getting published at a rate slower than the IETF is producing them (over a lengthy period), then we'd have a problem - but if the RFC editor can publish faster than the IETF can produce, then the editor simply has to stall - whether that occurs at the point where everything that has been produced by the IETF is published, or when nothing produced by the IETF is greater than 2 months old really makes no difference at all. Where we want to avoid delays is in everything that happens before the RFC is approved for publication - once that happens its text is (minor editing aside) known, its citation is known, everything that matters is known, and how long the final step takes isn't that important. | Don't publish the rfc before the appeals counter expires, there lies all | sorts of bad stuff and confusion. I agree. Certainly if there is an appeal then until the appeal is resolved, or it is ascertained that the result of the appeal won't affect what is published (the fact, or the content) then publication needs to be stalled. Waiting the prescribed period for appeals (however long that is, which is a different discussion entirely) before publication doesn't hurt anything, and avoids all kinds of changes being needed to how the RFC archives are maintained. What's more, doing this requires no changes to anything at all - we just ask the RFC editor not to get too efficient - to use common sense and not publish anything within the appeals window (however long that is updated as it changes) and everything will be happy. What's more, given that essentially no RFCs have ever been (before now) ready to publish that quick anyway, this isn't going to seem any different to what we have had (ever since appeals have existed anyway) - everything will just continue as it always has, and would have, without complaint, had this issue not been raised. kre ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
Hallam-Baker, Phillip [EMAIL PROTECTED] wrote: Only issue I would raise here is don't expire the ID if this situation arises... If there is an IESG action and an ID folk can read that is going to work for most people. Don't publish the rfc before the appeals counter expires, there lies all sorts of bad stuff and confusion. +1 Greetings, Norbert. -- Norbert Bollow [EMAIL PROTECTED] http://Norbert.ch President of the Swiss Internet User Group SIUGhttp://SIUG.ch Working on establishing a non-corrupt and truly /open/ international standards organization http://OpenISO.org ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
- Original Message - From: Lixia Zhang [EMAIL PROTECTED] To: Frank Ellermann [EMAIL PROTECTED] Cc: ietf@ietf.org Sent: Sunday, December 02, 2007 8:12 PM Subject: Re: Should the RFC Editor publish an RFC in less than 2 months? snip I'm late getting into this discussion, but also have the advantages of seeing arguments on all side at once :-) it seems to me that the final decision on this issue would be a tradeoff in a multi-dimension space: - how much gain vendors/users may get from publishing an RFC at time=T vs at (T + 2 months) in particular if the publication is tagged with some provisional clause. - how strong is the desire of wanting the published RFCs to be stable (i.e. minimizing the chances of reclassification, with an understanding that we cannot completely eliminate the chance) - As pointed out above, what may be the legal complication, if there is any, in handling appeals against a published RFC, and remedy the situation when an appeal succeeds. I too first thought that the process ought to be optimized for the majority cases. I now realized that the optimization should be based on the weighted percentages: (% of no-appeal cases) X (gains from publishing 2-month earlier) versus (% of appeal cases) X (chance of an appeal succeeded) X (cost from any potential legal complications and remedy) The remedy here may also include the cost to those people who acted on a published RFC in its first 2 months. I agree completely. When I am involved in risk analysis, the really nasty cases are 'probability low, impact high' - will the first nuclear bomb set off a chain reaction which destroys the world? unlikely but somewhat devastating if so. I see the withdrawal of approval by the IESG as risk analysis; whether it happens 10% or 0.1% of the time, whether it happens on account of an appeal or because of some other reason is immaterial if the potential adverse impact is high enough. At the same time, I see the benefits of having the RFC now rather than in February as minimal; early adopters adopt early and are proud to announce in their marketing material that their product conforms to I-D draft-ietf-wg-enhanced-protocol. The date of the arrival of an RFC is irelevant to them. The I-Ds that concern me most are those that may have had little exposure, for which that lack of exposure means that potentially show-stopping issues have yet to emerge. So one compromise would be to allow quicker publication of those I-Ds that have had wide exposure, that have been discussed on an IETF mailing list, so that at IETF Last Call it is feasible to look at the mailing list archive to see what has arison, but keep the 60 day delay for individual submissions, or for I-Ds that do not get an IETF Last Call. Tom Petch so the question to me is really: can we quantify the values of those weight factors? (as an academic I dont have a lot clue here) ps No, in my experience of risk analysis - each participant uses their gut feeling and the chair declares rough consensus. Lixia ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
On Dec 2, 2007 4:55 PM, Frank Ellermann [EMAIL PROTECTED] wrote: Lixia Zhang wrote: The remedy here may also include the cost to those people who acted on a published RFC in its first 2 months. Yes, or months earlier, for the case I have in mind more than two years, millions of users, and a bunch of implementations. Most happily ignoring the eventual opt-out remedy, I guess. Conversely, why not allow a Draft to be published as an RFC in that six-week period if there are no arguments or appeals, whereas an appeal could potentially (a) restart the six-week clock, or (b) extend the period from 42 to the full sixty days? Though again, it would be changing the rule for less than a 50% gain in minimum time to publication. I just thought I'd toss the idea out there. -- Daniel P. Brown [office] (570-) 587-7080 Ext. 272 [mobile] (570-) 766-8107 If at first you don't succeed, stick to what you know best so that you can make enough money to pay someone else to do it for you. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
On 2007-12-03 22:49, Robert Elz wrote: ... Everyone (almost everyone) seems to be assuming that getting the RFC published as quickly as possible is the aim. Why? What does actual appearance of the file in the directories really change? It's the instant of formal publication, and that changes at least two things: 1. It allows other SDOs that require a normative citation to proceed with *their* publication process, in order to meet their own deadlines. This has been a much more frequent situation than appeals in recent years (with ITU-T and 3GPP being the SDOs mainly concerned, iirc). 2. It triggers action by product developers and writers of RFPs, especially those not actively involved in the IETF. The RFC name is powerful enough that there really is an impact - people *do* wait until the RFC comes out, or hear about things for the first time then. Sure, it makes access a little easier, but that's it (and I guess that now, we could have a temporary placeholder installed, a file called rfc.2b or something, containing the URL of the I-D that will become the RFC when the editing process is finished - I personally doubt it is necessary, but it could be done). The RFC Editor hates to reveal RFC numbers until publication is a certainty. There is an unofficial list of approved but not published drafts, however, at http://rtg.ietf.org:8080/Test/parking (assuming it still works - I'm off line and can't check). Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
--On 3. desember 2007 10:09 +0100 Tom.Petch [EMAIL PROTECTED] wrote: At the same time, I see the benefits of having the RFC now rather than in February as minimal; early adopters adopt early and are proud to announce in their marketing material that their product conforms to I-D draft-ietf-wg-enhanced-protocol. The date of the arrival of an RFC is irelevant to them. The people who actually care about whether something is an I-D or an RFC are the people who write specifications (other bodies' standards, RFPs, government mandates wherever they need a stable identifier). For the implementors, an I-D + the fact of approval is sufficient. For those who write other documents, it's not - they need the RFC number. Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
Harald sed: For the implementors, an I-D + the fact of approval is sufficient. For those who write other documents, it's not - they need the RFC number. including the folk in other SDOs that want to point to IETF documents Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
--On 1. desember 2007 22:15 -0800 Bob Hinden [EMAIL PROTECTED] wrote: Before we head further down this track, do we have any data as to how big a problem we are thinking of fixing? Since the IETF has been producing RFCs, how many have been appealed in the 2 months after IESG approval? I would like to see the actual numbers. Does this happen 10%, 1%, .1%, .01%, .001%, etc. of the time? If we assume the list on http://www.ietf.org/IESG/Appeals.html is complete, there has been 22 appeals to the IESG since November 2002. From visual inspection of the list, I think at least half are unrelated to document publication (PR-actions, mailing list suspensions, WG closings). I don't know how many of the rest would have stop this document as part of their proposed remedies, but to be conservative, let's assume 10 (it's almost certainly less, but that will save me having to read all these appeal texts to figure them out). In November 2002, RFC 3323 was published; we're now at RFC 5092 - more than 1700 RFCs later. Based on the past record, we're talking about something that happens 0.58% of the time, or less. Of course, predicting the future from the past is iffy; there have been 10 appeals in 2006 and only one (not document related) in 2007, so it varies. Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
--On Sunday, 02 December, 2007 14:56 +0100 Harald Tveit Alvestrand [EMAIL PROTECTED] wrote: Based on the past record, we're talking about something that happens 0.58% of the time, or less. Of course, predicting the future from the past is iffy; there have been 10 appeals in 2006 and only one (not document related) in 2007, so it varies. But, at least for me, trying to make very specific rules for something that occurs less than 5 or 10% of the time and, even then, involves case by case idiosyncrasies, is just a bad idea. And, if you are seeing circa 6 tenths of a percent, I believe that the order of magnitude difference between that and my quite subjective criterion is more than enough to account for variability. If nothing else, if we have that little percentage experience, there is little with which to evaluate the effect of any possible rules. Of course, YMMD and, in particular, you might consider this potential problem to be important enough to have other criteria. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
John C Klensin wrote: Of course, YMMD and, in particular, you might consider this potential problem to be important enough to have other criteria. The enhanced NOOP discussion on the SMTP list just reminded me that we're talking about protecting IANA, RFC editor, and Trust from legal enforcement. Frank ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
Harald, Based on the past record, we're talking about something that happens 0.58% of the time, or less. Of course, predicting the future from the past is iffy; there have been 10 appeals in 2006 and only one (not document related) in 2007, so it varies. Thanks for looking at the data. It seems to me that we shouldn't be delaying all new RFCs for a problem that only occurs .58% of the time. Bob ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
On Dec 2, 2007, at 9:49 AM, Frank Ellermann wrote: John C Klensin wrote: Of course, YMMD and, in particular, you might consider this potential problem to be important enough to have other criteria. The enhanced NOOP discussion on the SMTP list just reminded me that we're talking about protecting IANA, RFC editor, and Trust from legal enforcement. Frank I'm late getting into this discussion, but also have the advantages of seeing arguments on all side at once :-) it seems to me that the final decision on this issue would be a tradeoff in a multi-dimension space: - how much gain vendors/users may get from publishing an RFC at time=T vs at (T + 2 months) in particular if the publication is tagged with some provisional clause. - how strong is the desire of wanting the published RFCs to be stable (i.e. minimizing the chances of reclassification, with an understanding that we cannot completely eliminate the chance) - As pointed out above, what may be the legal complication, if there is any, in handling appeals against a published RFC, and remedy the situation when an appeal succeeds. I too first thought that the process ought to be optimized for the majority cases. I now realized that the optimization should be based on the weighted percentages: (% of no-appeal cases) X (gains from publishing 2-month earlier) versus (% of appeal cases) X (chance of an appeal succeeded) X (cost from any potential legal complications and remedy) The remedy here may also include the cost to those people who acted on a published RFC in its first 2 months. so the question to me is really: can we quantify the values of those weight factors? (as an academic I dont have a lot clue here) Lixia ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
Lixia Zhang wrote: - how much gain vendors/users may get from publishing an RFC at time=T vs at (T + 2 months) For T = (timestamp of approval) the publication will be at time (T + x), and (T + x) (T + 2 months) is by definition irrelevant. With John's proposal six weeks it could be minimally faster, but as he and others said, it makes no sense to change the rules for a gain of about three weeks. Implementors are not forced to wait for the RFC number, they can start whenever they feel like it. Harald's approximation of 0.6% was already very pessimistic, e.g. he didn't aggregate the numerous I really don't like RFC 4646 appeals, and more important, he didn't count successful appeals affecting early implementors in some way. The remedy here may also include the cost to those people who acted on a published RFC in its first 2 months. Yes, or months earlier, for the case I have in mind more than two years, millions of users, and a bunch of implementations. Most happily ignoring the eventual opt-out remedy, I guess. so the question to me is really: can we quantify the values of those weight factors? The damage can be significant (e.g. commercial implementation ending up in /dev/null), harmless (e.g. if mail vanishes in a black hole created by RFC y), or disastrous (same scenario with an important mail). Frank ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
Sorry for the complete change in subject, but I think it's important to avoid confusion here: On 1 dec 2007, at 12:22, Frank Ellermann wrote: Disclaimer, I like Excel on boxes where it's available, it's a nice product. But it's not nice enough to say that 1900-02-29 was day 60 in year 0, if that's what the 6000 ooXML pages say (I only looked at some nits in the BSI Wiki, I never read any page of the huge draft). What are you trying to say here? There never was a februari 29 in 1900 so giving that non-existant day a number would be problematic. From your statement, I assume there is a standard that does this, but I'm not sure which one and why. Could you enlighten us? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
Iljitsch van Beijnum wrote: Could you enlighten us? Really, no :-) You could check what's really going on, grab a copy of ECMA 376 and tell us what it says. Maybe try your luck at http://www.noooxml.org/1900. With Redmond it's as with spammers, the one thing that's worse than spammers are the anti-spammers. Frank ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
Only issue I would raise here is don't expire the ID if this situation arises... If there is an IESG action and an ID folk can read that is going to work for most people. Don't publish the rfc before the appeals counter expires, there lies all sorts of bad stuff and confusion. Sent from my GoodLink Wireless Handheld (www.good.com) -Original Message- From: Russ Housley [mailto:[EMAIL PROTECTED] Sent: Saturday, December 01, 2007 05:58 PM Pacific Standard Time To: Alexey Melnikov; ietf@ietf.org Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject:Re: Should the RFC Editor publish an RFC in less than 2 months? Alexey: The latter. If the Auth48 completes before the 60 day appeal timer has expired, then the RFC Editor will hold off on publication until the 60 days have gone by. Russ P.S. A document that I wrote was the first document to get snagged in this situation. I guess it is only fair It got published yesterday. At 06:54 PM 12/1/2007, Alexey Melnikov wrote: Russ, IETF Chair wrote: While we figure out what policy we want, I have asked the RFC Editor to not publish any IESG approved documents until their appeal timer has expired. I also challenged the RFC Editor to move things along so fast that this matters. I suspect they can. Which means that the whole IETF community needs to help the leadership figure out the appropriate policy before the rapid processing of Internet-Draft documents into RFCs becomes the norm. I would like to ask a clarifying question: does this mean that RFC editors are not going to start editing the document until after 2 months since approval of a document, or does it mean that RFC editors start editing right away, can issue AUTH48 request, but will delay publication until after 2 months? I think the latter is better, because (a) appeals are not that frequent and (b) AUTH48 usually takes way longer than 2 days ;-). Regards, Alexey P.S. I apologize in advance for asking the question before reading the whole thread. Maybe it was already asked. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
Tom Petch wrote: a 60 day hold seems rather a good idea. Indeed, unless somebody transforms John's proposal 6 weeks in an ION and/or 2026 update, or whatever red tape cutting this needs. If appeals are drafted by a kind of community this needs time (e.g. to figure out who read the relevant procdoc RFCs... ;-) Frank ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
--On Saturday, 01 December, 2007 13:59 +0100 Frank Ellermann [EMAIL PROTECTED] wrote: Tom Petch wrote: a 60 day hold seems rather a good idea. Indeed, unless somebody transforms John's proposal 6 weeks in an ION and/or 2026 update, or whatever red tape cutting this needs. If appeals are drafted by a kind of community this needs time (e.g. to figure out who read the relevant procdoc RFCs... ;-) Frank, while figuring out what we are doing and documenting it would certainly be a good idea, my suggestion was carefully written to be feasible without any action as formal as opening 2026. The IESG clearly has the authority today (if only because the RFC Editor believes that they do) to ask for a publication hold. All it would take to implement that part of my suggestion would be an announcement that, while the appeal window remains at two months, any appeals that intend to ask for a publication hold must be announced in some substantive way within some much shorter time. Whether or not publication delays are then granted might, as I suggested, depend on joint IESG/IAB decisions about the level of possible damage and merit of the appeal. But, as many others have pointed out, the cases are few in which significant damage would be done by publishing and then changing status and/or posting a follow-up. I'd even suggest that a document that was significant enough to achieve IETF consensus as measured by the IESG --even if that measurement is overturned on appeal-- is a document that would normally deserve publication as a path not traveled independent or individual submission. That view argues that, in the rare cases in which a publication delay might be justified, someone who thinks one is needed should ask (presumably by posting a notice of intent to appeal with that request and justification) really quickly, before the RFC Editor can review, publish, and post _however_ short that time is. I'd then expect the IESG to ask that publication be suspended until they and the IAB can sort out whether a delay while the appeal is filed and sorted out is appropriate. But, again, while an ION to record whatever the plan is would be appropriate, I don't think we would be doing ourselves a favor by turning this into a big deal with a lot of formal procedures and cutoffs. As I think more about it, harm is more likely to be caused by IANA registrations specified in a document as requiring IETF or IESG approval and then needing to undo such registrations after an appeal than by publication of the document itself. As far as I know, we have never insisted on a two month hold for such registrations: we just assume that we can deprecate them if we have to. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
From: John C Klensin [EMAIL PROTECTED] --On Saturday, 01 December, 2007 13:59 +0100 Frank Ellermann [EMAIL PROTECTED] wrote: Tom Petch wrote: a 60 day hold seems rather a good idea. Indeed, unless somebody transforms John's proposal 6 weeks in an ION and/or 2026 update, or whatever red tape cutting this needs. If appeals are drafted by a kind of community this needs time (e.g. to figure out who read the relevant procdoc RFCs... ;-) Frank, while figuring out what we are doing and documenting it would certainly be a good idea, my suggestion was carefully written to be feasible without any action as formal as opening 2026. The metapoint that John may have assumed (because I know he knows it, because he's pointed this out to me many times) is that every time we stick very specific stuff in process BCPs, we regret it. I had the privilege of working on a minor process revision to RFC 3777 (NomCom process) earlier this year, and that was a dream, because all the dates were deadline-driven - we wanted to START earlier, and there was very little stopping us from STARTING earlier. When we get very specific, we find ourselves publishing what we really meant was BCPs that fix previous BCPs, with nice long publication delays while we either run under broken rules or ignore them and hope no one appeals. And THAT is why John is right about not opening 2026, which is actually a codename for reopening every process discussion we've had since 2027 was published. Someday we might open 2026, but it shouldn't be for this reason. Thanks, Spencer ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
Brian E Carpenter skrev: On 2007-12-01 00:45, Harald Alvestrand wrote: Tom.Petch wrote: I recall a recent occasion when the IESG withdrew its approval, for draft-housley-tls-authz-extns a document that both before and after its approval generated a lot of heat, within and without a WG. Presumably the expedited process would, or at least could, have seen that published as an RFC. With that example in mind, a 60 day hold seems rather a good idea. In that case, it went into the RFC Editor queue on June 30,, 2006, and was yanked from the queue on February 26, 2007 - 8 months later. According to the third last call announcement: On June 27, 2006, the IESG approved Transport Layer Security (TLS) Authorization Extensions, (draft-housley-tls-authz-extns) as a proposed standard. On November 29, 2006, Redphone Security (with whom Mark Brown, a co-author of the draft is affiliated) filed IETF IPR disclosure 767. it was five months between approval and the IPR disclosure. A two-month hold wouldn't have caught it. (No idea why it was still hanging there long enough for the IPR disclosure to catch up with it...) In any case, I would much rather have seen that published and later declared Historic than hold up all other RFCs. It isn't as if the IETF can control what actually gets implemented and deployed in any case - so why on earth does it *matter*? Whereas getting the vast majority of RFCs published promptly *does* matter. I am actually worried with the inter SDO implications of blocking publication for 2 months. Unless we actually always block publication for 2 month for approval this doesn't help. So what are we going to say to other SDO and they ask, can you do your best to get this document published. And then we have to say, well the document can be made ready but we can't for formal reasons provide it until 2 months have past. I think this would be going in the wrong direction on use cooperating with other SDOs. However, it clearly solves the issue with appeals and if it is IESG or IAB discretion whether the document is blocked or not. I actually are worried that people may use a appeals always block publication as way of forcing removal of ietf protocols from other SDOs specifications. The reality is that neither IESG or IAB can process appeals extremely quickly. Unless they are obvious bogus. Cheers Magnus Westerlund IETF Transport Area Director TSVWG Chair -- Multimedia Technologies, Ericsson Research EAB/TVM -- Ericsson AB| Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: [EMAIL PROTECTED] -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
John C Klensin wrote: figuring out what we are doing and documenting it would certainly be a good idea, my suggestion was carefully written to be feasible without any action as formal as opening 2026. Yes, and you also said that you're not going to do it. If Brian wants to tackle it he'd likely integrate your idea in his appeal I-D, Harald might prefer an ION to have it on public record, IMO there are various ways to implement your proposal. All it would take to implement that part of my suggestion would be an announcement that, while the appeal window remains at two months, any appeals that intend to ask for a publication hold must be announced in some substantive way within some much shorter time. Okay, but it's not a clean hack. In both cases where I felt a sudden urge to appeal (sitefinder-verisign and termination of MARID) I ended up with speed reading RFCs based on grep and Google searches, I'd certainly have missed anything more subtle, e.g. an ION or old IESG announcement buried in a list archive. I needed three months to find 3710 to historic as a potential remedy, it wasn't on my CD ROM with RFCs, and of course three months was anyway far too late. BTW, that's a flaw in Brian's proposal to deprecate the STD 1 rule, not everybody reads the RFCs online with access on a list of current STDs (etc.) published as rfc-editor.org page. Whether or not publication delays are then granted might, as I suggested, depend on joint IESG/IAB decisions about the level of possible damage and merit of the appeal. Yes, a cleaner (and faster) procedure would be to start the appeal chain *above* the level of the appealed decision, in the case of an RFC approved by the IESG go directly to the IAB (and maybe vice versa for the rare IAB RFCs). the cases are few in which significant damage would be done by publishing and then changing status and/or posting a follow-up. Let's face it, most folks out there don't get the fine print of not every RFC is a standard. Publishing garbage as RFC is the worst possible outcome, and no status changes, errata, updates, or other options can really fix it. Whatever is in say 2821bis will be holy scripture for decades (skipping the many years where folks will still try to cite 2821), any minor issue in it could cost billions later. Just an example - I don't think that your avoid WGs to get rid of the trolls approach posted elsewhere is a good idea: WGs have real Chairs forced to post real (hat on) decisons, offering an opportunity for real appeals below the IAB level. The design team approach is risky, maybe you win two years, but you could also lose five years. For important RFCs like SMTP or IDNA five years could be too long. I saw no trolls on the httpbis list so far (not counting me, YMMV), it's a very business oriented WG with a reasonable timetable (October 2008). I'd even suggest that a document that was significant enough to achieve IETF consensus as measured by the IESG --even if that measurement is overturned on appeal-- is a document that would normally deserve publication as a path not traveled independent or individual submission. AFAIK it's not possible to add IESG notes (or anything at all) to a published RFC. Maybe it would be a good idea to publish such decisions when they come after the fact also as erratum, folks reading RFCs on the IETF tools server have then a chance to find it. That view argues that, in the rare cases in which a publication delay might be justified, someone who thinks one is needed should ask (presumably by posting a notice of intent to appeal with that request and justification) really quickly, before the RFC Editor can review, publish, and post _however_ short that time is. I'd then expect the IESG to ask that publication be suspended until they and the IAB can sort out whether a delay while the appeal is filed and sorted out is appropriate. Yes, that's what you did back in summer 2005. For Sender ID it wasn't necessary because it anyway had a normative reference to SPF, and one co-author supported the appeal (and could in theory block the whole set). For the real appeal (not the 1st IESG reviewing its own decision round) it was different, we risked that the RFC-editor might be faster than the IAB. But he wasn't at this time, and besides the IAB rejected the Sender ID appeal, because experiments are experiments, and free to cause havoc as they see fit... :-( while an ION to record whatever the plan is would be appropriate, I don't think we would be doing ourselves a favor by turning this into a big deal with a lot of formal procedures and cutoffs. Well, it's highly disruptive if Redmond decides to embrace, extend, and extinguish an idea, and it's not better if they decide to use the democratic framework of another SDO to get a standard for their Office product. Disclaimer, I like Excel on boxes where it's available, it's a nice product. But it's not nice enough to say that
Re: Should the RFC Editor publish an RFC in less than 2 months?
--On Saturday, 01 December, 2007 21:22 +0100 Frank Ellermann [EMAIL PROTECTED] wrote: John C Klensin wrote: figuring out what we are doing and documenting it would certainly be a good idea, my suggestion was carefully written to be feasible without any action as formal as opening 2026. Yes, and you also said that you're not going to do it. Yes. I have made a personal decision that spending my time on Internet technology and protocols is better for the Internet and better for my mental and physical health than making further investments in IETF procedures. That decision has been reinforced by an assortment of actions in the past, including IAB, IESG, and Nomcom actions. I will probably continue to track issues like this, and IPR ones, etc. I may even express opinions about what might be placed in an I-D. But, if process I-Ds need to be written, someone else will need to write them, at least unless someone starts paying me a salary to do so. If Brian wants to tackle it he'd likely integrate your idea in his appeal I-D, Harald might prefer an ION to have it on public record, IMO there are various ways to implement your proposal. Of course, although I am in strong agreement with Spencer's comments that making rigid, BCP-level, procedures for unusual cases has almost never served us well. I more or less said that, but Spencer's note is much more clear and explicit. All it would take to implement that part of my suggestion would be an announcement that, while the appeal window remains at two months, any appeals that intend to ask for a publication hold must be announced in some substantive way within some much shorter time. Okay, but it's not a clean hack. In both cases where I felt a sudden urge to appeal (sitefinder-verisign and termination of MARID) I ended up with speed reading RFCs based on grep and Google searches, I'd certainly have missed anything more subtle, e.g. an ION or old IESG announcement buried in a list archive. I needed three months to find 3710 to historic as a potential remedy, it wasn't on my CD ROM with RFCs, and of course three months was anyway far too late. BTW, that's a flaw in Brian's proposal to deprecate the STD 1 rule, not everybody reads the RFCs online with access on a list of current STDs (etc.) published as rfc-editor.org page. I think you are conflating two issues. The first is that what I suggested is not, IMO, a hack. It is taking advantage of flexibility and options for applying discretion that are built into the system (mostly not by accident). YMMD, of course. The second is about whether the IETF processes are straightforward and well-documented enough that someone who is not already very familiar with them can efficiently navigate the process.We are probably in agreement about that state of affairs. I would favor fixing it but, based on painful experience, I would recommend that anyone who wants to try get IESG signup first and that they not get the effort entangled with working on the answer to any short-term or isolated question (of which publication delay issues are certainly an example). Your other comments are much more general. Whether I agree or disagree, I don't have time to respond adequately this weekend. I would, however, note that several of the issues you identify would have been resolved by proposals that were made a few years ago. The IESG decided those changes were either unnecessary, undesirable, or not worth the trouble and the community accepted those decisions (even if the only concrete way to measure accepted is that no one got recalled and the IESG did not get fired in toto).For better or worse, that suggests that the people who care about these things are a minority and that they have not been successful in convincing the majority that the topics are worth significant consideration.I think those of us who make up that minority need to accept that face... and I have. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
Russ, IETF Chair wrote: While we figure out what policy we want, I have asked the RFC Editor to not publish any IESG approved documents until their appeal timer has expired. I also challenged the RFC Editor to move things along so fast that this matters. I suspect they can. Which means that the whole IETF community needs to help the leadership figure out the appropriate policy before the rapid processing of Internet-Draft documents into RFCs becomes the norm. I would like to ask a clarifying question: does this mean that RFC editors are not going to start editing the document until after 2 months since approval of a document, or does it mean that RFC editors start editing right away, can issue AUTH48 request, but will delay publication until after 2 months? I think the latter is better, because (a) appeals are not that frequent and (b) AUTH48 usually takes way longer than 2 days ;-). Regards, Alexey P.S. I apologize in advance for asking the question before reading the whole thread. Maybe it was already asked. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
I would like to ask a clarifying question: does this mean that RFC editors are not going to start editing the document until after 2 months since approval of a document, or does it mean that RFC editors start editing right away, can issue AUTH48 request, but will delay publication until after 2 months? I think the latter is better, because (a) appeals are not that frequent and (b) AUTH48 usually takes way longer than 2 days ;-). The latter. There is a handful documents in the wait state. Jari ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
Alexey: The latter. If the Auth48 completes before the 60 day appeal timer has expired, then the RFC Editor will hold off on publication until the 60 days have gone by. Russ P.S. A document that I wrote was the first document to get snagged in this situation. I guess it is only fair It got published yesterday. At 06:54 PM 12/1/2007, Alexey Melnikov wrote: Russ, IETF Chair wrote: While we figure out what policy we want, I have asked the RFC Editor to not publish any IESG approved documents until their appeal timer has expired. I also challenged the RFC Editor to move things along so fast that this matters. I suspect they can. Which means that the whole IETF community needs to help the leadership figure out the appropriate policy before the rapid processing of Internet-Draft documents into RFCs becomes the norm. I would like to ask a clarifying question: does this mean that RFC editors are not going to start editing the document until after 2 months since approval of a document, or does it mean that RFC editors start editing right away, can issue AUTH48 request, but will delay publication until after 2 months? I think the latter is better, because (a) appeals are not that frequent and (b) AUTH48 usually takes way longer than 2 days ;-). Regards, Alexey P.S. I apologize in advance for asking the question before reading the whole thread. Maybe it was already asked. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
Before we head further down this track, do we have any data as to how big a problem we are thinking of fixing? Since the IETF has been producing RFCs, how many have been appealed in the 2 months after IESG approval? I would like to see the actual numbers. Does this happen 10%, 1%, .1%, .01%, .001%, etc. of the time? Bob ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
In any case, I would much rather have seen that published and later declared Historic than hold up all other RFCs. It isn't as if the IETF can control what actually gets implemented and deployed in any case - so why on earth does it *matter*? Whereas getting the vast majority of RFCs published promptly *does* matter. I agree. I don't think there should be any additional delay in RFC publication. It takes long enough as is. Unless we hold them up till any possible patent expires (e.g., 17+ years). Bob ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
On 2007-12-01 00:45, Harald Alvestrand wrote: Tom.Petch wrote: I recall a recent occasion when the IESG withdrew its approval, for draft-housley-tls-authz-extns a document that both before and after its approval generated a lot of heat, within and without a WG. Presumably the expedited process would, or at least could, have seen that published as an RFC. With that example in mind, a 60 day hold seems rather a good idea. In that case, it went into the RFC Editor queue on June 30,, 2006, and was yanked from the queue on February 26, 2007 - 8 months later. According to the third last call announcement: On June 27, 2006, the IESG approved Transport Layer Security (TLS) Authorization Extensions, (draft-housley-tls-authz-extns) as a proposed standard. On November 29, 2006, Redphone Security (with whom Mark Brown, a co-author of the draft is affiliated) filed IETF IPR disclosure 767. it was five months between approval and the IPR disclosure. A two-month hold wouldn't have caught it. (No idea why it was still hanging there long enough for the IPR disclosure to catch up with it...) In any case, I would much rather have seen that published and later declared Historic than hold up all other RFCs. It isn't as if the IETF can control what actually gets implemented and deployed in any case - so why on earth does it *matter*? Whereas getting the vast majority of RFCs published promptly *does* matter. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
Tom.Petch wrote: I recall a recent occasion when the IESG withdrew its approval, for draft-housley-tls-authz-extns a document that both before and after its approval generated a lot of heat, within and without a WG. Presumably the expedited process would, or at least could, have seen that published as an RFC. With that example in mind, a 60 day hold seems rather a good idea. In that case, it went into the RFC Editor queue on June 30,, 2006, and was yanked from the queue on February 26, 2007 - 8 months later. According to the third last call announcement: On June 27, 2006, the IESG approved Transport Layer Security (TLS) Authorization Extensions, (draft-housley-tls-authz-extns) as a proposed standard. On November 29, 2006, Redphone Security (with whom Mark Brown, a co-author of the draft is affiliated) filed IETF IPR disclosure 767. it was five months between approval and the IPR disclosure. A two-month hold wouldn't have caught it. (No idea why it was still hanging there long enough for the IPR disclosure to catch up with it...) Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
Original Message - From: Harald Alvestrand [EMAIL PROTECTED] To: ietf@ietf.org Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, November 29, 2007 7:52 AM Subject: Re: Should the RFC Editor publish an RFC in less than 2 months? IETF Chair skrev: Dear IETF Community: Due to a lot of hard work, the RFC Editor is publishing approved Internet-Drafts more quickly. Overall this is just what we want to happen. However, I am concerned that the RFC Editor is might be getting too quick. Anyone can appeal the approval of a document in the two months following the approval. In the past, there was not any danger of the RFC Editor publishing a document before this timer expired, and the only documents that became RFCs in less than 60 days were the ones where the IESG explicitly asked for expedited processing. The recent improvements by the RFC Editor make it likely that all documents will be moving through the publication process in less than two months. My short reply: Bad idea. In my opinion, placing such a hold on documents is a triumph of process over sanity. snip Such a hold is a dumb idea, and we shouldn't do it. Just publish, and if we turn out to have made the wrong decision, make a public statement saying that; one form of public statement is leaving a hole in the RFC Index. I recall a recent occasion when the IESG withdrew its approval, for draft-housley-tls-authz-extns a document that both before and after its approval generated a lot of heat, within and without a WG. Presumably the expedited process would, or at least could, have seen that published as an RFC. With that example in mind, a 60 day hold seems rather a good idea. Tom Petch Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
John C Klensin [EMAIL PROTECTED] wrote: I don't see any possible reason why we need to give people two months to get an appeal filed: a month or, at most, six weeks ought to be more than sufficient. +1 Greetings, Norbert. -- Norbert Bollow [EMAIL PROTECTED] http://Norbert.ch President of the Swiss Internet User Group SIUGhttp://SIUG.ch ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
On 29 nov 2007, at 0:18, Paul Hoffman wrote: One easy solution to the problem is to not change anything in the current IETF or RFC rules. If an RFC has been published before the appeal is brought, and that appeal is ultimately successful, a new RFC is issued that obsoletes the old RFC. That new RFC can essentially be a NULL, although hopefully it would have an explanation why an empty RFC is obsoleting a non-empty one. That new RFC can also be partially populated; for example, if the resolution of the appeal is to pull a contentious section or appendix. Given the extreme rarity of the situation where an appeal leads to non-publication or changed publication, it seems wasteful to create new rules (and spend lots of time arguing about them) when no new rules are needed. ++ Especially since presumably, an appealer would be motivated to stop publication of the RFC and file an appeal without delay rather than after 59 days. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
John, I agree with just about everything you say here, except for this: At Thu, 29 Nov 2007 01:56:51 -0500, John C Klensin wrote: And, incidentally, I believe that discussions about inherent conflicts of interest in the current appeals process are irrelevant to this discussion, for two reasons. First, as others have repeatedly pointed out, our appeals mechanisms are an important tool for reaching and establishing consensus, not a judicial procedure. Yes, it's not a judicial procedure, but nevertheless, an appeal of an IESG action inherently involves the claim that the IESG has made a mistake, and the IESG is not exactly in a position to judge that neutrally. Yes, the IESG does sometimes reverse itself, but there have also been times where the IESG has denied an appeal, the appellant has appealled to the IAB, and the IAB has upheld it. Having been involved in such cases, I don't think I would characterize them as establishing consensus. And second, if there are conflicts of interest that we believe are unacceptable, and that belief is based on experience rather than theory or hypothetical situations, then we need to fix 2026 and the appeals process for reasons and in ways that have little to do with the publication delay question. I didn't say that there were COIs that were unacceptable. I said they needed to be mitigated by ensuring that the appellant had an opportunity to have a hearing before a neutral (or as neutral as possible) party. I think the current 2026 procedures more or less do that, but in this particular case there is a bug in the process. It's not one I'd ordinarily spend a lot of time agitating to fix, but since Russ raised the topic of delaying publication, it's worth getting this aspect of it straight. -Ekr ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
Tim Polk wrote: There is no way to ensure that documents aren't published until *all* the appeals timers expire. Given that, let's encourage the RFC Editor to publish when ready, and we can concentrate on establishing a process that works when the appeal concerns a published document. +1 RFCs are withdrawn for a variety of reasons, already. A successful appeal would be merely one more. While no, historic is not metemantically identical to nevering having been published, it is sufficient that it means not approved by the IETF. Approval-vs-nonApproval seems like the most pragmatic test of reversal. The IETF approval process already has significant points of review and control. While this final-stage appeal potential is real, it does not happen with any frequency and the dangerous community impact of publishing an RFC that quickly gets moved to historic are small, possibly nil. Hence, no new mechanisms are need, although I do think it was useful to raise the question for discussion in this thread. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
Dave Crocker wrote: Tim Polk wrote: There is no way to ensure that documents aren't published until *all* the appeals timers expire. Given that, let's encourage the RFC Editor to publish when ready, and we can concentrate on establishing a process that works when the appeal concerns a published document. +1 RFCs are withdrawn for a variety of reasons, already. A successful appeal would be merely one more. While no, historic is not metemantically identical to nevering having been published, it is sufficient that it means not approved by the IETF. Approval-vs-nonApproval seems like the most pragmatic test of reversal. The IETF approval process already has significant points of review and control. While this final-stage appeal potential is real, it does not happen with any frequency and the dangerous community impact of publishing an RFC that quickly gets moved to historic are small, possibly nil. Indeed, let's optimize for the common case. Hence, no new mechanisms are need, although I do think it was useful to raise the question for discussion in this thread. +1. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
I agree with what Dave, Tim, and Harald said. Besides, if we really wanted a delay, we should pay the RFC Editor less and ask them to provide slower service :-) But please keep this as a secret from the IAOC... I would also like to point out its not the bits that are dangerous in a mistakenly or inappropriately approved document. It is the status that the IETF gives to these bits that matter. E.g., Proposed Standard, product of such and such WG. The bits are already out there in many places; we cannot withdraw them. What we can control is the status that the IETF gives for those bits. The modern tools we have for viewing IETF documents can make it plainly obvious to people what the status of an RFC is. But I would also caution a little bit against thinking that the solutions are easy. I think we should have a short deadline for notifying intent to appeal. However, a 5 page document may still get through the RFC Editor in a surprisingly small amount of time. And we can move a document to historic, but what about the other documents that referred to it? We can delay only the documents that we know will be appealed, but this appears to have obvious DoS problems. Nevertheless, I think repairing damage if it occurs is probably the right answer. Possibly combined with a short intent-to-appeal period, so that we can try to do the right thing as soon as possible. Jari ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
--On Thursday, 29 November, 2007 01:18 -0800 Eric Rescorla [EMAIL PROTECTED] wrote: John, I agree with just about everything you say here, except for this: We may not even disagree completely about that. The key to my comment was irrelevant to _this_ discussion (emphasis added). More below. At Thu, 29 Nov 2007 01:56:51 -0500, John C Klensin wrote: And, incidentally, I believe that discussions about inherent conflicts of interest in the current appeals process are irrelevant to this discussion, for two reasons. First, as others have repeatedly pointed out, our appeals mechanisms are an important tool for reaching and establishing consensus, not a judicial procedure. Yes, it's not a judicial procedure, but nevertheless, an appeal of an IESG action inherently involves the claim that the IESG has made a mistake, and the IESG is not exactly in a position to judge that neutrally. Yes, the IESG does sometimes reverse itself, but there have also been times where the IESG has denied an appeal, the appellant has appealled to the IAB, and the IAB has upheld it. Having been involved in such cases, I don't think I would characterize them as establishing consensus. I agree. See below. And second, if there are conflicts of interest that we believe are unacceptable, and that belief is based on experience rather than theory or hypothetical situations, then we need to fix 2026 and the appeals process for reasons and in ways that have little to do with the publication delay question. I didn't say that there were COIs that were unacceptable. I said they needed to be mitigated by ensuring that the appellant had an opportunity to have a hearing before a neutral (or as neutral as possible) party. I think the current 2026 procedures more or less do that, but in this particular case there is a bug in the process. It's not one I'd ordinarily spend a lot of time agitating to fix, but since Russ raised the topic of delaying publication, it's worth getting this aspect of it straight. Well, the place where I think we disagree is _only_ about whether introducing the timing issue and the possible conditions for delaying publication changes anything. I'm not prepared to suggest a change to the procedures, in part because I'm not convinced it is a good idea and in part because I'm trying to go out of the business of suggesting new procedure models (partially for personal reasons and partially because I have come to believe that any significant change is impossible without first changing the approval procedure for such changes). However, I think that, for at least some cases, the appeals procedure should be redesigned so that: * we identify the body that is actually responsible for the decision being appealed. Sometimes that will be a WG Chair, sometimes an AD, sometimes the IESG. Empirically, it is typically the last person or body who has carefully considered a question (or should have) before the appeal about the decision on that question is initiated. * that body is neither expected nor permitted to make a formal writeup or response. The only question for it is does the content of this appeal raise issues that you didn't consider before, or didn't consider in enough depth, that, given its content you want to reopen the question and reconsider your own decision. The answer to that question requires reading the appeal and responding yes or no, not a long and agonizing process of writing and evaluating response text. Presumably, if they say yes, timers start running to prevent rejecting an appeal by sitting on it. * actual appeal processing then starts with the next body up the line or with an independent appeals-review body. That body can ask questions of the decision-making body and expect answers, but is not working from a record the decision-making body has prepared to refute the appeal. Actually changing to something like this would require sorting out a lot of details that I haven't even started to think about. But it might yield a somewhat cleaner and faster process. Then again, it might not, or it might not be worth the effort to design. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
John == John C Klensin [EMAIL PROTECTED] writes: John --On Wednesday, 28 November, 2007 17:15 -0500 Sam Hartman John [EMAIL PROTECTED] wrote: John == John C Klensin [EMAIL PROTECTED] writes: John --On Thursday, 29 November, 2007 09:54 +1300 Brian E John Carpenter John [EMAIL PROTECTED] wrote: John I'd like to see something like the above combined with a John shorter window, maybe at two levels (hold publication John until... and provisional until...). Of course, if an John appeal is actually filed, it would be sensible to hold John publication until it is resolved. I disagree that it is always sensible to hold publication until the appeal is resolved, particularly for expedited publication drafts. We've had some very bogus appeals and writing up the responses is not always our top priority. I agree that it is almost always desirable to delay publication once an appeal is filed. One critical assumption in my evaluation is that RFCs can be withdrawn. I'm quite confident that given a court order the RFC editor, the IETF website, etc, would find a way to remove an RFC. As such, we as a community can establish our own processes for withdrawing an RFC. John There would be copies floating around somewhere and it would John violate some important precedents. I agree that their would be copies floating around. I'm not sure how important I consider the precedents to be, although I agree they exist. John I agree that we could do John this, but I hope it would only occur in response to an John external and binding order (such as the court order of your John example) rather than an IETF/IESG adoption of some version John of newspeak. John Let me try to restate what I was trying to suggest (with John some changes after thinking about subsequent comments). However with two minor points I agree with your thoughts on how we should handle this situation. In particular, I strongly agree that with the possible exception of one appeal, publication delay was desirable for all past IESG appeals. I agree that 2026 does not need to be changed and that your proposed model seems reasonable. John Independent of how long it takes the IESG to make a final John decision about an appeal, agree about text, etc., I believe John that they are able to quickly make a decision about whether John or not the appeal is totally without merit (a criterion we John have discussed before and one that is very different from John direction it is likely to consider or other form of John pre-judgment). I also believe that the IESG is able to ask John the IAB to quickly consider a totally without merit John conclusion and reach their own conclusion about it. It is not clear to me that 1) The IAB would be willing to engage in such a dialogue with the IESG on an outstanding appeal. 2) If they engaged in the dialogue they would be willing to consider such a question or come to a decision. The IAB's stanse on appeals handling has always confused me. Section 6.5 of RFC 2026 talks about an open appeals process, but the IAB members involved in the IESG process have always wanted to make sure they don't have access to information related to an appeal even when that creates inconvenience. IAB members have created back pressure against IESG considering involving the community in discussing open appeals. I get the feeling that if we discussed an appeal at the plenary, some IAB mem members might object and the IAB might feel that it had to ask its members not to get involved in the discussion. I don't think the IAB or its members are being unreasonable. I think that the goals of the appeals process are confusing and that it would be useful for the community to give guidance on what it wants. On how to balance neutrality vs openness and on how to balance appeals process as a consensus tool against appeals process as something else. In practice things seem to work and so it doesn't bother me if these issues are never particularly resolved. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
At 3:33 PM +0200 11/29/07, Jari Arkko wrote: And we can move a document to historic, Note that there are two different no process change needed proposals on the table: obsoleting with NULL (or a bit of explanation) and moving to Historic. Obsoleting a document is much easier for the outside world to understand than changing its status to Historic, given that we have many different reasons for Historic. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
Paul == Paul Hoffman [EMAIL PROTECTED] writes: Paul At 3:33 PM +0200 11/29/07, Jari Arkko wrote: And we can move a document to historic, Paul Note that there are two different no process change needed Paul proposals on the table: obsoleting with NULL (or a bit of Paul explanation) and moving to Historic. Obsoleting a document Paul is much easier for the outside world to understand than Paul changing its status to Historic, given that we have many Paul different reasons for Historic. I'd assume that you want to do both. Remember that obseleting a document does not imply it goes to historic. I've never fully agreed with that bit of rfc-editor-process trivia. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
--On Thursday, 29 November, 2007 09:54 +1300 Brian E Carpenter [EMAIL PROTECTED] wrote: I thought about this a bit when the RFC Editor started to catch up and accelerate; it's excellent news that it's no longer a theoretical question, so kudos to the Editor team (and IANA, who also have a role to play in getting many RFCs out). My conclusion is that the number of appeals is relatively low. I'd hate for the low risk of having to roll back an approval to slow down all publications. So my personal preference is to not hold up publication (unless there is good reason to expect an appeal), but to add a new RFC status, let's call it PROVISIONAL for the sake of argument, that would be applied if an appeal is received within the 2 month window but after publication. If the appeal succeeds, the status can be changed as appropriate (likely to HISTORIC), and if the appeal fails it can revert to its original value. I'd like to see something like the above combined with a shorter window, maybe at two levels (hold publication until... and provisional until...). Of course, if an appeal is actually filed, it would be sensible to hold publication until it is resolved. I don't see any possible reason why we need to give people two months to get an appeal filed: a month or, at most, six weeks ought to be more than sufficient. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Should the RFC Editor publish an RFC in less than 2 months?
Hi, --On Thursday, 29 November, 2007 09:54 +1300 Brian E Carpenter [EMAIL PROTECTED] wrote: I thought about this a bit when the RFC Editor started to catch up and accelerate; it's excellent news that it's no longer a theoretical question, so kudos to the Editor team (and IANA, who also have a role to play in getting many RFCs out). My conclusion is that the number of appeals is relatively low. I'd hate for the low risk of having to roll back an approval to slow down all publications. So my personal preference is to not hold up publication (unless there is good reason to expect an appeal), but to add a new RFC status, let's call it PROVISIONAL for the sake of argument, that would be applied if an appeal is received within the 2 month window but after publication. If the appeal succeeds, the status can be changed as appropriate (likely to HISTORIC), and if the appeal fails it can revert to its original value. I'd like to see something like the above combined with a shorter window, maybe at two levels (hold publication until... and provisional until...). Of course, if an appeal is actually filed, it would be sensible to hold publication until it is resolved. I don't see any possible reason why we need to give people two months to get an appeal filed: a month or, at most, six weeks ought to be more than sufficient. = I also think that in general, an approach like the above is needed. However, in some cases when for example, there is a consensus call on a sensitive draft on a specific ML, we get _sometime_ the opportunity to meet people who have never posted an email before to the specific ML... Of course, people complained about that as they just confuse the process. My point is that the appeal will/should also be carefully examined before it impacts a particular RFC or ...? Regards, Wassim H. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
At Thu, 29 Nov 2007 09:54:47 +1300, Brian E Carpenter wrote: On 2007-11-29 09:21, IETF Chair wrote: ... If we receive an appeal before the RFC is published, we can put a hold on the document, preventing pblication until the appeal has been studied. However, we have no way to pull an RFC back if it is published before the appeal arrives. As we all know, once an RFC is published, it cannot be changed. Thus, the RFCs form an archival series. If we find a bug in an RFC, we write a revised RFC that obsoletes the one that contains the error. So, what should we do if there is a successful appeal after the RFC is published? I thought about this a bit when the RFC Editor started to catch up and accelerate; it's excellent news that it's no longer a theoretical question, so kudos to the Editor team (and IANA, who also have a role to play in getting many RFCs out). My conclusion is that the number of appeals is relatively low. I'd hate for the low risk of having to roll back an approval to slow down all publications. So my personal preference is to not hold up publication (unless there is good reason to expect an appeal), but to add a new RFC status, let's call it PROVISIONAL for the sake of argument, that would be applied if an appeal is received within the 2 month window but after publication. If the appeal succeeds, the status can be changed as appropriate (likely to HISTORIC), and if the appeal fails it can revert to its original value. So, obviously it's important not conflate statements about what the rules *should* say with what they *do say*, but with that in mind, my reading of 2026 is that this isn't necessarily sufficient. Here's the relevant passage: S 6.5.2. If circumstances warrant, the IAB may direct that an IESG decision be annulled, and the situation shall then be as it was before the IESG decision was taken. The IAB may also recommend an action to the IESG, or make such other recommendations as it deems fit. The IAB may not, however, pre-empt the role of the IESG by issuing a decision which only the IESG is empowered to make. It seems to me that the situation of an existing RFC marked HISTORIC is pretty different from that of no RFC existing at all, so what ISTM that what you propose would require a change to 2026. -Ekr ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
At 4:02 PM -0500 11/28/07, John C Klensin wrote: So my personal preference is to not hold up publication (unless there is good reason to expect an appeal), but to add a new RFC status, let's call it PROVISIONAL for the sake of argument, that would be applied if an appeal is received within the 2 month window but after publication. If the appeal succeeds, the status can be changed as appropriate (likely to HISTORIC), and if the appeal fails it can revert to its original value. At first I thought you meant that all RFCs would be PROVISIONAL for two months, but on a second reading, what I understand you to mean is: 1) Anything published before the appeal window closes normally gets whatever status it would have had before (Proposed, Draft, Info, Exp). 2) Anything that gets appealed before the appeal window closed and for which the desired remedy relates to the document's status or language gets marked provisional 3) Anything for which the appeal succeeds and the remedy calls for the document to change or the status to change sees the document status go from provisional to historic and a new document with a new RFC number go out with the change/new status. I'm more-or-less okay with this, given that it does not hold up normal processing, but I note the difference between this and just publishing the docs and later changing their status is pretty small. I'd personally be willing to take the small number of cases where a document is published but quickly moved to historic as a corner case that doesn't need a special status. Appeals tend to be pretty big news within our community, and the rest of the world implements the internet drafts anyway This eliminates one possible remedy: removing something from publication. It's replaced with updating a document's status or publishing an update to it saying withdrawn as a result of appeal. I think that's okay as a consequence of avoiding self-imposed delay, but I do expect someone to squawk. I'd like to see something like the above combined with a shorter window, maybe at two levels (hold publication until... and provisional until...). Of course, if an appeal is actually filed, it would be sensible to hold publication until it is resolved. I don't see any possible reason why we need to give people two months to get an appeal filed: a month or, at most, six weeks ought to be more than sufficient. I also agree that shortening that appeal time is a reasonable idea, though it might require a two-stage Notify IESG of intent to appeal and File final language; there are some two month periods that have large dead zones (August in Europe, Christmas season in others). The real problem is often that the *combination* of the two month appeal window and the IESG response time can stretch to half a year or longer, especially when the IESG has to do significant work to answer an appeal. That's the only reason I think having a special status indicating the problem is reasonable. Ted ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
There are a few things I think people should keep in mind while discussing this: Russ has presented the IETF-particular case. If the solution lies in IETF process (i.e., update to RFC2026), that's fine. If the solution lies in adjusting RFC process, then we need to make sure there is agreement on how that impacts the whole RFC series (i.e., wider than IETF audience involved). For example -- shortening the appeal window (or going to a 2-stage process, as Ted noted) is an IETF process change.Determining that withdrawing a published RFC meets appeal-resolution requirements is an IETF process discussion. Changing the status of documents, or withdrawing them entirely, impacts the RFC series (RFC4844 and related). A wider discussion will be needed. (Note -- that wider discussion might be needed *anyway*, if there is belief that the ability to withdraw a published RFC is needed for other reasons.) Leslie. IETF Chair wrote: Dear IETF Community: Due to a lot of hard work, the RFC Editor is publishing approved Internet-Drafts more quickly. Overall this is just what we want to happen. However, I am concerned that the RFC Editor is might be getting too quick. Anyone can appeal the approval of a document in the two months following the approval. In the past, there was not any danger of the RFC Editor publishing a document before this timer expired, and the only documents that became RFCs in less than 60 days were the ones where the IESG explicitly asked for expedited processing. The recent improvements by the RFC Editor make it likely that all documents will be moving through the publication process in less than two months. If we receive an appeal before the RFC is published, we can put a hold on the document, preventing pblication until the appeal has been studied. However, we have no way to pull an RFC back if it is published before the appeal arrives. As we all know, once an RFC is published, it cannot be changed. Thus, the RFCs form an archival series. If we find a bug in an RFC, we write a revised RFC that obsoletes the one that contains the error. So, what should we do if there is a successful appeal after the RFC is published? While we figure out what policy we want, I have asked the RFC Editor to not publish any IESG approved documents until their appeal timer has expired. I also challenged the RFC Editor to move things along so fast that this matters. I suspect they can. Which means that the whole IETF community needs to help the leadership figure out the appropriate policy before the rapid processing of Internet-Draft documents into RFCs becomes the norm. Russ -- --- Reality: Yours to discover. -- ThinkingCat Leslie Daigle [EMAIL PROTECTED] --- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
John: RFC 2026 gives two months to appeal any decision. IESG approval of a document publication is one such decision. RFC 2026, section 6.5.4 says: All appeals must be initiated within two months of the public knowledge of the action or decision to be challenged. So, the two month timer begins when the approval announcement is sent. Russ At 04:02 PM 11/28/2007, John C Klensin wrote: I don't see any possible reason why we need to give people two months to get an appeal filed: a month or, at most, six weeks ought to be more than sufficient. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
On 2007-11-29 10:14, Eric Rescorla wrote: At Thu, 29 Nov 2007 09:54:47 +1300, Brian E Carpenter wrote: snip My conclusion is that the number of appeals is relatively low. I'd hate for the low risk of having to roll back an approval to slow down all publications. So my personal preference is to not hold up publication (unless there is good reason to expect an appeal), but to add a new RFC status, let's call it PROVISIONAL for the sake of argument, that would be applied if an appeal is received within the 2 month window but after publication. If the appeal succeeds, the status can be changed as appropriate (likely to HISTORIC), and if the appeal fails it can revert to its original value. So, obviously it's important not conflate statements about what the rules *should* say with what they *do say*, but with that in mind, my reading of 2026 is that this isn't necessarily sufficient. Here's the relevant passage: S 6.5.2. If circumstances warrant, the IAB may direct that an IESG decision be annulled, and the situation shall then be as it was before the IESG decision was taken. The IAB may also recommend an action to the IESG, or make such other recommendations as it deems fit. The IAB may not, however, pre-empt the role of the IESG by issuing a decision which only the IESG is empowered to make. It seems to me that the situation of an existing RFC marked HISTORIC is pretty different from that of no RFC existing at all, so what ISTM that what you propose would require a change to 2026. Very possibly. It's always struck me that the situation shall then be as it was before is a rather unrealistic goal, since you can't un-send email, un-publish a draft, cancel a past mailing list suspension, etc. Decisions can be revoked, but their physical consequences sometimes can't be. So in any case, that phrase in 2026 probably needs qualification. (For example, insofar as this is materially possible.) Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
What happens if the appeal is claiming that changes made in Auth 48 should have been reviewed by the working group and go against WG consensus? Given some of the changes I have seen between IESG approval and published RFC, this seems like a reasonable plausible scenario. On Nov 28, 2007, at 2:05 PM, Russ Housley wrote: John: RFC 2026 gives two months to appeal any decision. IESG approval of a document publication is one such decision. RFC 2026, section 6.5.4 says: All appeals must be initiated within two months of the public knowledge of the action or decision to be challenged. So, the two month timer begins when the approval announcement is sent. Russ At 04:02 PM 11/28/2007, John C Klensin wrote: I don't see any possible reason why we need to give people two months to get an appeal filed: a month or, at most, six weeks ought to be more than sufficient. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
John == John C Klensin [EMAIL PROTECTED] writes: John --On Thursday, 29 November, 2007 09:54 +1300 Brian E John Carpenter John [EMAIL PROTECTED] wrote: John I'd like to see something like the above combined with a John shorter window, maybe at two levels (hold publication John until... and provisional until...). Of course, if an John appeal is actually filed, it would be sensible to hold John publication until it is resolved. I disagree that it is always sensible to hold publication until the appeal is resolved, particularly for expedited publication drafts. We've had some very bogus appeals and writing up the responses is not always our top priority. I agree that it is almost always desirable to delay publication once an appeal is filed. One critical assumption in my evaluation is that RFCs can be withdrawn. I'm quite confident that given a court order the RFC editor, the IETF website, etc, would find a way to remove an RFC. As such, we as a community can establish our own processes for withdrawing an RFC. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
At Wed, 28 Nov 2007 17:15:40 -0500, Sam Hartman wrote: John == John C Klensin [EMAIL PROTECTED] writes: John --On Thursday, 29 November, 2007 09:54 +1300 Brian E John Carpenter John [EMAIL PROTECTED] wrote: John I'd like to see something like the above combined with a John shorter window, maybe at two levels (hold publication John until... and provisional until...). Of course, if an John appeal is actually filed, it would be sensible to hold John publication until it is resolved. I disagree that it is always sensible to hold publication until the appeal is resolved, particularly for expedited publication drafts. We've had some very bogus appeals and writing up the responses is not always our top priority. I'm actually very concerned by this reasoning. Upon deciding an appeal, the IESG owes the appellant a prompt response. If they don't have time to write up a response, then that's fine, they can treat the appeal as undecided but the document should be held pending the IESG getting time to do that. Remember that the appellant cannot appeal to the IAB until the IESG has responded to his appeal (S 6.5.2.). Given that many appeals are appeals *of IESG actions* and therefore that the IESG is not a neutral party, it seems quite problematic to allow the IESG to in effect decide the appeal but simply not respond, thus denying the appellant any avenue of recourse to a neutral body. In the limit, the IESG could simply internally decide to proceed as if the appeal had been denied, but hold the appeal response indefinitely, thus indefinitely denying the appellant further recourse under 2026. One critical assumption in my evaluation is that RFCs can be withdrawn. I'm quite confident that given a court order the RFC editor, the IETF website, etc, would find a way to remove an RFC. As such, we as a community can establish our own processes for withdrawing an RFC. So, clearly we need some way to withdraw documents *from the repository*, for instance for copyright reasons, but I think that's fundamentally a different issue from retracting them. Let's say that document X is published at PS, but contains some purely informational example source code. If it were later determined that that code was improperly licensed, X would need to be removed from the repository, but we would not treat it as if it didn't exist. If, for instance, document Y had a normative dependency on X, we wouldn't feel the need to go back and mark Y HISTORIC/WITHDRAWN/whatever. We'd just go and do a noninfringing document that obsoleted X. By contrast, if document Z depends on document W and W is subject to a successful appeal, we would need to withdraw Z, any documents that depended on it, and ultimately the transitive closure of any documents depending on W. So, I think these cases are quite different. -Ekr ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
I can think of an example where a minor clarification was made in AUTH 48. The appropriate AD confirmed the change but it still proved to be very controversial. (For the life of me, I have *never* understood why. I have read that sentence a thousand times, and I still don't see the problem. Not that it matters here, of course.) I don't know if an appeal for AUTH 48 changes has ever been filed, but I could certainly see it happening. There is no way to ensure that documents aren't published until *all* the appeals timers expire. Given that, let's encourage the RFC Editor to publish when ready, and we can concentrate on establishing a process that works when the appeal concerns a published document. Tim On Nov 28, 2007, at 5:14 PM, Cullen Jennings wrote: What happens if the appeal is claiming that changes made in Auth 48 should have been reviewed by the working group and go against WG consensus? Given some of the changes I have seen between IESG approval and published RFC, this seems like a reasonable plausible scenario. On Nov 28, 2007, at 2:05 PM, Russ Housley wrote: John: RFC 2026 gives two months to appeal any decision. IESG approval of a document publication is one such decision. RFC 2026, section 6.5.4 says: All appeals must be initiated within two months of the public knowledge of the action or decision to be challenged. So, the two month timer begins when the approval announcement is sent. Russ At 04:02 PM 11/28/2007, John C Klensin wrote: I don't see any possible reason why we need to give people two months to get an appeal filed: a month or, at most, six weeks ought to be more than sufficient. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
One easy solution to the problem is to not change anything in the current IETF or RFC rules. If an RFC has been published before the appeal is brought, and that appeal is ultimately successful, a new RFC is issued that obsoletes the old RFC. That new RFC can essentially be a NULL, although hopefully it would have an explanation why an empty RFC is obsoleting a non-empty one. That new RFC can also be partially populated; for example, if the resolution of the appeal is to pull a contentious section or appendix. Given the extreme rarity of the situation where an appeal leads to non-publication or changed publication, it seems wasteful to create new rules (and spend lots of time arguing about them) when no new rules are needed. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
Eric == Eric Rescorla [EMAIL PROTECTED] writes: Eric At Wed, 28 Nov 2007 17:15:40 -0500, Eric Sam Hartman wrote: John == John C Klensin [EMAIL PROTECTED] writes: John --On Thursday, 29 November, 2007 09:54 +1300 Brian E John Carpenter John [EMAIL PROTECTED] wrote: John I'd like to see something like the above combined with a John shorter window, maybe at two levels (hold publication John until... and provisional until...). Of course, if an John appeal is actually filed, it would be sensible to hold John publication until it is resolved. I disagree that it is always sensible to hold publication until the appeal is resolved, particularly for expedited publication drafts. We've had some very bogus appeals and writing up the responses is not always our top priority. Eric I'm actually very concerned by this reasoning. Upon deciding Eric an appeal, the IESG owes the appellant a prompt response. If Eric they don't have time to write up a response, then that's Eric fine, they can treat the appeal as undecided but the Eric document should be held pending the IESG getting time to do Eric that. I was sloppy in my wording and thought process. In the American legal system, there is a concept of a preliminary injunction--a leagel procedure to stop some action pending the outcome of some legal action. The idea is that there are some cases where it is desirable to hold things pending an outcome being determined, and some cases where there is a desire to clean up the mess later if there ends up being a problem. I think that for some of the same reasons preliminary injunctions make sense in the IETF, it is sometimes desirable to say that the probability that withdrawing a document is going to be the right solution is low enough that the appeal should not block the process. The IESG typically doesn't decide appeals without actually having response text in front of it; I think that is right and proper. However, the IESG does sometimes know what direction it is likely to consider in drafting response text and does have an idea about how probable it is that publishing a document and later the IESG or IAB realizing that a mistake was made is harmful. I think there are cases where it is appropriate not to allow an pending appeal to block publication. It might be reasonable for the IAB to be able to hold publication before an appeal had formally reached them. Personally I think the current IAB would be too conservative in applying this power and I'd like the community to come up with some guidance to give the IAB if they were going to do that regularly. I have confidence that if the community could agree on guidance the IAB would do a fine job of applying that and I have confidence that absent guidance the IAB would use their best judgment. I just think the IAB tends to be more conservative than would be appropriate in this case. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
Paul == Paul Hoffman [EMAIL PROTECTED] writes: Paul One easy solution to the problem is to not change anything Paul in the current IETF or RFC rules. If an RFC has been Paul published before the appeal is brought, and that appeal is Paul ultimately successful, a new RFC is issued that obsoletes Paul the old RFC. That new RFC can essentially be a NULL, Paul although hopefully it would have an explanation why an empty Paul RFC is obsoleting a non-empty one. That new RFC can also be Paul partially populated; for example, if the resolution of the Paul appeal is to pull a contentious section or appendix. I would be happy with this solution. Paul Given the extreme rarity of the situation where an appeal Paul leads to non-publication or changed publication, it seems Paul wasteful to create new rules (and spend lots of time arguing Paul about them) when no new rules are needed. I agree. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
John C Klensin wrote: Of course, if an appeal is actually filed, it would be sensible to hold publication until it is resolved. +1 That would be two months, plus another two months after the decision if an appeal was filed and its resolution was unsatisfactory - after all the IESG checks its own approval, it should be unusual that the first round has any other effect than an are you sure ? question for very simple problems. I don't see any possible reason why we need to give people two months to get an appeal filed: a month or, at most, six weeks ought to be more than sufficient. Now with Brian's procdoc ION six weeks might be enough. It took me longer without it to find RFC 3710 and its incompatibility with RFC 2418 more than 3 years ago. Frank ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
At Wed, 28 Nov 2007 19:08:53 -0500, Sam Hartman wrote: Eric == Eric Rescorla [EMAIL PROTECTED] writes: Eric At Wed, 28 Nov 2007 17:15:40 -0500, Eric Sam Hartman wrote: John == John C Klensin [EMAIL PROTECTED] writes: John --On Thursday, 29 November, 2007 09:54 +1300 Brian E John Carpenter John [EMAIL PROTECTED] wrote: John I'd like to see something like the above combined with a John shorter window, maybe at two levels (hold publication John until... and provisional until...). Of course, if an John appeal is actually filed, it would be sensible to hold John publication until it is resolved. I disagree that it is always sensible to hold publication until the appeal is resolved, particularly for expedited publication drafts. We've had some very bogus appeals and writing up the responses is not always our top priority. Eric I'm actually very concerned by this reasoning. Upon deciding Eric an appeal, the IESG owes the appellant a prompt response. If Eric they don't have time to write up a response, then that's Eric fine, they can treat the appeal as undecided but the Eric document should be held pending the IESG getting time to do Eric that. I was sloppy in my wording and thought process. In the American legal system, there is a concept of a preliminary injunction--a leagel procedure to stop some action pending the outcome of some legal action. The idea is that there are some cases where it is desirable to hold things pending an outcome being determined, and some cases where there is a desire to clean up the mess later if there ends up being a problem. I think that for some of the same reasons preliminary injunctions make sense in the IETF, it is sometimes desirable to say that the probability that withdrawing a document is going to be the right solution is low enough that the appeal should not block the process. Yes, I've been thinking about this analogy as well, but I think it cuts the opposite way from what you're arguing. In a legal proceeding, the two parties argue their case before a presumptively neutral arbiter (the judge). As you say, the judge can choose to issue a preliminary injunction while the case is being heard and pending the final outcome. This works because at least in theory the judge is neutral--you wouldn't let the plaintiff or the defendant decide on whether the PI should be granted. A 2026 appeal is an entirely different case, namely, that the party hearing the appeal (the IESG) isn't neutral at all. On the contrary, they're the party who's decision is being appealed! So, no, I don't think they can be allowed to make a decision about whether the appellant is likely to prevail or the damage that is likely to be done if the appeal is later upheld. The IESG typically doesn't decide appeals without actually having response text in front of it; I think that is right and proper. However, the IESG does sometimes know what direction it is likely to consider in drafting response text and does have an idea about how probable it is that publishing a document and later the IESG or IAB realizing that a mistake was made is harmful. It seems to me that if the IESG has enough confidence about the direction it is likely to consider to proceed with document publication, they have in effect decided the appeal, regardless of whether the response text has actually been drafted. And if not, then they should stop publication until they have decided the appeal. As for the IESG's ability to predict whether the IAB will eventually uphold an appeal, my experience is that it's not actually that great, and, given the inherent COI involved, I don't see how they can be allowed to make that judgement, regardless of its expected accuracy. I think there are cases where it is appropriate not to allow an pending appeal to block publication. That may be so. What I'm saying is that the IESG shouldn't get to make that decision. It might be reasonable for the IAB to be able to hold publication before an appeal had formally reached them. Personally I think the current IAB would be too conservative in applying this power and I'd like the community to come up with some guidance to give the IAB if they were going to do that regularly. I have confidence that if the community could agree on guidance the IAB would do a fine job of applying that and I have confidence that absent guidance the IAB would use their best judgment. I just think the IAB tends to be more conservative than would be appropriate in this case. Well, that's not what I proposed: rather, I said there should be a hard rule. That said, regardless of whether the IAB is too conservative or not, they're at least in principle neutral, which makes them a far more appropriate body to make this decision than the IESG, which is not. -Ekr
Re: Should the RFC Editor publish an RFC in less than 2 months?
IETF Chair skrev: Dear IETF Community: Due to a lot of hard work, the RFC Editor is publishing approved Internet-Drafts more quickly. Overall this is just what we want to happen. However, I am concerned that the RFC Editor is might be getting too quick. Anyone can appeal the approval of a document in the two months following the approval. In the past, there was not any danger of the RFC Editor publishing a document before this timer expired, and the only documents that became RFCs in less than 60 days were the ones where the IESG explicitly asked for expedited processing. The recent improvements by the RFC Editor make it likely that all documents will be moving through the publication process in less than two months. My short reply: Bad idea. In my opinion, placing such a hold on documents is a triumph of process over sanity. We have already lost the opportunity to restrict the circulation of the text when we published the I-D, which anyone in the world can copy. So the further aggravation of having copies out there of a document with an RFC number that isn't in the index any more is, if it is a difference at all, an extremely marginal one. So the remedy of making the text not published is already unavailable. In that case, the only difference between holding an approved document and then not publishing it and publishing an RFC and then withdrawing it is that in the latter case, we're left with a permanent mark in our RFC Index saying This RFC was withdrawn. (I know this option does not exist now, as Leslie pointed out. I have big problems seeing a situation where it would be appropriate, but if people really argue that we need it once we admit that we can't unpublish an I-D, we can change the rules.) If we err so egregriously as to end up in a situation where a retraction is the appropriate remedy (as opposed to the situation where we can publish another RFC saying on further consideration, the idea we approved in RFC was stupid, and we regret doing it; it's now Historic), having to live with the blame for such a mark forever is appropriate and just punishment. We're ALREADY in a no-hold situation in many cases; when someone appeals the decision on an appealed approval, we do NOT, in general, hold the publication of the RFC, even though we are not just afraid there'll be an appeal, we positively *know* that there is an appeal. The same thing applies for appeals against the RFC Editor/WG chair/author's decision to approve an AUTH48 change. Such a hold is a dumb idea, and we shouldn't do it. Just publish, and if we turn out to have made the wrong decision, make a public statement saying that; one form of public statement is leaving a hole in the RFC Index. (As to the ideas for further complexity in the process with provisional markers considered by Brian and John: My opinion is that they add cost, and in practice provide zero value. Just publish, and if needed, unlist.) Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
--On Wednesday, 28 November, 2007 17:15 -0500 Sam Hartman [EMAIL PROTECTED] wrote: John == John C Klensin [EMAIL PROTECTED] writes: John --On Thursday, 29 November, 2007 09:54 +1300 Brian E John Carpenter John [EMAIL PROTECTED] wrote: John I'd like to see something like the above combined with a John shorter window, maybe at two levels (hold publication John until... and provisional until...). Of course, if an John appeal is actually filed, it would be sensible to hold John publication until it is resolved. I disagree that it is always sensible to hold publication until the appeal is resolved, particularly for expedited publication drafts. We've had some very bogus appeals and writing up the responses is not always our top priority. I agree that it is almost always desirable to delay publication once an appeal is filed. One critical assumption in my evaluation is that RFCs can be withdrawn. I'm quite confident that given a court order the RFC editor, the IETF website, etc, would find a way to remove an RFC. As such, we as a community can establish our own processes for withdrawing an RFC. There would be copies floating around somewhere and it would violate some important precedents. I agree that we could do this, but I hope it would only occur in response to an external and binding order (such as the court order of your example) rather than an IETF/IESG adoption of some version of newspeak. Let me try to restate what I was trying to suggest (with some changes after thinking about subsequent comments). Historically and going back to the dawn of IETF time, when the IESG has asked the RFC Editor to delay publication and given a reason, the RFC Editor has complied. I don't see any reason why that should change, and I don't see any reason why we need to adopt new rules and procedures for the IESG to make the request or requiring the RFC Editor to honor it. Independent of how long it takes the IESG to make a final decision about an appeal, agree about text, etc., I believe that they are able to quickly make a decision about whether or not the appeal is totally without merit (a criterion we have discussed before and one that is very different from direction it is likely to consider or other form of pre-judgment). I also believe that the IESG is able to ask the IAB to quickly consider a totally without merit conclusion and reach their own conclusion about it. If an appeal of a standards action that would lead to RFC publication appears to be substantive, then I really don't seem much harm in delaying publication until the issues can be resolved. In reaching that conclusion, I'm drawing heavily on two things. The first is that we have, relatively speaking, few appeals that get far enough to merit full IESG consideration. We also see long delays due to IESG consideration of issues raised during or after Last Call, sometimes by IESG members, and working out the resolution of those issues. It doesn't seem to me to make a tremendous difference whether we suffer publication delay due to pre-approval delays and negotiation or due to delays brought on by an appeal. In addition, while I have been saddened by the typical length of time between approval and publication in the last several years, and am delighted that we are now forced to ask this question, I think there is little evidence that the earlier publication cycles have caused us serious harm (except, perhaps, in further reducing the motivation to advance things along the standards track). The second is that, while the IESG has often taken months to getting around to considering an appeal, generating and agreeing on response text, etc., there is no requirement for such long delays. If the IESG doesn't want a lengthy publication delay, then let it move expeditiously. To be specific, suppose we adopted the following model, which I believe requires no change to 2026 (some refinements are possible if we start making modifications): * If someone intends to appeal, and wants to make a case for publication delay until the appeal is resolved, they must give notice of that intent with an outline of issues within a month (for example). Such a notice would generally result in a publication delay, at least for the rest of the two-month limit to permit an actual appeal to be filed. * When an appeal is filed, it may contain a request that publication be delayed until the appeal is resolved and an explanation as to why that action would be appropriate. If it does not, publication will not be delayed (unless the IESG decides to block it on its own, which it can do at any time, with or without a pending appeal). If it does contain such a request, the request must be granted unless the IESG concludes that either the appeal, or the publication delay
