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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf