Because the definitions of “mandatory” and “automatically mandatory” are not
all that clear. And “mandatory” is also a word in the English language, with
meanings and connotations (and is the opposite of “optional”).
The spec is internally consistent, but it definitely could be made be more
clear.
Brian
> On Jul 22, 2020, at 7:12 PM, Mark Andrews <ma...@isc.org> wrote:
>
> 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_dnsop&d=DwIFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bPfM-kVBGNE2d_r6kVQw1V-urTv21fSHLYeFhReKf5w&m=FtMnEZFyfLXTvyM7ZAFq08FBW1-7qUZvzg_tT0X3PQE&s=cmmQysWJ2dW9RAvBo6_GULomfiLuXTV1dl-FlMQDTEI&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
