On 12/8/20 6:59 PM, Eric Rescorla wrote:
On Tue, Dec 8, 2020 at 3:49 PM Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx> wrote:
Benjamin, thanks for a very thorough summary of the discussion.
I was thinking about the use of 2119 keywords in the context of draft-ietf-v6ops-cpe-slaac-renum and realizing that there's a subtle but important difference between a BCP that says MUST NOT vs. a protocol specification that says MUST NOT:
In a BCP - MUST NOT presumably means "doing this violates what we consider best current practice".
In a protocol specification - MUST NOT means "a protocol implementation violates the standard if it does this"
Do you have a citation for this distinction? I believe that in both cases this means "you are in violation of RFC XXXX if you do this".Yes, but a BCP really does have a different meaning and scope than a standard protocol specification.
A lot of my concern about draft-ietf-tls-oldversions-deprecate-09 is that it may be taken to mean that implementations MUST NOT permit use of TLS versions < 1.2 even though there are valid reasons for doing so. I think draft-ietf-tls-oldversions-deprecate would be Mostly Harmless if it were clear that it's only making operational recommendations that aren't binding on implementations, and that there may continue to be valid corner cases in which there's a need for implementations to be configurable to use older TLS versions. Perhaps language to this effect could be added in the proposed section 7 or elsewhere.
I would not be in favor of adding this text.I would counter that if the real goal of this document is to constrain implementations, it should be written as a standards-track document, and have been last called as a standards-track document, and to Last Call it as BCP was an error.
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
