That is actually a pretty good example of an Informational RFC that was necessary as part of the standards process even if it was not standard itself. The IETF had no control over the infrastructure being described so it was not creating a standard. But the development of an IP based alternative required a description of the existing legacy system that simply did not exist at the time. Referencing the standards on which the legacy system was purportedly based would not be an acceptable substitute even if the documents were freely available. On Thu, Sep 9, 2010 at 8:06 AM, Richard Shockey <richard@xxxxxxxxxx> wrote: > And add to that one that Mr Burger should vaguely recall :-) > > http://www.rfc-editor.org/rfc/rfc3482.txt > > Number Portability in the Global Switched Telephone Network (GSTN): > An Overview > > -----Original Message----- > From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf Of Fred > Baker > Sent: Wednesday, September 08, 2010 9:49 PM > To: Eric Burger > Cc: IETF Discussion > Subject: Re: The Evils of Informational RFC's > > Please, no. > > The RFC Series is not a collection of standards. It is community memory, and > in it we have white papers that have been seminal such as RFC 970, problem > statements, requirements documents, and analyses of a wide variety, all of > which are informational. > > Let me give you two specific examples: > > http://www.ietf.org/rfc/rfc2804.txt > 2804 IETF Policy on Wiretapping. IAB, IESG. May 2000. (Format: > TXT=18934 bytes) (Status: INFORMATIONAL) > > http://www.ietf.org/rfc/rfc3924.txt > 3924 Cisco Architecture for Lawful Intercept in IP Networks. F. Baker, > B. Foster, C. Sharp. October 2004. (Format: TXT=40826 bytes) (Status: > INFORMATIONAL) > > The former gives a view on the topic of lawful interception, and requests > that anyone that develops an interception technology publish it so that it > can be reviewed openly within the community. The latter does exactly that. > > The collected experience in the RFC series is at least as valuable as the > protocol descriptions in it. > > On Sep 9, 2010, at 12:03 AM, Eric Burger wrote: > >> Can we please, please, please kill Informational RFC's? Pre-WWW, having > publicly available documentation of hard-to-get proprietary protocols was > certainly useful. However, in today's environment of thousands of > Internet-connected publication venues, why would we possibly ask ourselves > to shoot ourselves in the foot by continuing the practice of Informational > RFC publication? >> >> On Sep 3, 2010, at 7:48 PM, Richard Bennett wrote: >> >>> With respect, Brian, I don't think this is simply the failure of > journalists to discern the distinction between Informational RFCs and > Standards Track RFCs. Nobody has made the claim that the IETF produced a > standard for accounting and billing for QoS or anything else. Informational > RFCs are a perfectly fine record of what certain people in the IETF > community may be "envisioning" at a given time, as long as people understand > that "envisioning" is not the same as "requiring," which is basic English > literacy. >> _______________________________________________ >> Ietf mailing list >> Ietf@xxxxxxxx >> https://www.ietf.org/mailman/listinfo/ietf > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf > -- Website: http://hallambaker.com/ _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf