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

[Ted Mittelstaedt]

On 5/9/2011 1:06 PM, Cameron Byrne wrote:
> On Mon, May 9, 2011 at 1:00 PM, Ted Mittelstaedt<tedm at ipinc.net>  wrote:
>> On 5/9/2011 11:15 AM, Cameron Byrne wrote:
>>>
>>> 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:
>>>>>>>
>>>>>>> http://tools.ietf.org/html/rfc6146
>>>>>>>
>>>>>>> 8<=============================================
>>>>>>> Internet Engineering Task Force (IETF)
>>>>>>> Request for Comments: 6146
>>>>>>> Category: Standards Track
>>>>>>> ISSN: 2070-1721
>>>>>>> =============================================>8
>>>>>>>
>>>>>
>>>>> 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.
>>>>
>>>> Ted
>>>>
>>>
>>>
>>> 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
>>> other.
>>>
>>> http://www.ietf.org/rfc/rfc6146.txt
>>
>> Well, first of all 6146 isn't the problem the OP was talking about.
>>
>>> http://www.ietf.org/rfc/rfc2460.txt
>>
>> rfc2460 is a draft standard that has been replaced by proposed standards
>> as shown here:
>>
>> http://www.rfc-editor.org/info/rfc2460
>>
>> So, no, 2460 is not the same as 6146
>>
>> Now, as for proposed standards vs standards, I'll refer here:
>>
>>>
>>
>>  From http://www.rfc-editor.org/rfc/rfc2026.txt
>>
>>
>> 4.1.3  Internet Standard
>>
>>    A specification for which significant implementation and successful
>>    operational experience has been obtained may be elevated to the
>>    Internet Standard level
>>
>> The simple fact of the matter is that IPv6 has NOT been significantly
>> implemented on the Internet.  Until that happens it will NOT be possible
>> for it to meet the requirements of standardization.
>>
>> Your argument is essentially saying that since IPv6 standardization isn't
>> fixed in stone, that it is OK to deploy all sorts of solutions
>> such as NAT over IPv6 that aren't fixed in stone either.
>>
>> But this argument is disingenuous.
>>
>> You may note one of the requirements to be advanced to Draft
>> standard:
>>
>> 4.1.2  Draft Standard
>>
>>    A specification from which at least two independent and interoperable
>>    implementations from different code bases have been developed, and
>>    for which sufficient successful operational experience has been
>>    obtained, may be elevated to the "Draft Standard" level.
>>
>> pray tell where are the independent implementations from different code
>> bases?
>>
>> Can you provide URL's?
>>
>
> http://www.a10networks.com/products/axseries-NAT64_DNS64.php
>
> http://www.brocade.com/solutions-technology/enterprise/application-delivery/seamless-transition-to-ipv6/index.page
>
> http://www.cisco.com/en/US/docs/ios/ios_xe/ipaddr/configuration/guide/iad_stateless_nat64_xe.html
>
> http://www.juniper.net/techpubs/en_US/junos10.4/information-products/topic-collections/nce/nat64-ipv6-ipv4-depletion/configuring-nat64-ipv6-ipv4-depletion.pdf
>
> http://ecdysis.viagenie.ca/
>

Because those are proprietary we really have no way, short of signing an
NDA, of knowing if they really are independent.

For all anyone knows, every one of those commercial customers could
have signed an agreement with the guy running the ecdysis website.  I
have wondered about that since the code on his site does not run on
FreeBSD, and normally an OpenBSD to FreeBSD port is child's play -
to me that indicates a lot of deep mucking around in the kernel.  It's
not a very portable implementation unless he wrote it to be portable
and clearly he didn't.  And last I checked it was an old version of
Linux, too.

For example just about all the small routers (Linksys, Netgear) use the
same code base. (Linux kernel)

> There are others as well...
>

Post them.  I would like to see multiple open source implementations
that are buildible on current OSes.  I think that is far more in the
spirit of openness that the RFC system is built on.

I have nothing against commercial companies but we have had several
very ugly incidents in the past of companies patenting
aspects of stuff they got inserted in the RFC process, and got
standardized.  That is why multiple open source implementations are
critical for anything like this.  Many such exist for IPv6 stacks,
incidentally.

Ted



> Cameron
>> Ted
>>
>>
>>> Cameron
>>>
>>>>   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,
>>>>> Martin
>>>>>
>>>>
>>>>
>>>
>>
>>
>