Nut upsdev - Dec 2021 - New Version Notification for draft-rprice-ups-management-protocol-05

The IETF have confirmed that they now have version 05 of the NUT RFC in their 
repository.  This includes changes made following comments by Bart Smit and 
David Zomaya.  The full list of changes can be found in Appendix D.

Roger

---------- Forwarded message ----------
A new version of I-D, draft-rprice-ups-management-protocol-05
has been successfully submitted by Roger Price and posted to the
IETF repository.

Name:		draft-rprice-ups-management-protocol
Revision:	05
Title:		Uninterruptible Power Supply (UPS) Management Protocol -- Commands and
Responses
Document date:	2021-12-28
Group:		Individual Submission
Pages:		61
Html:          
https://www.ietf.org/archive/id/draft-rprice-ups-management-protocol-05.html

Abstract:
    This document describes the command/response protocol currently used
    in the management of Uninterruptible Power Supply (UPS) units and
    other power devices often deployed in small offices, and in IT
    installations subject to an erratic public power supply.  The UPS
    units typically interface to an Attachment Daemon in the system they
    protect.  This daemon is in turn polled by a Management Daemon which
    notifies users and system administrators of power supply incidents,
    and automates system shutdown decisions.  The commands and responses
    described by this document are exchanged between the UPS Attachment
    Daemon and the Management Daemon.  Current practice when this text
    was written risks weak security and this is addressed in the Security
    Considerations sections of this document.

The IETF Secretariat

Section 6.4 needs some work.? I think you need to renumber it as follows:

6.4.1? to 6.4.1.1

6.4.1.1 to 6.4.1.1.1

6.4.1.2 to 6.4.1.1.2

6.4.2 to 6.4.1.2

6.4.3 to 6.4.1.3

6.4.4 to 6.4.1.4


6.4.5 to 6.4.2

The reason this needs to be done is you are saying in 6.4 that UPS 
management "needs to move to a more secure practice in which all traffic 
is encrypted"

In an RFC standards document this wishy hand-waving wording isn't 
allowed, what you are hinting at here is a "MUST" directive but not 
coming out and using the MUST keyword.? That is, what this section is 
proposing is that the final RFC requires encryption - so that programs 
that do NOT implement encryption are NOT fully compliant.

Setting aside for the moment the discussion of whether you agree the RFC 
should require this (I do not BTW) the existing sections are of 2 
flavors - the first flavor is "ways to implement encryption" and the 
second flavor is basically a laundry list of ways to protect traffic in 
a non-encrypted manner.

Section 6.4 is conflating the encryption and non-encryption flavors 
together under a paragraph that says management data MUST be encrypted.? 
This makes no logical sense

Renumbering is a way of separating the encryption/non encryption flavors.

I also propose adding 6.4.1.5 saying the following:

A fifth option would be to incorporate a configuration directive in the 
ups daemon program that would allow the admin to set a list of IP 
addresses that are permitted to send commands to the UPS daemon.? 
Addresses would allow for read-only or read-send configuration 
directives.? This could also be accomplished with less granularity via 
the use of firewall entries on the hosts.


Now as for the 6.4 section, I disagree with making encryption a 
requirement.? Just like SMTP traffic encryption should ALWAYS be an 
option.? The draft RFC swings back and forth on this, and this kind of 
requirement absolutely needs discussion in any case.

I don't believe you are going to get an RFC that mandates encryption for 
interhost communication no matter how much you want it, people have been 
holding their breath turning blue in the face and jumping up and down 
trying to force SMTP to have mandated encryption for years and have not 
gotten their way on it.? So don't even open the door to that.? You can 
satisfy the large corps who want encryption by standardizing encryption 
in the RFC and making it optional and the small orgs and individuals who 
don't need encryption and don't want the bother of it by making it
optional.

Rewrite paragraph 6.4 to say:

UPS management needs to make available optional mechanisms for securing 
host to host communication such as encrypting traffic, blah blah blah.

and rewrite the entire section on security to make it clear that 
encryption of the commands was a SHOULD not a MUST in the RFC. Separate 
all the encryption approaches into their own group, and all the 
non-encryption approaches into their group for clarity.

And DON'T cave into the "encryption everywhere" cult-hood.? I
don't know
if any of them are listening but if so this post is going to be like 
throwing red meat down in front of them so I'll step back and let the 
frenzy start.

Ted

On 12/28/2021 9:27 AM, Roger Price wrote:
> The IETF have confirmed that they now have version 05 of the NUT RFC 
> in their repository.? This includes changes made following comments by 
> Bart Smit and David Zomaya.? The full list of changes can be found in 
> Appendix D.
>
> Roger
>
> ---------- Forwarded message ----------
> A new version of I-D, draft-rprice-ups-management-protocol-05
> has been successfully submitted by Roger Price and posted to the
> IETF repository.
>
> Name:??????? draft-rprice-ups-management-protocol
> Revision:??? 05
> Title:??????? Uninterruptible Power Supply (UPS) Management Protocol 
> -- Commands and Responses
> Document date:??? 2021-12-28
> Group:??????? Individual Submission
> Pages:??????? 61
> Html: 
>
https://www.ietf.org/archive/id/draft-rprice-ups-management-protocol-05.html
>
> Abstract:
> ?? This document describes the command/response protocol currently used
> ?? in the management of Uninterruptible Power Supply (UPS) units and
> ?? other power devices often deployed in small offices, and in IT
> ?? installations subject to an erratic public power supply.? The UPS
> ?? units typically interface to an Attachment Daemon in the system they
> ?? protect.? This daemon is in turn polled by a Management Daemon which
> ?? notifies users and system administrators of power supply incidents,
> ?? and automates system shutdown decisions.? The commands and responses
> ?? described by this document are exchanged between the UPS Attachment
> ?? Daemon and the Management Daemon.? Current practice when this text
> ?? was written risks weak security and this is addressed in the Security
> ?? Considerations sections of this document.
>
> The IETF Secretariat
>
>
>
> _______________________________________________
> Nut-upsdev mailing list
> Nut-upsdev at alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20211228/9c0bb1fd/attachment-0001.htm>