Before I begin, a short summary of the different types of RFC's: 3. Standards Track, Draft Standard, Standard, developed by the IETF. 2. Best Current Practice [BCP], developed by an IETF Working Group [WG] 1. Informational RFC, developed by an individual as an independent submission. 0. Internet-Draft [I-D] Not yet assigned a number. Work in progress. I have submitted the NUT I-D to the RFC Independent Submission Editors [RFC ISE]. You can see the text at: https://datatracker.ietf.org/doc/draft-rprice-ups-management-protocol/ Here are the comments received from the RFC ISE (Adrian Farrel). We have to decide whether the NUT project wants to develop a Best Current Practice [BCP] or stay with an Informational RFC. _____________________________________________________________________> I can see good value in having a published specification for a UPS > management protocol, and also for a best current practice for > describing how to use the protocol and manages UPS.> Before I start work processing this as an Independent Stream > submission, I have three meta-points:> 1. Would you prefer to have this published as an IETF RFC? Given > that the document describes what is already in the field, I can > see that that might not be relevant for the description of the > protocol. But you might want IETF review and consensus for the > security and operational practices.> 2. As Independent Stream Editor, I cannot publish standards track > or BCP RFCs (they can only come out of the IETF). We could handle > this by sending the document through the IETF (see 1) or by > sticking with the "Informational" tag that you currently have, and > adding wise words about how this is a description of what is in > the field and that opinions on good practice are "only" the > opinions of the authors.> 3. I am somewhat limited as to what IANA actions can be requested in > Independent Stream documents (see RFC 8726). looking at your Section 6: > a. 6.1 looks like a reasonable conclusion. You might say where > codepoints will be tracked if they are added beyond this document. > Do you have a web page? > b. 6.2.2-1 I am not clear what your request to IANA is. What exactly > do you want to do? If you are asking that port 401 be *reassigned* > for a different use, then I think you may have a hard time > persuading the Port Experts. If you are saying that you plan to > use port 401 exactly as currently allocated, then there is probably > nothing more to say. > c. 6.2.2-2 Dependent on the answer to b, I suggest that prior to any > disposition of this document you should contact IANA and ask them to > consider assigning a new contact email for port 401. Just send them > mail. Hopefully, this can be resolved without any need to reference > this document.> For both b and c, the IANA will most certainly contact the Port > Experts. You should probably contact them direct to discus what > changes you want to see. You can see their names at > https://www.iana.org/assignments/service-names-port-numbers/ and > the IANA can help you contact them.> As for me, port 401 falls into the category of Systems Ports and > can only be assigned or modified by "IETF Review" or "IESG > Approval" which means that if you want to make a change to the > meaning of 401, you'll need to go via the IETF *or* get special > dispensation from the IESG.____________(Later, after RFC Editor discussions with IANA)______________> We think that changing the assignation is a lot of work partly > because we can't contact the current assignee, partly because it is > a system port requiring IETF review or IESG approval, and partly > because of the rules set out in section 8.5 and 8.6 of RFC 6335.(RP: See below for sections 8.5 and 8.6 which forbid direct transfers.)> The process *could* be followed with an Independent Stream document and > would look a bit like: > > - You make an application for port 401 following the process in RFC 6335 > and citing this document as reference. > You support this with information about the current use of the port. > - We advance the document (reviews and edits) to be ready to become an RFC > - May take a while > - Final step is going to the IESG for approval of the document and > at that time they could approve the assignment of the port (they > might be persuaded to do it sooner)> But two questions you should think about. Someone will definitely ask > them!> 1. What use is being made of 401 in the field today? If it is widely > used then reassignment may actually be easier provided we can > establish that you are not changing the meaning. If we know that > it is not being used, then that is also good (but it may be hard > to prove this in the absence of the assignee). If we don't know > if it is used, then it is hard to change the assignment. > > 2. Do you actually need a system port? Are you picking 401 because "it > looked like a relevant port"? Could you simply take another port > from the user port range?_________________________RFC 6335______________________________________ Cotton, et al. Service Name and Port Number Procedures, Best Current Practice RFC 6335, August 2011, Page 22 8.5. Service Name and Port Number Transfers The value of service names and port numbers is defined by their careful management as a shared Internet resource, whereas enabling transfer allows the potential for associated monetary exchanges. As a result, the IETF does not permit service name or port number assignments to be transferred between parties, even when they are mutually consenting. The appropriate alternate procedure is a coordinated de-assignment and assignment: The new party requests the service name or port number via an assignment and the previous party releases its assignment via the de-assignment procedure outlined above. With the help of their IESG-appointed Expert Reviewer, IANA SHALL carefully determine if there is a valid technical, operational, or managerial reason to grant the requested new assignment. 8.6. Maintenance Issues In addition to the formal procedures described above, updates to the Description and Contact information are coordinated by IANA in an informal manner, and may be initiated by either the Assignee or by IANA, e.g., by the latter requesting an update to current Contact information. (Note that the Assignee cannot be changed as a separate procedure; see instead Section 8.5 above.)
Roger Price
2021-Mar-20 10:10 UTC
[Nut-upsuser] NUT RFC: reference document for names for statuses
I am preparing an update to the NUT I-D https://datatracker.ietf.org/doc/draft-rprice-ups-management-protocol/ which answers some of the questions raised by the Independent Submissions Editor (ISE). I am looking for NUT documents which record names used in the NUT protocol. For the variables, the file docs/nut-names.txt looks suitable, but I do not have an equivalent document for the names of statuses. The file clients/status.h dates from 1999 and is incomplete. I gives only the 14 values OFF OL OB LB RB OVER TRIM BOOST CAL BYPASS when I expected to see 17 values: ALARM BOOST BYPASS CAL CHRG COMM DISCHRG FSD LB NOCOMM OB OFF OVER RB RB TEST TRIM. Is there a better reference document for the names of statuses? Roger
We have to decide whether the NUT RFC should be 1. an individual submission with status "Informational" or 2. an IETF Working Group (WG) submission as Best Current Practice (BCP). Should we decide 1, then your Editor will prepare a fuller text which anticipates the questions to come from the IETF. After that it will be matter of negotiation between Jim, myself, the IETF Editor, IANA and finally the IETF. We will have little difficulty in getting an RFC, but getting a second IANA port for TLS support is uncertain. Should we decide 2, then we would need to request permission from an IETF Area Director to form a WG in that Area, with an approved charter. A WG operates in a mailing list which is archived by the IETF. This means that we cannot use our nut-user list - we would have to open a new list. Do we have enough people willing to join a new list to discuss IETF processes? The submission of a text becomes more complex. The WG takes decisions on the basis of consensus as determined by the WG chairman (Jim). The advantage is that any text submitted goes directly by the IETF itself which has the power to approve/disapprove the assignment of ports. For full details, see RFC 2418 "IETF Working Group Guidelines and Procedures" https://tools.ietf.org/html/rfc2418 It would be a much longer process getting to a BCP, a matter of years. It would involve more people, the formalities are laborious and the outcome is uncertain. It is perfectly possible for the IETF to end up saying No. Given the procedural complexity of developing a BCP (Best Current Practice), and the difficulty of transferring a port, I am personally inclined to follow the suggestion from the RFC Editor, stay with an informational RFC and follow the suggested path 1. But this must be a collective decision taken by the whole NUT project. Roger