On Jan 23, 2021, at 8:18 AM, Roger Price <ro...@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. _______________________________________________ Nut-upsuser mailing list Nut-upsuser@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
