An RFC is an RFC when it is an RFC (Was: Question Re: best practices)
marcelo bagnulo braun
marcelo at it.uc3m.es
Mon May 9 21:08:10 CEST 2011
A brief overview of the IETF RFCs document suite.
The first step for a document in the IETF is an individual Internet Draft.
These documents can be recognized because their name is
These document are the product of one or more individual and they only
represent the consensus among the authors of the document. There is no
review of any kind. We usually call these drafts. These drafts expire
every 6 months and in order to be "alive" they need to be reposted
The second step is usually a working group internet draft. These are
recongized because their name is draft-ietf-wg_name-...
These documents reflect to some degree the WG opinion, but they are work
in progress and can be significantly changed.
Once the WG agrees that a document is ready to move forward, and the
document is reviewed by the IESG and it is open for IETF wide last call
for comments, the document is progressed to RFC.
There are several types of RFCs.
There are some RFCs that are informational, which provide information
for the community.
Other RFCs are Best Current Practices, which document operational best
Other RFCs are Experimental, which document technologies that are still
not mature enough for their deployment in the internet and more
experiment is needed to understnad their impact.
And then there are the Standard Track RFCs. The key word here is Track.
Becoming an Internet standard is a path. The first step is a Proposed
Standard RFC. The second step is a Draft Standard and the third step is
a Full Internet Standard.
Now, RFCs are immutable, so in order for a document to move from
Proposed Standard to Draft standard, a new RFC must be published, with a
So, about the comments received in the ml so far:
- RFC6146 is a Standard Track RFC which status is Proposed Standard.
- RFC2460 is a Standard Track RFC which status is Draft Standard
Other examples of Proposed Standards RFC 3261 (the SIP protocol) RFC
I hope this clarifies a bit the situation.
El 09/05/11 20:15, Cameron Byrne escribió:
> On Mon, May 9, 2011 at 11:05 AM, Ted Mittelstaedt<tedm at ipinc.net> wrote:
>> On 5/9/2011 10:56 AM, Martin Millnert wrote:
>>> On Mon, 2011-05-09 at 10:39 -0700, Ted Mittelstaedt wrote:
>>>> On 5/9/2011 10:13 AM, Jeroen Massar wrote:
>>>>> On 2011-May-09 19:00, Ted Mittelstaedt wrote:
>>>>>> That is a draft, not a real RFC.
>>>>> Ehmmm, from the top of the document:
>>>>> Internet Engineering Task Force (IETF)
>>>>> Request for Comments: 6146
>>>>> Category: Standards Track
>>>>> ISSN: 2070-1721
>>> Ted, you seem to be educating us on three issues:
>>> 1) NAT is bad,
>>> 2) that 6146 is not a standard,
>>> 3) that 6146 is a draft document
>>> re 3: I'm thoroughly confused. To us not involved in BEHAVE or experts
>>> on IETF process, what makes 6146 not be a proposed standard in the
>>> standards track (it does claim so)?
>> Being a draft does not automatically guarentee it will become a standard.
>> Use it at your own risk.
>> As for is NAT bad, well I think so - but I would say the same
>> for any other proposed standard passed off as a real standard
>> regardless if it had to do with NAT or not.
> Soo..... These 2 drafts have the same headers, both are proposed
> standards, there is no difference in their standings from an IETF
> perspective, as far as i know. I am interested in hearing fact based
> pointers on how i should view one as more of a standard than the
>> Ok, there's a link named
>>> "draft-ietf-behave..." on top, but that seems to be the case for other
>>> proposed standards in the standards track by my random testing. The
>>> 'draft' in that link text is the only match of the word 'draft' in the
>>> entire RFC, according to my browser.
>>> On 2: do you mean that the standardization has failed to standardize the
>>> protocols involved/proposed?
>>> Best Regards,
More information about the ipv6-ops