On Fri, Dec 6, 2019 at 5:45 PM Eric Orth <ericorth= 40google....@dmarc.ietf.org> wrote:
> > > - Therefore, unless somebody comes up with a good reason that longer > chains need to be supported, we intend to only follow 1 or 2 links before > > > I'm sure you're not trying to undermine the standards process, but that's what happens as a side effect of statements like that. We're at an -01, let's discuss (as Brian does downthread) the reasoning behind design decisions and see if we can get to consensus on them without threatening to take the ball and go home already. If there is eventual consensus and you're in the rough and feel its bad for your product then the appropriate thing to do is not to implement a standard you don't believe in. but implementing a different protocol and calling it httpsssvc does nothing but lead to breakage and undermine the entire point of having a standards based definition. Maybe you mean you strongly believe this standard should allow at most 2 links? Brian has got a good point that these are pointers, and pointers don't know how long the list is and the parties in the list are not strongly coordinated (which is what makes a pointer powerful - its permissionless). This also complicates ESNI, but its a fact of life. Also, people trade latency off against indirection all of the time for reasons they think are valuable (that's true of DNS but also in general). It would be interesting to study the distribution of chain lengths, but I can say off the cuff that 3 is really common in web space and imo, this spec should be aligning itself with existing deployment strategies in order to make its own path to deployment as frictionless as possible. ;; ANSWER SECTION: download.microsoft.com. 1471 IN CNAME 2-01-4ca6-0004.cdx.cedexis.net. 2-01-4ca6-0004.cdx.cedexis.net. 19 IN CNAME main.dl.ms.akadns.net. main.dl.ms.akadns.net. 160 IN CNAME download.microsoft.com.edgekey.net. download.microsoft.com.edgekey.net. 12 IN CNAME e3673.dscg.akamaiedge.net. e3673.dscg.akamaiedge.net. 8 IN A 23.46.196.215
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
