Re: [DNSOP] port number in HTTPSSVC

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.com@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 <paul@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
>