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

[[e-mail]]

Hi Gunter, 

Thanks for the review. 

A version that takes into account your review can be seen at: https://author-tools.ietf.org/api/iddiff?url_1=https://boucadair.github.io/add-resolver-information/draft-ietf-add-resolver-info.txt&url_2=https://boucadair.github.io/add-resolver-information/Gunter-Review/draft-ietf-add-resolver-info.txt

Please see inline for more context.

Cheers,
Med

> -----Message d'origine-----
> De : Add <[e-mail]> De la part de Gunter Van de Velde via
> Datatracker
> Envoyé : vendredi 29 mars 2024 12:54
> À : The IESG <[e-mail]>
> Cc : [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> Objet : [Add] Gunter Van de Velde's No Objection on draft-ietf-add-
> resolver-info-12: (with COMMENT)
> 
> 
> 
> 
> ----------------------------------------------------------------------
> 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.
> 

[Med] OK.

> 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?

[Med] Server selection is the main use. FWIW, we are covering this part of the ADD charter:

==
Define a mechanism that allows communication of DNS resolver
information to clients for use in selection decisions.
==

> 
> 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?

[Med] Added "Invalid records MUST be silently ignored by DNS clients." as a catchup.

> 
> 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.

[Med] ACK.

> 
> 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.
> 

[Med] s/Keys/Resolver information keys

> 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? 

[Med] Tweaked the text to "The presence of this key indicates that the DNS resolver supports QNAME minimisation {{!RFC9156}}
to improve DNS privacy".

note that 'minimisation' is British English, while
> 'minimization' is American English
> 

[Med] :-) We are actually echoing the form used in RFC9156.

> 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?

[Med] No need to over-specify here, IMO. If we had to specify the selection procedure, we should cover these cases but it is really up to that layer to decide what to do (ignore, etc.).

> 
> 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?
> 

[Med] Added: "Invalid URLs MUST be ignored."

> 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'?
> 

[Med] I prefer to keep the OLD wording. Thanks.


____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.