On Monday, 9 March 2020 20:56:39 UTC Ben Schwartz wrote: > It occurs to me that I hit "publish" on this draft without updating the > release notes, so I'll mention some of the many changes since -01 here > instead: > > ... > > As always, please review and send comments. We also expect to do a > presentation on this draft (remotely) in the DNSOP session.
i propose that section 6.2 for "port", and all references to same, be removed. this is: --- 6.2. "port" The "port" SvcParamKey defines the TCP or UDP port that should be used to contact this alternative service. The presentation format of the SvcParamValue is a numeric value between 0 and 65535 inclusive. Any other values (e.g. the empty value) are syntax errors. The wire format of the SvcParamValue is the corresponding 2 octet numeric value in network byte order. === in the SRV RR (from RFC 2782) we specified a port number as part of the RData because a client would otherwise have to have an up-to-date /etc/services file (or local equivalent) to know what (TCP) port number a listener would listen on, and this seemed archaic. for HTTPSSVC and SVCB, the service is a constant (HTTPS) and its transport layer port number (443) is known. inviting listener operators to specify a different port number will result in unpredictable (other than wide-spread) failures for those accessors behind NAT, firewalls, or ALG's. please leave out this legacy from DNS SRV as you go forward with HTTPSSVC. -- Paul _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
