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