<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Section 6.4 needs some work. I think you need to renumber it as
follows:</p>
<p>6.4.1 to 6.4.1.1</p>
<p>6.4.1.1 to 6.4.1.1.1</p>
<p>6.4.1.2 to 6.4.1.1.2</p>
<p>6.4.2 to 6.4.1.2</p>
<p>6.4.3 to 6.4.1.3</p>
<p>6.4.4 to 6.4.1.4</p>
<p><br>
</p>
<p>6.4.5 to 6.4.2</p>
<p>The reason this needs to be done is you are saying in 6.4 that
UPS management "<span style="color: rgb(34, 34, 34); font-family:
"Noto Sans", Arial, Helvetica, sans-serif; font-size:
14px; font-style: normal; font-variant-ligatures: normal;
font-variant-caps: normal; font-weight: 400; letter-spacing:
normal; orphans: 2; text-align: left; text-indent: 0px;
text-transform: none; white-space: normal; widows: 2;
word-spacing: 0px; -webkit-text-stroke-width: 0px;
background-color: rgb(255, 255, 255); text-decoration-thickness:
initial; text-decoration-style: initial; text-decoration-color:
initial; display: inline !important; float: none;">needs to move
to a more secure practice in which all traffic is encrypted"</span></p>
<p>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.</p>
<p>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.</p>
<p>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 <br>
</p>
<p>Renumbering is a way of separating the encryption/non encryption
flavors.</p>
<p>I also propose adding 6.4.1.5 saying the following:<br>
</p>
<p>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.</p>
<p><br>
</p>
<p>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.</p>
<p>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.<br>
</p>
<p>Rewrite paragraph 6.4 to say:</p>
<p><span style="color: rgb(34, 34, 34); font-family: "Noto
Sans", Arial, Helvetica, sans-serif; font-size: 14px;
font-style: normal; font-variant-ligatures: normal;
font-variant-caps: normal; font-weight: 400; letter-spacing:
normal; orphans: 2; text-align: left; text-indent: 0px;
text-transform: none; white-space: normal; widows: 2;
word-spacing: 0px; -webkit-text-stroke-width: 0px;
background-color: rgb(255, 255, 255); text-decoration-thickness:
initial; text-decoration-style: initial; text-decoration-color:
initial; display: inline !important; float: none;">UPS
management needs to make available optional mechanisms for
securing host to host communication such as encrypting traffic,
blah blah blah.</span></p>
<p>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.</p>
<p>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.<br>
</p>
<p>Ted<br>
</p>
<div class="moz-cite-prefix">On 12/28/2021 9:27 AM, Roger Price
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:alpine.DEB.2.20.2112281823420.4867@maria.rogerprice.org">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.
<br>
<br>
Roger
<br>
<br>
---------- Forwarded message ----------
<br>
A new version of I-D, draft-rprice-ups-management-protocol-05
<br>
has been successfully submitted by Roger Price and posted to the
<br>
IETF repository.
<br>
<br>
Name: draft-rprice-ups-management-protocol
<br>
Revision: 05
<br>
Title: Uninterruptible Power Supply (UPS) Management
Protocol -- Commands and Responses
<br>
Document date: 2021-12-28
<br>
Group: Individual Submission
<br>
Pages: 61
<br>
Html:
<a class="moz-txt-link-freetext" href="https://www.ietf.org/archive/id/draft-rprice-ups-management-protocol-05.html">https://www.ietf.org/archive/id/draft-rprice-ups-management-protocol-05.html</a><br>
<br>
Abstract:
<br>
This document describes the command/response protocol currently
used
<br>
in the management of Uninterruptible Power Supply (UPS) units
and
<br>
other power devices often deployed in small offices, and in IT
<br>
installations subject to an erratic public power supply. The
UPS
<br>
units typically interface to an Attachment Daemon in the system
they
<br>
protect. This daemon is in turn polled by a Management Daemon
which
<br>
notifies users and system administrators of power supply
incidents,
<br>
and automates system shutdown decisions. The commands and
responses
<br>
described by this document are exchanged between the UPS
Attachment
<br>
Daemon and the Management Daemon. Current practice when this
text
<br>
was written risks weak security and this is addressed in the
Security
<br>
Considerations sections of this document.
<br>
<br>
The IETF Secretariat
<br>
<br>
<br>
<br>
_______________________________________________
<br>
Nut-upsdev mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:Nut-upsdev@alioth-lists.debian.net">Nut-upsdev@alioth-lists.debian.net</a>
<br>
<a class="moz-txt-link-freetext" href="https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev">https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev</a>
<br>
</blockquote>
</body>
</html>