If your interpretation of this comes down to “mandatory is optional”, then that shows how confusing this is.
Brian > On Jul 22, 2020, at 6:45 PM, Mark Andrews <ma...@isc.org> wrote: > > This is a case of reading a sentence out of context. > > The first paragraph describing “mandatory” ends with: > > The SvcParamKey "mandatory" is used to indicate any mandatory keys for this > RR, in addition to any automatically mandatory keys that are present. > > It also has: > > In presentation format, "mandatory" contains a list of one or more valid > SvcParamKeys, > > I think there is already plenty of context to show that mandatory is optional. > >> On 23 Jul 2020, at 11:31, Tim Wicinski <tjw.i...@gmail.com> wrote: >> >> Brian >> >> I agree on clarity, and their git repo has been more recently updated. >> I've been poking the authors on some better examples in the spec as well. >> >> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_MikeBishop_dns-2Dalt-2Dsvc&d=DwIFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bPfM-kVBGNE2d_r6kVQw1V-urTv21fSHLYeFhReKf5w&m=KbZDXTLvNOxENtFWCMdggAhJaRvABzLIoje-QspoFCM&s=NAnMW9xGWQVnYnS9I88YowKyWxHMrEM3ACuElx9IB5Y&e= >> >> >> >> On Wed, Jul 22, 2020 at 9:20 PM Wellington, Brian >> <bwelling=40akamai....@dmarc.ietf.org> wrote: >> ok. So, what this means is that keys listed in the “mandatory” parameter >> must be included as parameters, and are required to be understood by >> clients. The set of “automatically mandatory” keys are required to be >> understood by clients, but are not required in the RR. >> >> I’m a native English speaker, and have been working with DNS for over 20 >> years. If I’m having trouble understanding this, perhaps the spec should be >> a bit clearer. >> >> Brian >> >>> On Jul 22, 2020, at 5:56 PM, Tommy Pauly >>> <tpauly=40apple....@dmarc..ietf.org> wrote: >>> >>> >>> >>>> On Jul 22, 2020, at 5:46 PM, Wellington, Brian >>>> <bwelling=40akamai....@dmarc.ietf.org> wrote: >>>> >>>> I attempted to start implementing support for SVCB and HTTPS, and >>>> discovered that the data being served by Cloudflare does not conform to >>>> the current spec. >>>> >>>> Assuming my decoder is correct, the response below decodes to: >>>> >>>> 1 . alpn=h3-29,h3-28,h3-27,h2 echconfig=aBIaLmgSGy4= >>>> ipv6hint=2606:4700::6812:1a2e,2606:4700::6812:1b2e >>>> >>>> and does not include a “mandatory” parameter. But section 6.5 of >>>> draft-ietf-dnsop-svcb-https, which is talking about the “mandatory” key, >>>> says: >>>> >>>> This SvcParamKey is always automatically mandatory, >>>> >>>> which implies that there MUST be a “mandatory” parameter. Is this an >>>> oversight in the Cloudflare implementation, or is the Cloudflare >>>> implementation not implementing the current version? >>> >>> The Cloudflare record does conform correctly. >>> >>> The “mandatory” key does NOT need to be included. "automatically mandatory” >>> keys do not need to be included. Mandatory just indicates which >>> non-automatically-mandatory keys included in the record are required to be >>> understood by clients, or else clients should reject them. >>> >>> Thanks, >>> Tommy >>> >>>> >>>> Thanks, >>>> Brian >>>> >>>>> On Jul 16, 2020, at 8:13 AM, Alessandro Ghedini <alessan...@ghedini.me> >>>>> wrote: >>>>> >>>>> Hello, >>>>> >>>>> Just a quick note that we have started serving "HTTPS" DNS records from >>>>> Cloudflare's authoritative DNS servers. Our main use-case right now is >>>>> advertising HTTP/3 support for those customers that enabled that feature >>>>> (in >>>>> addition to using Alt-Svc HTTP headers). >>>>> >>>>> If anyone is interested in trying this out you can query pretty much all >>>>> domains >>>>> served by Cloudflare DNS for which we terminate HTTP. >>>>> >>>>> For example: >>>>> >>>>> % dig blog.cloudflare.com type65 >>>>> >>>>> ; <<>> DiG 9.16.4-Debian <<>> blog.cloudflare.com type65 >>>>> ;; global options: +cmd >>>>> ;; Got answer: >>>>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17291 >>>>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 >>>>> >>>>> ;; OPT PSEUDOSECTION: >>>>> ; EDNS: version: 0, flags:; udp: 4096 >>>>> ;; QUESTION SECTION: >>>>> ;blog.cloudflare.com. >>>>> IN >>>>> TYPE65 >>>>> >>>>> ;; ANSWER SECTION: >>>>> blog.cloudflare.com. >>>>> 300 IN >>>>> TYPE65 \# 76 000100000100150568332D32390568332D32380568332D3237026832 >>>>> 0004000868121A2E68121B2E00060020260647000000000000000000 >>>>> 68121A2E26064700000000000000000068121B2E >>>>> >>>>> Cheers >>>>> >>>>> _______________________________________________ >>>>> DNSOP mailing list >>>>> DNSOP@ietf.org >>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf..org_mailman_listinfo_dnsop&d=DwICAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=bPfM-kVBGNE2d_r6kVQw1V-urTv21fSHLYeFhReKf5w&m=Ei0lUqjTt2OhRnRqJeO1XDCHQqnH1FdINDMcPEhCC1g&s=WQn55KFIZ5LGfsj-QGNSS31WGhpI-GuXpJEmhibwNuo&e= >>>>> >>>> >>>> _______________________________________________ >>>> DNSOP mailing list >>>> DNSOP@ietf.org >>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_dnsop&d=DwIFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bPfM-kVBGNE2d_r6kVQw1V-urTv21fSHLYeFhReKf5w&m=KbZDXTLvNOxENtFWCMdggAhJaRvABzLIoje-QspoFCM&s=T4xEg4ZgSU98oALn8LAXlkcHcJsPFbcGLuBwIOLAef0&e= >>>> >> >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_dnsop&d=DwIFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bPfM-kVBGNE2d_r6kVQw1V-urTv21fSHLYeFhReKf5w&m=KbZDXTLvNOxENtFWCMdggAhJaRvABzLIoje-QspoFCM&s=T4xEg4ZgSU98oALn8LAXlkcHcJsPFbcGLuBwIOLAef0&e= >> >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_dnsop&d=DwIFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bPfM-kVBGNE2d_r6kVQw1V-urTv21fSHLYeFhReKf5w&m=KbZDXTLvNOxENtFWCMdggAhJaRvABzLIoje-QspoFCM&s=T4xEg4ZgSU98oALn8LAXlkcHcJsPFbcGLuBwIOLAef0&e= >> > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
