[Nut-upsdev] [EXTERNAL] Re: NUT RFC progress

[David Zomaya]

> Could you please submit your comments, suggestions, text, recommendations, ideas, ... to this list.  I will pick up comments which I have received privately and introduce them to the list.

Pasting below and attaching. Notes are also here: https://gist.github.com/dzomaya/876d4f8f14db0c7fc04cfec220ac9a36


****************************
> Would publication be a good/bad idea?

Good idea overall.

> Is it clear enough to be published and implemented?

Yes. Comments and follow-up questions intended to help improve it are below, but even as-is it is useful.

* 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.

* Section 4.2.1
* Suggest replacing "trio" with "3" or "three" for simplicity

* 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

* 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

* 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

* 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
* 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.
* 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"

* 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 message is for the addressee's use only. It may contain confidential information. If you receive this message in error, please delete it and notify the sender. Tripp Lite disclaims all warranties and liabilities, and assumes no responsibility for viruses which may infect an email sent to you from Tripp Lite and which damage your electronic systems or information. It is your responsibility to maintain virus detection systems to prevent damage to your electronic systems and information.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: NUT_UPS_RFC_notes.md
Type: application/octet-stream
Size: 3475 bytes
Desc: NUT_UPS_RFC_notes.md
URL: <http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20211227/35c009f3/attachment.obj>