On 12/8/2020 9:23 PM, John C Klensin wrote:
I believe that there has been a increasing tendency in recent years to use the BCP category for documents that, if 2026 were taken seriously, would be required to be ordinary Technical Specification or Applicability Statement documents. My reading of 2026 (including the paragraphs quoted by ekr) as well as the distinction I think you are making is that a BCP should never be used to alter the technical content of a standards track document. If we have a document, RFC NNNN that says "you MUST do this in so-and-so way", then a BCP that says "regardless of what RFC NNNN says, the best practice is to do it is this other way". That would (and, IMO, has) put us in the rather odd position of defining something as a Standard (even if only a "Proposed" one) and then turning around and saying "don't take our standards seriously". IMO, not good.
We could look at process, or we could look at technology. Take for example one of the updated RFC, 3856, "A Presence Event Package for the Session Initiation Protocol (SIP)". The text says that it basically uses TLS to secure the connection. Changing the version of TLS has no functional impact on the specification, which relies only on version-independent properties of TLS such as confidentiality and authentication. The text only mentions a "version" of TLS through its references to RFC 2246, TLS 1.0, which was the version of TLS current at the time. Yes, the authors of that RFC did not write "TLS 1.0 or a later version". Had they done that, there would be no process issue. And I think that if we want a narrow process decision, we should start there: applications should anticipate that security requirements will change over time, and say something like "current version of TLS [RFC XXXX] or later."
-- Christian Huitema
