[Add] Gunter Van de Velde's No Objection on draft-ietf-add-resolver-info-12: (with COMMENT)

[Gunter Van de Velde via Datatracker <[e-mail]>]

Gunter Van de Velde has entered the following ballot position for
draft-ietf-add-resolver-info-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-add-resolver-info/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Many thanks for the document. It was easy to read and process and well written.

Please use or ignore the below observations at your desire.

The abstract could be made more precise:

[existing]
13         This document specifies a method for DNS resolvers to publish
14         information about themselves.  DNS clients can use the resolver
15         information to identify the capabilities of DNS resolvers.  How such
16         an information is then used by DNS clients is out of the scope of
17         this document.

[proposed]
   This document specifies a method for DNS resolvers to publish
   information about themselves.  DNS clients can use the resolver
   information to identify the capabilities of DNS resolvers.
   How DNS clients use such information is beyond the scope of this document.

other observations and clarifications:

101        Retrieved information can be used to feed the server selection
102        procedure.  However, that selection procedure is out of the scope of
103        this document.

Can the retrieved only be used for server selection, or is this merely an
example use-case? This could maybe be clarified?

133        Section 5.  If the resolver understands the RESINFO RR type, the
134        RRSet MUST have exactly one record.  RESINFO is a property of the

What if there is none or more as one? is there an exception procedure?

156        The resolver information record uses the same format as DNS TXT
157        records.  As a reminder, the format rules for TXT records are defined
158        in the base DNS specification (Section 3.3.14 of [RFC1035]) and

The words 'As a reminder' sound pedantic. Maybe they can be removed without
changing the validity of the information.

172        Keys MUST either be defined in the IANA registry (Section 8.2) or
173        begin with the substring "temp-" for names defined for local use
174        only.

Maybe additional clarification on what keys is being referenced to? It is
reasonably clear from the previous context, but being more explicit, especially
with a training MUST statement will reduce confusion.

180        qnamemin:  If the DNS resolver supports QNAME minimisation [RFC9156]
181           to improve DNS privacy, the key is present.  Note that, as per the
182           rules for the keys defined in Section 6.4 of [RFC6763], if there
183           is no '=' in a key, then it is a boolean attribute, simply
184           identified as being present, with no value.

I am unsure what 'the key is present' exactly means? does this need BCP14
normative language? note that 'minimisation' is British English, while
'minimization' is American English

188        exterr:  If the DNS resolver supports extended DNS errors (EDE)
189           option [RFC8914] to return additional information about the cause
190           of DNS errors, the value of this key lists the possible extended
191           DNS error codes that can be returned by this DNS resolver.  When
192           multiple values are present, these values MUST be comma-separated.

what if the same value is added multiple times? or if there are 100000 values
inserted? what if illegal values are inserted?

196        infourl:  An URL that points to the generic unstructured resolver
197           information (e.g., DoH APIs supported, possible HTTP status codes
198           returned by the DoH server, or how to report a problem) for
199           troubleshooting purposes.  The server that exposes such
200           information is called "resolver information server".

Is it possible that the URL is not complete, invalid or overly long? how to
handle exception scenarios when the URL is illegal or incorrect?

202           The resolver information server MUST support the content-type
203           'text/html'.  The DNS client MUST reject the URL if the scheme is
204           not "https".  The URL SHOULD be treated only as diagnostic
205           information for IT staff.  It is not intended for end user
206           consumption as the URL can possibly provide misleading
207           information.  A DNS client MAY choose to display the URL to the
208           end user, if and only if the encrypted resolver has sufficient
209           reputation, according to some local policy (e.g., user
210           configuration, administrative configuration, or a built-in list of
211           respectable resolvers).

The wording 'if and only if' seems a difficult way to use 'when'?