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 <resea...@bensmyth.com> 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@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Reply via email to