At 04:10 PM 8/13/2015, Pete Resnick wrote:
Mike,
I think there are a couple of factual mistakes in here,
I'm pretty sure I differ with you on whether they constitute factual mistakes
versus different interpretations.
though I don't think they'll change either of our opinions about this
particular document:
On 13 Aug 2015, at 10:26, Michael StJohns wrote:
1) Unlike the publication of a new RFC and its associated dates, there isn't
any way to permanently associate the change of status date with the RFC. At
some future time (and here I'm talking 10-20 years), will it ever be
important to be able to identify when the change was made (without having to
do email archeology)?
A change in status of a Standards Track document (whether up in the Standards
Track or down to Historic) requires a "Standards Action" notification, and
that gets documented in the IESG minutes. Not an ideal markup system (only
half better than email spelunking), but the process is there. (See 2026 6.1.3,
and RFC 7100.)
Yes but as I noted - finding that in the IESG minutes requires email
archeology. There is nothing associated with the document itself, nor for that
matter with the RFC index system that indicates that a document was made a BCP
on a date other than the date it was published.
Changes to Historic require the submission of an RFC to mark the change
Not according to 2026 6.4. All it requires is a Last-Call and then the
notification procedures in 6.1.3.
https://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html While
you are correct that 2026 only requires what you say it does, I read the IESG
statement on saying "no, we're not doing it that way any more and it's our
call".
And the reason that was put in place is pretty clear:
We have reclassified RFCs as Historic through different mechanisms and with
different documentation over time. All reclassifications have suffered from a
common problem: there is no direct reference from the RFC that has been made
Historic to the explanation of why that action was taken.
Finally, the section in that document that begins "The current process, then,
of moving an RFC to Historic..." no longer just permits the simple last call.
Or do you believe that page is not the current process?
2) According to RFC 2026, BCPs are documents of the IESG, not the IAB and
IESG together.
Well, they go through IESG review, but they're documents that are "viewed as
having the technical approval of the IETF". That said, 2026 does recognize the
IAB as a potential author of a BCP:
While it is recognized that entities such as the IAB and IESG are
composed of individuals who may participate, as individuals, in the
technical work of the IETF, it is also recognized that the entities
themselves have an existence as leaders in the community. As leaders
in the Internet technical community, these entities should have an
outlet to propose ideas to stimulate work in a particular area, to
raise the community's sensitivity to a certain issue, to make a
statement of architectural principle, or to communicate their
thoughts on other matters. The BCP subseries creates a smoothly
structured way for these management entities to insert proposals into
the consensus-building machinery of the IETF while gauging the
community's view of that issue.
My read has always been that the IAB and/or IESG can create a document for the
purposes above, it goes through an IETF discussion/edit, and then it can
become a BCP of the IETF.
I can live with the reading of the text. But does that then mean that the
IAB of the current era should be giving its approval as a group prior to asking
the IESG for its approval? Given that it is a joint statement and both groups
are listed as authors.
Later, Mike