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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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
>>> <[email protected]> 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
>>>> <[email protected]> wrote:
>>>>
>>>>
>>>>
>>>>> On Jul 22, 2020, at 5:46 PM, Wellington, Brian
>>>>> <[email protected]> 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 <[email protected]>
>>>>>> 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
>>>>>> [email protected]
>>>>>> 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
>>>>> [email protected]
>>>>> 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
>>> [email protected]
>>> 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
>>> [email protected]
>>> 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: [email protected]
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [email protected]
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
