On 11/21/2013 7:40 AM, John C Klensin wrote:
it seems to
me that you are making a leap from "the metadata are available
if you know where to look" (or use the right tools) to
Which is exactly the same model being applied when explanatory text is
published through an RFC.
We not not make sure that someone seeking the original RFC will find the
explanatory RFC concerning a move to history.
The much-maligned datatracker makes the link and the RFC Editor Search
makes the link. The former already also points to non-RFC discussion
and the latter can easily be modified to do that too.
"therefore it is reasonable to change the procedures by which
standards-affecting decisions are documented and to introduce
those procedures via a specific case".
There is no such "procedure".
There is an occasional practice, but nothing codified.
Certainly there is no procedure that is documented by the IETF. Not in
RFC 2026. And not in the obscure IESG Statement on the matter of moving
to Historic:
http://www.ietf.org//iesg/statement/designating-rfcs-as-historic.html
In fact, most RFCs that are moved to Historic do not publish an
explanatory RFC, although yes, some do.
If my count is correct[*], there have been 44 RFC published since
2000 that were moved to Historic. Of those, 6 have had explanatory RFCs
published along with the move the Historic. That's 14%.
No doubt, once can play with the analysis to up the percentage,
but the essential points are:
1. There is no established IETF (or IESG) rule about
publishing explanatory text
2. There is no consistent practice in publishing
explanatory text
It also seems to me
that this process involves doing that without any real
discussion of the procedural change independent of that case.
If we push all other issues aside, it is that change, without a
clear discussion or statement of what is being done, that is
troubling, not the particular action or documentation of one
particular case.
I agree. So please stop trying to impose a new rule due to this one case.
So here's the thing:
The problem with the analysis that John then pursued is that he
cherry-picked examples that suited his view and ignored the ones that
are just as plausible but don't support that view.
That suggests to me that, if we are going to expect people to go
to the datatracker (or equivalent) in all cases, we have some
act-cleaning-up to do.
Isn't it nice that John and I still manage to find substantive points to
agree on? Like this one.
The IETF spent a ton of money developing the datatracker. In a few
places, we press for its use, but mostly we don't.
For example, it should always be the first returned entry when doing a
google search for an RFC or Internet-Draft.
d/
ps. Speaking of side-effects, although I didn't look carefully, a
side-effect of the quick research to produce the data for this note
causes me to suspect that I might hold the record for the most RFCs
moved to Historic...
RFCs Moved to Historic -- Annotated with explanatory RFCs
RFC 2673 Binary Labels in the Domain Name System August 1999
RFC 2754 RPS IANA Issues January 2000 RFC 6254
RFC 2766 Network Address Translation - Protocol Translation
(NAT-PT) February 2000 rfc4966
RFC 2776 Multicast-Scope Zone Announcement Protocol (MZAP)
February 2000
RFC 2831 Using Digest Authentication as a SASL Mechanism
May 2000 rfc6331
RFC 2841 IP Authentication using Keyed SHA1 with Interleaved Padding
(IP-MAC) November 2000
RFC 2874 DNS Extensions to Support IPv6 Address Aggregation and
Renumbering July 2000
RFC 2885 Megaco Protocol version 0.8 August 2000
RFC 2886 Megaco Errata August 2000
RFC 2908 The Internet Multicast Address Allocation Architecture
September 2000
RFC 2909 The Multicast Address-Set Claim (MASC) Protocol
September 2000
RFC 2965 HTTP State Management Mechanism October 2000
RFC 3340 The Application Exchange Core July 2002
RFC 3341 The Application Exchange (APEX) Access Service July 2002
RFC 3342 The Application Exchange (APEX) Option Party Pack,
Part Deux! July 2002
RFC 3343 The Application Exchange (APEX) Presence Service
April 2003
RFC 3525 Gateway Control Protocol Version 1 June 2003
RFC 5125
RFC 3627 Use of /127 Prefix Length Between Routers Considered
Harmful September 2003 RFC 6547
RFC 3913 Border Gateway Multicast Protocol (BGMP): Protocol
Specification September 2004
RFC 4156 The wais URI Scheme August 2005
RFC 4157 The prospero URI Scheme August 2005
RFC 4351 Real-Time Transport Protocol (RTP) Payload for Text
Conversation Interleaved in an Audio Stream January 2006
RFC 4612 Real-Time Facsimile (T.38) - audio/t38 MIME Sub-type
Registration August 2006
RFC 4693 IETF Operational Notes October 2006 RFC 6393
RFC 4743 Using NETCONF over the Simple Object Access Protocol
(SOAP) December 2006
RFC 4744 Using the NETCONF Protocol over the Blocks Extensible
Exchange Protocol (BEEP) December 2006
RFC 4870 Domain-Based Email Authentication Using Public Keys
Advertised in the DNS (DomainKeys) May 2007
RFC 4905 Encapsulation Methods for Transport of Layer 2 Frames over
MPLS Networks June 2007
RFC 4906 Transport of Layer 2 Frames Over MPLS June 2007
RFC 5143 Synchronous Optical Network/Synchronous Digital Hierarchy
(SONET/SDH) Circuit Emulation Service over MPLS (CEM) Encapsulation February 2008
RFC 5412 Lightweight Access Point Protocol February 2010
RFC 5413 SLAPP: Secure Light Access Point Protocol February 2010
RFC 5414 Wireless LAN Control Protocol (WiCoP) February 2010
RFC 5772 A Set of Possible Requirements for a Future Routing
Architecture February 2010
RFC 5773 Analysis of Inter-Domain Routing Requirements and
History February 2010
RFC 5806 Diversion Indication in SIP March 2010
RFC 6037 Cisco Systems' Solution for Multicast in BGP/MPLS IP
VPNs October 2010
RFC 6101 The Secure Sockets Layer (SSL) Protocol Version 3.0
August 2011
RFC 6123 Inclusion of Manageability Sections in Path Computation
Element (PCE) Working Group Drafts February 2011
RFC 6348 Requirements for Point-to-Multipoint Extensions to the Label
Distribution Protocol September 2011
RFC 6529 Host/Host Protocol for the ARPA Network April 2012
RFC 6587 Transmission of Syslog Messages over TCP April 2012
RFC 6804 DISCOVER: Supporting Multicast DNS Queries November 2012
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net