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..b1f6e3b0
--- /dev/null
+++ b/specs/2024.1/user-visible-information-in-volume-types.rst
@@ -0,0 +1,277 @@
+..
+ 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.
+
+* Please do not delete any of the sections in this template. If you have
+ nothing to say for a whole section, just write: None
+
+* If your specification proposes any changes to the Cinder REST API such
+ as changing parameters which can be returned or accepted, or even
+ the semantics of what happens when a client calls into the API, then
+ you should add the APIImpact flag to the commit message. Specifications with
+ the APIImpact flag can be found with the following query:
+
+ https://review.openstack.org/#/q/status:open+project:openstack/cinder-specs+message:apiimpact,n,z
+
+
+Problem description
+===================
+
+When a non-admin user is creating a volume they would like to see various
+information about the volume type. Some of them are already available
+(e.g. multiattach), while others are either not available at all or not
+available for non-admin users. This is a problem when trying to choose a
+fitting volume type.
+
+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 sould 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,
+those 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. The "properties" field 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 getting unusable, when some 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: "propertied" 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.
+
+
+Data model impact
+-----------------
+
+For 1.a and 3.a 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 defealt 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 a the 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 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.
+
+In general there should be a clear separation of information being set by
+admins versus information being set through OpenStack workflows. 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.
+
+
+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 notification are sent, whenever an encryption_type is created
+or deleted adn thus a new kea-value pair is written into the extra_specs
+database tbale 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
+---------------------
+
+Discuss things that will affect how you deploy and configure OpenStack
+that have not already been mentioned, such as:
+
+There will be no new config options.
+
+The change will come into effect immediately.
+
+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
+----------
+
+Work items or tasks -- break the feature up into the things that need to be
+done to implement it. Those parts might end up being done by different people,
+but we're mostly trying to understand the timeline for implementation.
+
+
+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
+==========
+
+Please add any useful references here. You are not required to have any
+reference. Moreover, this specification should still make sense when your
+references are unavailable. Examples of what you could include are:
+
+* `Mailing list discussion`_
+
+* `Discussion in the Cinde Midcycle`_
\ No newline at end of file