Nut upsuser - Jan 2021 - An RFC for the NUT project

IETF and IANA require that protocols on ports assigned by IANA be documented 
with RFC's.  We do not currently have an RFC for port nut/3493.  To solve
this
IANA port administration issue, I propose the text 
http://rogerprice.org/NUT/draft-rprice-ups-management-protocol-00.html as a 
candidate.  Such texts are known as "Internet Drafts".  They have a
limited
lifetime, but if accepted by the IETF become permanent "Informational
RFC's".

Clauses "5. IANA Considerations" and "6. Security
Considerations" are key
clauses.

There are places in the text which need clarification.  I would much appreciate 
assistance in completing those clauses.

In the long term, if all goes well, it would be good for the NUT Project to have
the RFC promoted to "Best Current Practice" (BCP), which is a step
towards the
Nivana of "Standards Track" and highly desirable.  Getting to BCP
requires a
full consensus.

Comments and corrections are welcome in this list.  When we have a consensus, I 
will submit the draft to the IETF.

Roger

On Jan 23, 2021, at 8:18 AM, Roger Price <roger at rogerprice.org>
wrote:
> 
> IETF and IANA require that protocols on ports assigned by IANA be
documented with RFC's.  We do not currently have an RFC for port nut/3493. 
To solve this IANA port administration issue, I propose the text
http://rogerprice.org/NUT/draft-rprice-ups-management-protocol-00.html as a
candidate.  Such texts are known as "Internet Drafts".  They have a
limited lifetime, but if accepted by the IETF become permanent
"Informational RFC's".
> 
> Clauses "5. IANA Considerations" and "6. Security
Considerations" are key clauses.
> 
> There are places in the text which need clarification.  I would much
appreciate assistance in completing those clauses.
> 
> In the long term, if all goes well, it would be good for the NUT Project to
have the RFC promoted to "Best Current Practice" (BCP), which is a
step towards the Nivana of "Standards Track" and highly desirable. 
Getting to BCP requires a full consensus.
> 
> Comments and corrections are welcome in this list.  When we have a
consensus, I will submit the draft to the IETF.
Nice work! I would like to take a little more time to read through this, 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.

* 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?)

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

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