Re: [Nut-upsuser] An RFC for the NUT project
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 Nut-upsuser@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] An RFC for the NUT project
On Jan 23, 2021, at 8:18 AM, Roger Price 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
[Nut-upsuser] 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 ___ Nut-upsuser mailing list Nut-upsuser@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
