diff --git a/specs/2024.1/user-visible-information-in-volume-types.rst b/specs/2024.1/user-visible-information-in-volume-types.rst
new file mode 100644
index 00000000..44accbb9
--- /dev/null
+++ b/specs/2024.1/user-visible-information-in-volume-types.rst
@@ -0,0 +1,266 @@
+..
+ This work is licensed under a Creative Commons Attribution 3.0 Unported
+ License.
+
+ http://creativecommons.org/licenses/by/3.0/legalcode
+
+========================================
+User visible information in volume types
+========================================
+
+https://blueprints.launchpad.net/cinder/+spec/user-visible-information-in-volume-types
+
+Volume types are used to find a fitting backend when creating a volume. But
+they also imply a few configurations to the volume to be created, that are
+good to know for anyone who has to choose from various volume types.
+
+Problem description
+===================
+
+When a non-admin user is creating a volume they would like to see various
+information about the volume type. Some of those information are already
+visible for users, when looking into a volume type (e.g. multiattach). Other
+information are either not available at all or not visible for non-admin
+users. This is a problem when trying to choose a fitting volume type when
+creating a volume.
+
+Use Cases
+=========
+
+The information users would like to see are first and foremost:
+1. Whether a volume type can be used to create encrypted volumes
+2. Whether a volume type creates replicated volumes, either through Cinder or
+through a configured backend like ceph
+
+The first information comes from the encryption type within the volume, which
+is only accessible for an admin. The second information can either be set and
+directly seen in the volume type extra_specs or is indirectly a part of the
+configuration of the backend.
+
+There might be more use cases, that should benefit from a solution allowing
+an admin to add certain user facing information into the volume type in a
+uniform way.
+
+As there are more and more tools that automatically create IaaS resources,
+that information should be accessible in a uniform way and could best be used
+to filter for fitting volume types in the client.
+
+Proposed change
+===============
+
+Here are a few ways to solve this problem.
+
+Alternatives
+------------
+
+1. Using the already existing user facing "properties" field. Administrators
+can already set key,value pairs here and user visible extra_specs can be
+seen in this field. This would lead to a problem in the volume scheduler,
+as EVERY input is going into the extra_specs table and the scheduler will
+try to fulfill every key=value pair a volume type requests when looking for
+a fitting backend for the volume.
+1.a) This could be solved in creating a whitelist or blacklist, so not every
+extra_spec is checked in the scheduler. Either all only informational
+extra_specs should be ignored or a list of extra_specs, that will be checked
+could be created.
+1.b) Another option would be to create another database table: metadata and
+put every key=value pair in there at the time of their creation, that should
+not be used in the scheduling process. This would also need a whitelist or
+blacklist to decide in the API, where to put the information.
+The "properties" field of the volume type would then be build in the API from
+a merge of the extra_specs and the metadata table. (This may also prevent the
+volume type from becoming unusable, when someone adds a key=value pair to the
+"properties", that is not meant for the scheduler - right now this would break
+the volume creation process)
+
+2. Creating a new "metadata" field, that will contain such user facing
+information. This would include API changes to address the new view of the
+volume type as well as a new API endpoint to set information as key value
+pairs for this metadata field. A new database table for those metadata is
+also necessary. The downside on this is, it might confuse people, as user
+facing information would be in two different fields: "properties" for
+multiattach, replication_enabled and AZ, but "metadata" for some things
+like encryption_enabled and backend_replication, etc... It would also not
+solve the problem, that key-value pairs not meant for scheduling purposes
+can still be put into the properties/extra_specs and will only lead to
+Errors in the scheduling process later on.
+
+3. Facing use cases individually:
+3.a) Information about whether a volume type creates encrypted volumes or not
+could be calculated in the API calls for list/show volume types from the
+presence of an encryption type. The information would be shown in the
+"properties" field. This would be a very minimal patch, but will not solve
+other use cases, that would benefit from user facing information.
+3.b) Creating an extra field for the encryption in the volume type table, that
+is automatically set when creating or deleting an encryption type. This
+would need a database change and a change of the view of the volume_types.
+3.c) Looking into the different drivers and how they handle internal
+configurable replication and whether there are ways to let OpenStack know
+this and propagate it to users. This is very hard to achieve, maybe even
+impossible without input from an operator, who configured the backends and
+volume types.
+3.d)The policy for the encryption type could be loosend to let users see not
+only whether a volume type has an encryption type, but also what algorithm
+and provider is used for it. This may have a security impact.
+
+All the options under 3 are not able to solve the general issue of having a
+reliable way to provide user visible information in volume types. Neither will
+they solve the problem, that operators are able to add key-value pairs not
+meant for scheduling purposes to the volume type extra specs.
+
+
+Data model impact
+-----------------
+
+For 1.a, 3.a and 3.d there are no changes to the data model.
+
+For 1.b and 2. it would be necessary to create a new table `metadata` that
+works like the `extra_specs` table. As there are currently no user visible
+information in volume types in place, an initially empty table would be
+sufficient.
+
+For 3.b the volume type table would need to get a new column: `encryption_set`
+with a boolean option. This could default to false but has to be set to true
+for every volume type that has an associated encryption type.
+
+For 3.c it is not yet clear what changes need to be done.
+
+Additionally for 1.a, 1.b, 2 and 3.b in case of an upgrade from a previous
+OpenStack version, all volume types need to be checked and for volume types
+with associated encryption types, there need to be an encryption parameter
+set in the database according to the chosen option.
+
+REST API impact
+---------------
+
+Each API method which is either added or changed should have the following
+
+For 1.a and 1.b there would only be minor changes in already existing API
+calls such as creating a new key-value pair and writing it to the database
+when creating an encryption type.
+
+For 1.b and 3.a the list and show calls for the volume type would get an
+update to mix in either the metadata table or the encryption type into
+the `properties` field.
+
+For 3.b there would be an update to the view of the volume type, as an
+additional field is created and shown.
+
+For 2 a new field needs to be added to the view of volume types.
+For that field new API calls will be needed:
+- a POST method to set new key-value pairs
+- a DELETE method to delete a key-value pair.
+These new calls should behave the same way as for the volume type extra specs.
+
+For 3.c it is not yet clear what changes need to be done.
+
+For 3.d there is only one policy check, that is not executed anymore.
+
+In general there should be a clear separation of information being set by
+admins versus information being set through OpenStack workflows. The latter
+should not be setable via `openstack volume type set`. Instead a 403 Error
+should be presented.
+
+
+Security impact
+---------------
+
+This change will expose a boolean value, that shows, whether a volume type
+will encrypt volumes at creation or not.
+
+In case of 3.d this will also expose all information of the encryption type.
+
+
+Active/Active HA impact
+-----------------------
+
+There should not be any impact upon Cinder's Active/Active HA support.
+
+
+Notifications impact
+--------------------
+
+There might be additional notifications when database entries are made or
+removed. They will behave the same way as the notifications of extra_specs.
+Those will be sent, whenever an encryption_type is created or deleted and thus
+a new key-value pair is written into the extra_specs database table or in
+general when a key-value pair is added to a possible new metadata DB table.
+
+Other end user impact
+---------------------
+
+This change may lead to users wanting to use the filtering mechanism in
+`openstack volume type list --property key=value` for both explained use
+cases.
+
+Performance Impact
+------------------
+
+The changes would lead to one additional database call, when creating or
+deleting an encryption type: then there will also be a key-value pair written
+to the database either into the `extra_specs` or a potentially new `metadata`
+table.
+
+In the case of the creation of a new database table, the API call for getting
+volume types and their details need to be adjusted or to get an additional
+query for the new metadata table.
+
+Other deployer impact
+---------------------
+
+Old volume types with associated encryption types will need to have the
+potentially new database entry set. This cannot be done via `volume type set`
+command, but has to be written into the database either manually or with a
+script, that sets the correct entry for all affected volume types.
+
+Developer impact
+----------------
+
+For 1.a this will change the workflow of the cinder scheduler. Developers
+cannot assume anymore that all entries to the `extra_specs` will be checked
+in the scheduler.
+
+
+Implementation
+==============
+
+Assignee(s)
+-----------
+
+Primary assignee:
+ Josephine Seifert (josei)
+
+Other contributors:
+ None
+
+Work Items
+----------
+
+TBD when one of the options is chosen.
+
+
+Dependencies
+============
+
+There are no dependencies.
+
+Testing
+=======
+
+Testing will depend on the chosen option. Some of them will only need unit
+testing, while others should have at least one tempest test that checks new
+API endpoints.
+
+Documentation Impact
+====================
+
+There might be a documentation needed to separate between the extra specs
+and the handling of user visible information. It depends on the chosen option.
+
+
+References
+==========
+
+* `Mailing list discussion `_
+
+* `Discussion in the Cinder Midcycle `_