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@xxxxxxxxxxxx> > 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 > > > >