I agree. I do not think we should make this change. -Ekr
On Fri, Jan 3, 2020 at 12:02 PM Erik Kline <ek.i...@gmail.com> wrote: > I think removing port number flexibility might unduly constrain some data > center use cases where service reachability might not have the more common > 443-only limitations. > > On Fri, Jan 3, 2020 at 11:33 AM Ben Schwartz <bemasc= > 40google.....@dmarc.ietf.org <40google....@dmarc.ietf.org>> wrote: > >> HTTPSSVC co-editor here. >> >> The effect of this change seems similar to deprecating support for >> non-default ports in HTTP/3. While I have some misgivings about the >> handling of non-default ports in HTTPS, I would want to see consensus in >> the HTTP and QUIC working groups before making this change. >> >> I would suggest sending your proposal to those lists, and we can adjust >> the HTTPSSVC draft based on their conclusions. >> >> On Fri, Jan 3, 2020 at 1:24 PM Paul Vixie <p...@redbarn.org> wrote: >> >>> in SRV we added a port number to the rdata because the /etc/services >>> file was >>> painful to keep globally updated. SRV was protocol independent. >>> >>> HTTPSSVC is protocol specific, and when it copied SRV, it included the >>> port >>> number in the rdata, which i think is both unnecessary and error-prone. >>> >>> managed private networks who want to permit outbound HTTP/3 are going to >>> add a >>> rule like "if the far end port number is 443, add a stateful rule". >>> anyone who >>> uses the port number field (if it exists) in HTTPSSVC to specify a >>> different >>> port number is going to suffer, as will many of the clients trying to >>> access >>> that service. >>> >>> i suggest that the port 443 assumption for HTTP/3 be baked in, and that >>> this >>> field be removed from the HTTPSSVC rdata. >>> >>> -- >>> Paul >>> >>> >>> _______________________________________________ >>> DNSOP mailing list >>> DNSOP@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnsop >>> >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >> > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
