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

Mon May 9 23:25:02 CEST 2011

On Mon, May 9, 2011 at 2:21 PM, Ted Mittelstaedt <tedm at ipinc.net> wrote:
> 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.
>

<plonk>

> 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
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>