Having risk management experience as well as policy establishment and enforcement, I would rather see the clear notification that something is not secure. Then the organization makes the decision to take that risk based on likelihood/impact considerations. This factors in risk tolerance and business objectives. I am an author on the draft, and don’t think this is the place for those business decisions to be made. Best regards, Kathleen Sent from my mobile device > On Dec 1, 2020, at 12:52 AM, Ben Smyth <research@xxxxxxxxxxxx> wrote: > > > I haven't followed all the nuances of this discussion, but it seems to boil down to use of "MUST NOT" when certain "EXCEPTIONS MAY" exist for private enterprise running legacy kit, which makes decision makers anxious, since they don't want responsibility for something they "MUST NOT" do: A solution might be to introduce "MUST NOT...EXCEPTIONS MAY" language, thereby allowing sectors to define their standards/principles/expectations. > _______________________________________________ > TLS mailing list > TLS@xxxxxxxx > https://www.ietf.org/mailman/listinfo/tls -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
