RFC 3692: Assigning Experimental and Testing Numbers Considered Useful
In plain English — editorial summary, not part of the RFC
When experimenting with or extending protocols, it is often necessary to use some sort of protocol number or constant in order to actually test or experiment with the new function, even when testing in a closed environment. For example, to test a new DHCP option, one needs an option number to identify the new function. This document recommends that when writing IANA Considerations sections, authors should consider assigning a small range of numbers for experimentation purposes that implementers can use when testing protocol extensions or other new features. This document reserves some ranges of numbers for experimentation purposes in specific protocols where the need to support experimentation has been identified.
Document record
- Document ID
- RFC3692
- Published
- January 2004
- Authors
- T. Narten
- Status
- BEST CURRENT PRACTICE
- Stream
- IETF
- Area
- —
- Pages
- 7
- Also known as
- BCP82
- Updates:
- RFC 2434
Topics
Related documents
Ranked automatically by shared keywords, IETF area and stream — not by editorial selection.
- RFC 5226Guidelines for Writing an IANA Considerations Section in RFCsObsoleted
May 2008
- RFC 8126Guidelines for Writing an IANA Considerations Section in RFCsUpdated
June 2017
- RFC 3737IANA Guidelines for the Registry of Remote Monitoring (RMON) MIB modulesCurrent
April 2004
- RFC 3575IANA Considerations for RADIUS (Remote Authentication Dial In User Service)Updated
July 2003
- RFC 4021Registration of Mail and MIME Header FieldsUpdated
March 2005
- RFC 2929Domain Name System (DNS) IANA ConsiderationsObsoleted
September 2000
- RFC 4645Initial Language Subtag RegistryCurrent
September 2006
- RFC 2360Guide for Internet Standards WritersCurrent
June 1998
Also filed under
About this page
The document record above — title, authors, date, status, stream, area, relationships, DOI and errata — is imported verbatim from the public RFC Editor index. The “in plain English” section is editorial: written by The metasystema editorial team, not part of the RFC. Where the two differ, the RFC text governs.
Last checked against the RFC Editor index on . RFCs are never revised after publication; changes are issued as new documents.
Data sources · Editorial policy · Report a correction · What is an RFC?