[Nut-upsuser] NUT RFC; progress report

[Roger Price]

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