sysfs tls_configured_key naming?

[Sagi Grimberg]

On 17/10/2024 15:13, Hannes Reinecke wrote:
> On 10/17/24 12:54, Daniel Wagner wrote:
>> f5eb7397471b ("nvme-sysfs: add 'tls_configured_key' sysfs attribute")
>> claims that the --tls_key is expecting a 'Configured PSK'. That is not
>> correct. It expects a 'Derived TLS PSK'. That means user space has to do
>> the whole key transformation as described in Figure 21: {TLS PSK, TLS
>> Identity, Hash} Tuple Derivation in TCP Transport Specification,
>> Revision 1.1.
>>
> Not necessarily. The spec indicates two methods:
>
> > Each NVMe/TCP entity shall support:
> > * transforming the configured PSK into a retained PSK before it is
> >   stored by the NVMe/TCP entity for repeated use with another
> >   NVMe/TCP entity; and
> > * using the configured PSK as a retained PSK.
>
>>  From a quick look at the concatenation patches and based on the spec,
>> tls_configured_key will never hold the 'Configured PSK'. I think we
>> should use a better name for this sysfs attribute. I suppose it should
>> be named 'tls_generated_psk'?
>>
> No. The 'generated' PSK (in the current wording of the TLS concatenation
> patches) is the PSK generated internally during TLS concatenation.
> And, curiously, the only one which will _never_ be presented in the
> 'tls_configured_key' attribute.

FWIW, I don't like the tls_configured_key notation either. But I don't have
a better name.