An RFC is an RFC when it is an RFC (Was: Question Re: best practices)

[Ted Mittelstaedt]

On 5/9/2011 2:07 PM, Ole Troan wrote:
> Ted,
>
>> rfc2460 is a draft standard that has been replaced by proposed
>> standards as shown here:
>
> incorrect.


http://www.rfc-editor.org/info/rfc2460

Status:
DRAFT STANDARD
Obsoletes:
RFC 1883
Updated by:
RFC 5095, RFC 5722, RFC 5871

You are correct that "replaced by" is not exactly accurate.  More
accurate would be "part of it replaced by" proposed standards.

We may see more and more parts of this replaced by proposed
standards.  The IETF may not ever wish to standardize IPv6 in
one single chunk, they may feel it more politically expedient to
standardize a bunch of chunks of it.

But since so many different implementations of IPv6 now exist and
are out in the wild, that follow RFC2460, compared to so few of
NAT64, (save proprietary commercial ones, which all may be the same
code) it is still rather absurd to equate the two.

> please don't spread misinformation. there are a number of different
> standards level RFCs. for the ones we are talking about here on the
> 'standards track'. when something is first standardised it is a
> "Proposed standard" (6146), then if it has been shown to work, and
> there is enough interest to do the process work of moving it onwards
> it will be come "Draft standard" (2460), then the next step, and
> almost no standard ever makes it this far is full standard. there
> appears to be about 70 of these
> (http://www.rfc-editor.org/categories/rfc-standard.html).
>

OK your making the argument now that a RFC standard is the same
thing as a Draft RFC Standard, based on the fact that the IETF
has not approved many standards.

But to accept that argument basically means your saying the IETF RFC
standards process is broken - that it's incapable of producing
standards that anyone will adhere to, so they settle for "Draft 
Standard" as a politically expedient result as it allows vendors
to worm their way out of supporting older code that might not be
compliant.

But if that is the case then why drag the RFC's in to the discussion
in the first place?

> what exactly the RFC status of a technology has to do in this debate
> I'm unclear on though.

The first responders to the OP's question apparently could
not resist dragging in RFC numbers rather than (as Cameron eventually
did, after my prodding) simply produce a list of NAT64 vendor 
implementations that the OP could use.  Thus, the status of the RFC
became relevant.

I would say that the OP got his answer plus a list of places to go
spend his money, so I would mark this thread off as successful.

Ted

> so apologies for butting in.
>
> cheers, Ole
>
>
>
>