Re: [DNSOP] [Ext] draft-sah-resolver-information (revised)

[Paul Hoffman <[e-mail]>]

Sorry for the delay, and thanks for the careful review.

On Jun 3, 2019, at 4:52 AM, John Dickinson <[e-mail]> wrote:
> 
> Reference to SUDN in Introduction is no longer needed.

Fixed.

> DNS-over-TLS and DNS-over-HTTPS are both abbreviated to DoT in the Security Considerations

Fixed.

> Section 4 P3 s/returen/return/

Fixed.

> Section 4 and 5.2 are a bit hard to follow (maybe I need more caffeine). I would suggest that you use the term key-value pair in place of name-value pair. Using the word name in DNS docs is bound to lead to confusion.

I am hesitant to make that change because "name" is the term used consistently in JSON (and thus also in I-JSON). JSON uses "name/value pair", so I'll change to that, but I recognized that this is not a substitute for caffeine. 

> Also I was a bit confused by
> 
> 4: “All names in the returned object MUST be defined in the IANA registry
>   or begin with the substring "temp-“” and
>   “As defined in Section 5.2, the
>   IANA registry will not register names that begin with "temp-", so
>   these names can be used freely by any implementer”
> 
> 5.2: “Name: The name to be used in the JSON object.  This name MUST NOT
>   begin with "temp-".
> 
> until I reread the words “or begin with the substring "temp-“” I think the could be clearer, something like:
> 
> All keys in the returned object MUST either be defined in the IANA registry or if for local use only they MAY begin with the substring "temp-“ since IANA registry will not register names that begin with "temp-“.

Good suggestion; fixed.

> Finally, section 2
> 
> “Note that the answer given by the resolver cannot be validated with DNSSEC.”
> Whilst I understand the reasons, is it reasonable that we are still trying to standardise responses that can not be signed?

That wording was left over from the -00 draft and is incorrect. Fixed.

--Paul Hoffman