diff --git a/notes.md b/notes.md
index da07c240..99d4a724 100644
--- a/notes.md
+++ b/notes.md
@@ -675,13 +675,17 @@ Country codes are the [@!BCP47] two-letter region subtag, without the UK excepti
 
 # Encryption
 
-Encryption in Matroska is designed in a very generic style to allow people to
-implement whatever form of encryption is best for them. It is possible to use the
-encryption framework in Matroska as a type of DRM (Digital Rights Management).
-
-This document does not specify any kind of standard for encrypting elements.
-The issue of key scheduling, authorisation, and authentication are out of scope.
-External entities have used these elements in proprietary ways.
+This Matroska specification provides no interoperable solution for securing the
+data container with any assurances of confidentiality, integrity, authenticity,
+or to provide authorization. The `ContentEncryption Element` ((#contentencryption-element))
+and associated sub-fields ((#contentencalgo-element) to (#aessettingsciphermode-element)) are defined
+only for the benefit of implementers to construct their own proprietary solution
+or as the basis for further standardization activities.  How to use these
+fields to secure a Matroska data container is out of scope, as are any related
+issues such as key management and distribution.
+
+A `Matroska Reader` who encounters containers that use the fields defined in this
+section **MUST** rely on out-of-scope guidance to decode the associated content.
 
 Because encryption occurs within the `Block Element`, it is possible to manipulate
 encrypted streams without decrypting them. The streams could potentially be copied,
@@ -696,12 +700,22 @@ Encryption information is stored in the `ContentEncodings Element` under the `Co
 For encryption systems sharing public/private keys, the creation of the keys and the exchange of keys
 are not covered by this document. They have to be handled by the system using Matroska.
 
+The algorithms described in (#ContentEncAlgoValues) support
+different modes of operations and key sizes.  The specification of these
+parameters is required for a complete solution, but is out of scope of this
+document and left to the proprietary implementations using them or subsequent
+profiles of this document.
+
 The `ContentEncodingScope Element` gives an idea of which part of the track are encrypted.
 But each `ContentEncAlgo Element` and its sub elements like `AESSettingsCipherMode` really
 define how the encrypted should be exactly interpreted.
 
-The AES-CTR system, which corresponds to `ContentEncAlgo` = 5 ((#contentencalgo-element)) and `AESSettingsCipherMode` = 1 ((#aessettingsciphermode-element)),
-is defined in the [@?WebM-Enc] document.
+An example of an extension that builds upon these security-related fields in this specification is [@?WebM-Enc].
+It uses AES-CTR, `ContentEncAlgo` = 5 ((#contentencalgo-element)) and `AESSettingsCipherMode` = 1 ((#aessettingsciphermode-element)).
+
+A `Matroska Writer` **MUST NOT** use insecure cryptographic algorithms to create new
+archives or streams, but a `Matroska Reader` **MAY** support these algorithms to read
+previously made archives or stream.
 
 # Image Presentation