Re: [TLS] [Editorial Errata Reported] RFC5246 (3191)

This errata should be rejected because it is not an errata, it is an objection to the IETF process (how one RFC obsoletes another). It is definitely an interesting process question, but not one that should be dealt with through the errata process.

On Apr 12, 2012, at 12:38 PM, RFC Errata System wrote:

> 
> The following errata report has been submitted for RFC5246,
> "The Transport Layer Security (TLS) Protocol Version 1.2".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=5246&eid=3191
> 
> --------------------------------------
> Type: Editorial
> Reported by: Martin Rex <mrex@sap.com>
> 
> Section: Meta-Data
> 
> Original Text
> -------------
> Obsoletes: 3268, 4346, 4366
> Updates: 4492
> 
> Corrected Text
> --------------
> Updates: 4492
> 
> Notes
> -----
> "Obsoletes: 4366" is factually incorrect, because it is impossible to implement TLSv1.1 (rfc4346) or TLSv1.0(rfc2246) from the TLSv1.2 spec alone. (IPv6 does not obsolete IPv4 and HTTP/1.1 does not obsolete HTTP/1.0 either).
> 
> "Obsoletes: 4366" is factually incorrect, because some of the TLS extensions defined in rfc4366 do NOT appear in rfc5246 (and were updated by rfc6066).  On top of that, in order to implement TLS extensions for TLSv1.0 or TLSv1.1, rfc4366 is indispensible, because it describes the necessary changes to the TLSv1.0 & TLSv1.1 PDUs, information that would be cumbersome to extract from rfc5246 compared to simply using rfc4366.
> 
> "Obsoletes: 3268" is factually incorrect, because 3268 is the document needed to implement the AES ciphersuites in implementations of TLS _prior_ to TLSv1.2,
> such as TLSv1.0(rfc2246) and TLSv1.1(rfc4346), i.e. to add support for AES ciphersuites to an existing implementation of TLSv1.0, one would use TLSv1.0(rfc2246) plus rfc3268, rather than TLSv1.0 plus some undefined fragments of rfc5246.
> 
> Instructions:
> -------------
> This errata is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary. 
> 
> --------------------------------------
> RFC5246 (draft-ietf-tls-rfc4346-bis-10)
> --------------------------------------
> Title               : The Transport Layer Security (TLS) Protocol Version 1.2
> Publication Date    : August 2008
> Author(s)           : T. Dierks, E. Rescorla
> Category            : PROPOSED STANDARD
> Source              : Transport Layer Security
> Area                : Security
> Stream              : IETF
> Verifying Party     : IESG
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls