Re: [DNSOP] I-D Action: draft-ietf-dnsop-svcb-httpssvc-02.txt

[Paul Vixie <[e-mail]>]

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