While I generally agree with John here, let's not forget what caused the
IESG to put together that procedure in the first place and let's not get
back to that previous state:
The problem is that "moving to Historic" is really a Standards Track
thing to do. What was happening before is that these "moves" were being
done in Informational RFCs, and anyone who didn't happen to notice the
Last-Call for the document, or decided not to care all that much because
the document was Informational, was not going to notice that the IESG
was making this declaration that another document had moved to Historic
status. Not only that, these moves to Historic were not being properly
kept track of, and it took a good deal of research to figure out when
certain old docs became Historic, and why.
(BTW: Personally, I think it's bad form for any document to say, "This
document moves X to Historic", as it does in this case. I think "This
document requests that X be moved to Historic" is probably more
accurate.)
In this case, the name of the Informational draft is so painfully
obvious that I think the IESG could "just do the right thing". They
certainly don't need to re-Last-Call this document; simply Last-Calling
the move to Historic is (more than) sufficient. But lets not go back to
the previous state of randomly, and without any breadcrumbs, declaring
things as Historic.
pr-the-only-slightly-less-grumpy
On 27 Mar 2018, at 16:02, John C Klensin wrote:
Just two observations by someone who is not at all involved in
this. As others have observed recently in other contexts, one
of the main distinctions that used to characterize the IETF and
its work was that we focused on doing the right thing for the
Internet, with flexibility to do The Right Thing in specific
cases, rather than getting completely constipated by large
collections of rigid rules, applied mindlessly. I favor being
very careful about what we identify as Historic and about having
traceability and easily-accessed information, but this
discussion seems to be headed down the path toward "well, we
made these rules that didn't allow for all of the cases, so we
need to follow them without thinking". That doesn't seem
desirable, especially if it represents a trend.
I do see a special issue in this case: as I understand it, NSA
has posted documents that are intended to replace some of the
documents under discussion and has asked the ISE to publish
them. If those documents were slated for publication in the
IETF Stream, I assume the Right Thing to do would be to have
them contain text obsoleting the earlier versions and
eliminating any confusion. But they are not, which I presume is
one of the reasons we are in this tangle.
FWIW, would strongly encourage the IESG to take advantage of the
considerable trust and flexibility the community has given it
(and which has been taken advantage many times in the past when
doing so has suited the IESG's convenience) to consider and cut
through this knot rather than taking a position that sounds too
much like "well, we made up this procedure, the community is
stuck with it, and we think it is better to subject the entire
community to the costs of an unnecessary Last Call than to
figure out how to consider the facts of the situation".
best,
john-the-grump
--On Tuesday, March 27, 2018 15:08 -0500 Benjamin Kaduk
<kaduk@xxxxxxx> wrote:
I was just looking at
https://www.ietf.org/mail-archive/web/ietf-announce/current
/maillist.html, which does *not* show an IETF Last Call
being issued for "Reclassification of Suite B Documents to
Historic Status" (the status change document) until today.
So that seems to be the part that was missed last time.
I do not believe that the additional month will yield any new
information.
I don't believe that anyone thinks it will. But, until the
IESG decides to revise
https://www.ietf.org/iesg/statement/designating-rfcs-as-histor
ic.html it is the process we are stuck with. (And given the
document load for the next couple telechats, I don't expect
the IESG to get around to deciding to revise this statement
before the four week LC is up...)
