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.)
_______________________________________________
Nut-upsuser mailing list
[email protected]
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
