I think that if we worried about every minor deviation from RFC 2026,
we would be here for a long time and wasting most of it.
I have no particular objection to publishing the draft.
Regards
Brian Carpenter
(who tried and failed - see draft-carpenter-rfc2026-critique,
draft-carpenter-rfc2026-practice, draft-carpenter-rfc2026-changes)
On 17/08/2013 06:44, John C Klensin wrote:
--On Thursday, August 15, 2013 12:06 -0700 SM <sm(_at_)resistor(_dot_)net>
wrote:
At 11:48 14-08-2013, IAB Chair wrote:
This is a call for review of "List of Internet Official
Protocol Standards: Replaced by an Online Database" prior to
potential approval as an IAB stream RFC.
The document is available for inspection here:
https://datatracker.ietf.org/doc/draft-rfced-rfcxx00-retired/
From Section 2.1 of RFC 2026:
'The status of Internet protocol and service specifications
is
summarized periodically in an RFC entitled "Internet
Official
Protocol Standards".'
My guess is that draft-rfced-rfcxx00-retired cannot update RFC
2026. Does the IAB have any objection if I do something about
that?
SM,
You have just identified another aspect of why I find this
document troubling. I note that requirement of RFC 2026 has not
been satisfied for years unless one interprets "periodically" as
consistent with "whenever we get around to it, which, in today's
age, is likely to be never". I note that the last version of
STD 1 was RFC 5000, published in May 2008 and that its
predecessor was RFC 3700 in July 2004, i.e., there was a four
year interval followed by at least a seven year one. That is
well outside most normal interpretations of "periodic".
I don't personally think it is worth it (or, more specifically,
think the resources could be better spent in other ways) but, if
one believed the "keep anything that might turn out to be
historically important" theme of the IETF 86 History BOF, then
there is value in maintaining the sort of comprehensive status
snapshot that STD 1 was supposed to provide (once its [other]
original purpose of being part of a report to the sponsor became
irrelevant) even if that snapshot is taken only once every few
years.
That aside, I think this document is almost completely
unnecessary. RFC 5000 already points to the HTML version of the
RFC index as the authority for contemporary information. There
has, as far as I know, never been a requirement that STD 1 be
issued as RFCs numbered NN00, nor that all such numbers be
reserved for that purpose, outside the internal conventions of
the RFC Editor function.
At the same time, if the IAB and RSE believe that assembling and
publishing this statement formally and in the RFC Series is a
good use of their time and that of the community, I think it is
basically harmless, _unless_ it becomes an opportunity to
nit-pick such questions as its relationship to requirements or
statements in 2026 or elsewhere.
From Section 3:
"This document formally retires STD 1. Identifier STD 1
will not be
re-used unless there is a future need to publish periodic
snapshots
of the Standards Track documents (i.e., unless the
documentation is
resumed)."
The document argues that STD 1 is historic as there is an
online list now. The above reserves an option to restart
periodic snapshots if there is a future need. I suggest
removing that option as I presume that the IAB has thought
carefully about the long term evolution of the Series before
taking the decision to retire STD 1.
This is another form of the nit-picking (if there were protocols
involved, the historical term would involve the phrase "protocol
lawyer") that concerns me. I don't remember where it is written
down (if at all), but the RFC Editor has had a firm rule ever
since I can remember that STD numbers are never reused for a
different topic. Violating that prohibition against reuse would
be a really stupid move on the part of the RFC Editor and/or the
IAB. If they were to be that stupid, we have much more serious
other problems. If they are going to continue to avoid that
sort of stupidity, then that part of the statement above is
completely unnecessary - but still harmless.
As far as removing the option is concerned, I think doing so
would be pointless if the rest of the statement remains. For
better or worse, anything that is written into one RFC by the
IAB (or, under different circumstances, the IETF) can be amended
out of it by another RFC. While I think it unlikely, I can
imagine at least one scenario, tied to the historical concern
above, under which we would resume publishing a snapshot.
Whether the IAB has considered it or not and whatever promises
this document does or does not make are irrelevant to whether or
not that would happen.
Summary: I think the RFC Series Editor should just make whatever
announcement she feels it is appropriate to make, recognizing
that we stopped regularly updating STD 1 long ago and have no
present intention of restarting. I think this document and the
process and associated work it imposes on the IAB and the
community are a waste of time that could be better used in other
ways. However, if they feel some desire to publish it in some
form, let's encourage them to just get it done and move on
rather than consuming even more time on issues that will make no
difference in the long term.
best,
john