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
- 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)."
-
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
- 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).
-
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.
Also submitted to the list here:
https://alioth-lists.debian.net/pipermail/nut-upsdev/2021-December/007650.html