As TSVART reviewer I have included two additional mailing lists for this review response, sorry for the cross posting but I think it is relevant to get more opinions on this. The port experts, although they are not responsible for system port assignments per RFC 6335. TSVWG is included as it is the WG that have been responsible for developing the documents in BCP 165 and these rules. 

The main question here is if this particular case warrants an exception in regards to the principals documented by RFC 6335 and RFC 7605 (Together BCP 165)? 

So this document wants an alternative port that is to be used with a subset of NTPv4 that is deemed to be more operational safe and which has an packet response amplification factor below 1, i.e. for each request, one and only one response is generated and that packet is not larger than the request. 
For more details see (it is a very short document): https://datatracker.ietf.org/doc/draft-ietf-ntp-alternative-port/

So in regards to the basic principals this should be rejected as it is simply an alternative. However, I think this one might be a case where the exception is motivated. The service here is not identical and it has improved security properties, especially in regards to how network intermediaries may interpret the traffic. Where one might want to filter and/or block port 123 due to its potential for DDoS with a reduced risk the alternative port would imply I think this gets into the case which Section 7.1 of RFC 7605 discusses: 

   o  Separate assigned port numbers are not intended for insecure
      versions of existing (or new) secure services.  A service that
      already requires security would be made more vulnerable by having
      the same capability accessible without security.

      Note that the converse is different, i.e., it can be useful to
      create a new, secure service that replicates an existing insecure
      service on a new port number assignment.  This can be necessary
      when the existing service is not backward-compatible with security
      enhancements, such as the use of TLS [RFC5246] or DTLS [RFC6347].

The important difference here is that although this is not an endpoint incompatibility issue, it is an interpretation difference by the network itself. 

So personally I would argue for this exception to the basic principles. However, this is in the end going to be an IETF consensus decision if we allow it or not. Thus, I think discussing any views now, and allow a bit more time for discussion and also addressing any issue prior to IETF last call would be good. 

I also would like to ask the NTP experts if they really need a system port? From my perspective an NTP server should not need to run with increased privileges on the host. The main purpose of NTP is after all to server the requester an answer based on its access to a clock that is believed to provide accurate time. So, could you please improve the motivation why "ntp-alt" actually needs a system port. Even if NTP as a service when originally was given port 123 a system ports it might have been considered a system services I do wonder if that assessment still stands. I would note that this motivation is required for any application for assigning a systems port. 

 Cheers

Magnus Westerlund