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://github.com/MikeBishop/dns-alt-svc
> 
> 
> 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://www.ietf.org/mailman/listinfo/dnsop
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> _______________________________________________
> 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

Reply via email to