On Sat, 23 Jan 2021, Charles Lepple wrote:
..., but a few early notes:
* I try not to be too picky about moving threads between lists (since our
archives are fragmented as-is), but for new protocol-related threads, I'd
recommend listing the discussion address in the RFC as the nut-upsdev list
instead of nut-upsuser.
I choose nut-upsuser to get wide coverage : for me it's Jim's decision.
* For a new document that will be undergoing review by a diverse audience, I
would recommend we seriously discuss changing the master/slave terminology
before submitting to IETF. I have not had a chance to see what other recent
RFCs use, but some preliminary NUT discussion is here:
https://github.com/networkupstools/nut/issues/840 (maybe captain/crew,
leader/follower, etc?)
It looks as if problems could arise with presentations of NUT in woke
organisations. I have changed Master/Slave to Primary/Secondary, and the
command MASTER is changed to PRIMARY, with notes to say `Historically, this
command was known as "MASTER"'. I have not said that MASTER is deprecated.
* CHRG generally implies OL, but not if UPS output is OFF (battery still may
be recharging). OL does not imply CHRG if battery is floating. DISCHRG is
similar, in that the UPS output may not be "on battery" if there is an
internal dummy load for calibration. I would recommend against reading into
what some of the drivers do - not all of them are correct, especially the ones
based on observations or generic protocols rather than vendor documentation.
I have updated the status CHRG to read
The UPS battery is charging. This usually implies that the UPS also has status
OL, but may not be the case if the UPS also has status OFF.
Note: OL does not imply CHRG if the battery is floating.
and I have changed status DISCHRG to read
The UPS battery is discharging. This usually implies that the UPS also has
status OB, but may not be the case if the UPS also has status OFF.
Note: OB does not imply DISCHRG if the battery is floating.
* NETVER is IMHO problematic. Numeric version tests can generally can be
avoided by distinguishing between various error codes when trying commands. If
we are proposing a new way to describe the protocol revision (PROTVER?) I
would instead recommend something based on named features (which would be more
amenable to branching and merging). Some past discussion on the topic:
https://alioth-lists.debian.net/pipermail/nut-upsdev/2012-March/006000.html
https://alioth-lists.debian.net/pipermail/nut-upsdev/2012-May/006123.html
For an example, see
https://en.wikipedia.org/wiki/Sieve_(mail_filtering_language)#Extensions and
the "require" line in the sample script in the next section.
My change of NETVER to PROTVER was editorial and not technical. The response
should indicate the version of the protocol supported, not the version of the
network.
Interrogating the server to discover the features available looks like something
new. I would like an RFC to appear with 2.7.5, so maybe feature discovery
should be "for future study" as far as an RFC is concerned.
Roger
_______________________________________________
Nut-upsuser mailing list
[email protected]
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
