We could change the sentence to start with "This SvcParamKey MUST NOT be ignored,"
> On 23 Jul 2020, at 12:09, Mark Andrews <ma...@isc.org> wrote: > > mandatory is described thus: > > "In a ServiceMode RR, a SvcParamKey is considered "mandatory" if the RR will > not > function correctly for clients that ignore this SvcParamKey. Each SVCB > protocol > mapping SHOULD specify a set of keys that are "automatically mandatory", i.e. > mandatory if they are present in an RR. The SvcParamKey "mandatory" is used > to > indicate any mandatory keys for this RR, in addition to any automatically > mandatory keys that are present. > > A ServiceMode RR is considered "compatible" with a client if the client > implements > support for all its mandatory keys. If the SVCB RRSet contains no compatible > RRs, > the client will generally act as if the RRSet is empty. > > In presentation format, "mandatory" contains a list of one or more valid > SvcParamKeys, > either by their registered name or in the unknown-key format > ({{presentation}}). Keys > MAY appear in any order, but MUST NOT appear more than once. Any listed keys > MUST also > appear in the SvcParams. To enable simpler parsing, this SvcParam MUST NOT > contain > escape sequences. > > For example, the following is a valid list of SvcParams: > > echconfig=... key65333=ex1 key65444=ex2 mandatory=key65444,echconfig > > In wire format, the keys are represented by their numeric values in network > byte order, > concatenated in ascending order. > > This SvcParamKey is always automatically mandatory, and MUST NOT appear in > its own > value list. Other automatically mandatory keys SHOULD NOT appear in the list > either. > (Including them wastes space and otherwise has no effect.)” > > I don’t see how, after reading that, one can conclude that all ServiceMode > records > MUST include the key “mandatory”. > > Mark > >> On 23 Jul 2020, at 11:47, Wellington, Brian <bwell...@akamai.com> wrote: >> >> 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 > > -- > 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 -- 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