[Nut-upsdev] NUT RFC: Disposition of comments by David Zomaya

Roger Price roger at rogerprice.org
Tue Dec 28 17:23:00 GMT 2021

Hello David, thanks for the close reading.

I propose the following disposition of your comments. Note that resolution of 
the Section 4.3.2 comment probably requires discussion in the mailing list.

Thanks again for your comments, Roger

Section 2.8

> "Data lead" may be confusing. Suggest replacing "the system to which the data 
> lead is connected is known as the primary" with something more explicit such 
> as "the system which communicates directly with the UPS unit (e.g. using a 
> USB, RS232, or network connection) is known as the primary"

Section 3

> In Figure 4: UPS protects multiple systems "but if the UPS had status "OB" the 
> Secondary shuts down." Should there be additional text that the OB shutdown 
> depends on the configuration? i.e. while the default case may be to shut down, 
> it is a configurable setting.

The note below figure 4 says « but if the UPS had status OB the Secondary shuts 
down. » This is the current behaviour built into NUT's upsmon.  The NUT RFC 
follows upsd and upsmon closely, but clearly a different Management Daemon could 
do something different.

I propose changing the text to « but if the UPS had status OB the Secondary 
may choose to shut down as a precaution. »
Section 4.2.1

> Suggest replacing "trio" with "3" or "three" for simplicity

Done.  Replaced "a trio of" by "three".
Section 4.2.3

> Suggest dropping "high-level" from " In current practice, commands such as 
> "FSD" are made available only to a high-level administrative user (2.2)" to 
> match other references to the administrative user

Done. The sentence now reads « In current practice, commands such as FSD are 
made available only to a privileged administrative user (2.2) authorized to send 
such a mission critical command. »
Section 4.2.7

> Suggest changing "then go off and wait for the response" to "wait"

Section 4.2.3

> Can we add what "FSD" is an acronynm for (Forced ShutDown)? E.g. reword 1st 
> line to "A Management Daemon (2.6) which is Primary (2.8) and has the required 
> authority, uses this command to set status symbol "FSD" (forced shutdown) in 
> the Attachment Daemon (2.1)." Related: FSD is spelled out as "Forced ShutDown" 
> in 6.5.1 and "Forced Shut Down" in 5.1. Should be consistent throughout

Done. Replaced « uses this command to set status symbol FSD in the Attachment 
Daemon. » to « uses this command to set status symbol FSD meaning "Forced 
Shutdown" in the Attachment Daemon. ».

Spell out FSD as "Forced Shutdown". 
Section 4.3.2. Error Responses

> There are security implications to returning INVALID-USERNAME and 
> INVALID-PASSWORD discretely, do we need to be concerned with these? If yes, 
> maybe we should combine them into INVALID-CREDENTIALS? Some general discussion 
> on the topic here: 
> https://security.stackexchange.com/questions/17816/username-and-or-password-invalid-why-do-websites-show-this-kind-of-message-i

This would be a design change rather than an editorial matter.  It would be 
better to raise the matter for discussion in the mailing list. 
Section 5.1

> The term "public supply" is used four times. I understand this means 
> utility/wall power/where the UPS is plugged in. I would suggest something like 
> "input power source", "input" "utility", "utility power", or "wall power" as 
> more common/easy to understand. For reference, the HID PDC spec 
> (https://www.usb.org/sites/default/files/pdcv11.pdf) uses "input source 
> power", "Input", and "utility" (probably best to pick just 1).

> Note that "wall power" is used elsewhere in the RFC draft and we should 
> change/leave it alone as needed based on any changes here

I propose using "input power supply".  I have reviewed section 5.1 and made 
7 changes.  I added a sentence to section 1.1 How to Read this Document.

> Regarding: " Note: "OB" does not imply "DISCHRG" if the battery is floating." 
> Is there a specific UPS feature or scenario driving this note? Generally, if 
> the UPS is operating off the battery, it is discharging it.

I propose removing to remove the notes from CHRG and DISCHRG.

> Suggest removing "is offline," from the OB definition to avoid confusion 
> between "offline" and the various definitions of OFF from different UPS 
> topologies and models

Section 5.2

> Suggest changing "deduces" to "detects"

Ok, done.
Appendix A

> Suggest replacing "domestic" with "consumer-grade" to avoid confusion around 
> the term "domestic" being used as the opposite of "international".

Appendix B

> In Step 7, is the description of the outlets only shutting off correct in the 
> common case? Many UPSes do not offer outlet control and if they are on 
> battery, a shutdown command will eventually lead to them shutting off.

This is a delicate matter.  Back in the ISO we saw the difference between 
Informative Annexes and Normative Annexes, but the entire current NUT RFC is 
"Informative" only.  However it is realistic to expect that one day the text 
will be run through the formal IETF Standards Track process and will become 
normative, so it is important to say now that Appendix B is a "helpful 
introduction" and no more.

I intended Appendix B to give new-comers an introduction to the subject, not to 
be a definitive statement of what "shutdown" of a UPS means for every model.  I 
choose the case in which the outlets are disconnected with an audible signal 
that a new-comer can hear.  In the past this has helped in mailing list 

I will add words to say that the audible outlet disconnection is only an 
example, and that other UPS units may behave differently.  However the common 
point is that the outlets are no longer powered.  See Appendix D for details.

End of resolution of comments.

More information about the Nut-upsdev mailing list