<div dir="ltr"><div>Cheers fellow NUT developers,</div><div><br></div><div>  Several recent discussions touched on discrepancies between the factual NUT networked protocol and the requirements of <a href="https://www.rfc-editor.org/info/rfc9271/#section-4.2.1" rel="nofollow">RFC 9271</a> - in particular, the different naming of certain commands and responses. Subsequently I've posted an issue to track ideas and development around this - feel free to chime in, especially with ideas about keeping the solution backwards compatible for older NUT and third-party clients conformant to the protocol definition of their day: <a href="https://github.com/networkupstools/nut/issues/3637">https://github.com/networkupstools/nut/issues/3637</a></div><div><br></div><div>  As a heads-up, another noted discrepancy is that RFC-compliant communications may not be anonymous. And the RFC review had questions about the use of plaintext protocol connections, so we assured them we have in-dialog STARTTLS or add-on stunnel etc. ability to protect the monitoring/management traffic... So eventually NUT would grow (initially optional, later default that can be reverted) settings to reject any unauthenticated traffic for queries and other commands - even for the likes of upsc client or common monitoring frameworks. More details on that in <a href="https://github.com/networkupstools/nut/issues/3411">https://github.com/networkupstools/nut/issues/3411</a> - and since PR <a href="https://github.com/networkupstools/nut/pull/3435">https://github.com/networkupstools/nut/pull/3435</a> we can easily pass SSL details and login credentials to clients using a common configuration file. Further work done in PR <a href="https://github.com/networkupstools/nut/pull/3607">https://github.com/networkupstools/nut/pull/3607</a> aimed to close the gap for clients with multiple connections like upsmon, upslog and upsstats.cgi to be able to talk with SSL/TLS servers managed by different CA realms (different SSL contexts in OpenSSL terms). Generally speaking, the SSL/TLS support should be working and easily (*the best we can manage) configurable across the board as most of the points in epic <a href="https://github.com/networkupstools/nut/issues/3329">https://github.com/networkupstools/nut/issues/3329</a> are already ticked.</div><div><br></div><div>Hope this helps,</div><div>Jim Klimov</div><div><br></div></div>