[Nut-upsuser] An RFC for the NUT project

[Roger Price]

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