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"
Done.
________________________________________________________________________________
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"
Done.
________________________________________________________________________________
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
Done.
________________________________________________________________________________
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".
Done.
________________________________________________________________________________
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
assistance.
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.
_______________________________________________
Nut-upsdev mailing list
[email protected]
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev
