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 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). I've even calculated the cost for an "unfriendly takeover" of the IETF, and fortunately arrived at a sum that they couldn't hide (between 10 and 20 million USD). > 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. Yes, the "experimental" solution for a case discussed here recently is elegant wrt stable IANA registries. Admittedly I wouldn't try to explain this to hit and run posters. Maybe we should have a kind of "help" list for procedural issues, and for new contributors, or a Wiki with a Forum, or similar. It's good if the number of folks who know all rules (and ways to bypass them) is not yet zero, but it starts to get very confusing if the published rules are always the old rules, while the real rules are some kind of elitist "need to know" insider oral history. Fortunately at least the errata submission works again - please send pictures if you happen to watch the historic moment when an A-D figures out what this actually means, I'd get a screaming fit as victim of this assault... ;-) > 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. Depends on the registry, doesn't it ? Frank _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf