Yes, you're right of course. I'd kind of forgotten that periodic review
since it has never happened (to my knowledge) in the last 29 years...
This underlines that there is work to be done by the IETF.
Regards
Brian
On 14-Mar-25 09:07, Pete Resnick wrote:
Still sans chapeau...
On 13 Mar 2025, at 12:58, Brian E Carpenter wrote:
Why not? If the protocol still works and is deployed, who cares? As
has been noted elsewhere, the IETF doesn't have a standard meaning for
"deprecate", and as far as I know doesn't have one for "obsolete"
either. For "historic", RFC 2026 only says:
'4.2.4 Historic
A specification that has been superseded by a more recent
specification or is for any other reason considered to be obsolete
is
assigned to the "Historic" level. (Purists have suggested that the
word should be "Historical"; however, at this point the use of
"Historic" is historical.)'
[...]
If the IETF wants to use "Historic" to mean "don't do this", they
would need to say so. Personally, I quite like the 4th definition in
Merriam-Webster: dating from or preserved from a past time or culture.
Actually, it says quite a bit more about it further down in section 6.
(I'm including some things which are not actually true, but in there
nonetheless.)
6.2
When a standards-track specification has not reached the Internet
Standard level but has remained at the same maturity level for
twenty-four (24) months, and every twelve (12) months thereafter
until the status is changed, the IESG shall review the viability of
the standardization effort responsible for that specification and
the
usefulness of the technology. Following each such review, the IESG
shall approve termination or continuation of the development effort,
at the same time the IESG shall decide to maintain the specification
at the same maturity level or to move it to Historic status.
6.3
A new version of an established Internet Standard must progress
through the full Internet standardization process as if it were a
completely new specification. Once the new version has reached the
Standard level, it will usually replace the previous version, which
will be moved to Historic status. However, in some cases both
versions may remain as Internet Standards to honor the requirements
of an installed base. In this situation, the relationship between
the previous and the new versions must be explicitly stated in the
text of the new version or in another appropriate document (e.g., an
Applicability Statement; see section 3.2).
6.4
As the technology changes and matures, it is possible for a new
Standard specification to be so clearly superior technically that
one
or more existing standards track specifications for the same
function
should be retired. In this case, or when it is felt for some other
reason that an existing standards track specification should be
retired, the IESG shall approve a change of status of the old
specification(s) to Historic. This recommendation shall be issued
with the same Last-Call and notification procedures used for any
other standards action. A request to retire an existing standard
can
originate from a Working Group, an Area Director or some other
interested party.
pr
--
rswg mailing list -- rswg@rfc-editor.org
To unsubscribe send an email to rswg-le...@rfc-editor.org
