Re: Call for Review of draft-rfced-rfcxx00-retired, "List of Internet Official Protocol Standards: Replaced by an Online Database"

[Brian E Carpenter <[e-mail]>]

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 <[e-mail]>
> 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
> 
> 
> 
>