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
