Re: [Last-Call] Opsdir last call review of draft-ietf-add-dnr-10

["Joe Clarke \(jclarke\)" <jclarke=40cisco.com@xxxxxxxxxxxxxx>]

Thanks.  This addresses my comment.

 

Joe

 

From: mohamed.boucadair@xxxxxxxxxx <mohamed.boucadair@xxxxxxxxxx>
Date: Friday, July 8, 2022 at 14:51
To: Joe Clarke (jclarke) <jclarke@xxxxxxxxx>, ops-dir@xxxxxxxx <ops-dir@xxxxxxxx>
Cc: add@xxxxxxxx <add@xxxxxxxx>, draft-ietf-add-dnr.all@xxxxxxxx <draft-ietf-add-dnr.all@xxxxxxxx>, last-call@xxxxxxxx <last-call@xxxxxxxx>
Subject: RE: Opsdir last call review of draft-ietf-add-dnr-10

Re-,

 

I’m not that comfortable with adding a reco for clients, but let’s try the following:

 

   If a client learns both encrypted and unencrypted DNS resolvers from

   the same network, and absent explicit configuration otherwise, it is

   RECOMMENDED that the client uses the encrypted DNS resolvers for that

   network.

 

Cheers,

Med

 

De : Joe Clarke (jclarke) <jclarke@xxxxxxxxx>
Envoyé : vendredi 8 juillet 2022 20:28
À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@xxxxxxxxxx>; ops-dir@xxxxxxxx
Cc : add@xxxxxxxx; draft-ietf-add-dnr.all@xxxxxxxx; last-call@xxxxxxxx
Objet : Re: Opsdir last call review of draft-ietf-add-dnr-10

 

Hey, Med.  See below.

 

[Med] We don't include such details because:
* Whether a client asks for Do53 in addition to encrypted DNS is implementation and policy based.
* Also, how a DNS selects among learned Do53 and Encrypted DNS servers is beyond discovery.

 

[JC] I get how this can be left up to the server and/or client.  Still, with an operator hat on, it might be nice to see a RECOMMENDED blurb that when presented with both encrypted and unencrypted DNS options, a client SHOULD choose the encrypted DNS.

  You mention you initially thought of using those
> approaches, but that leads to probing.
>
> Section-wise, I found a couple of nits:
>
> Section 3.1.8:
>
> s/If the checks fail, the receiver discards/If any of the checks
> fail, the receiver MUST discard/

[Med] OK for the first part of the suggested change. For the second one, we are not using the normative language on purpose because otherwise this will be redundant with text such as:

   The DHCPv6 client MUST silently discard any OPTION_V6_DNR that fails
   to pass the validation steps defined in Section 3.1.8.

[JC] It was this that prompted me to suggest the strong text.  But I’m okay with not having it in both places.

 

Joe

_________________________________________________________________________________________________________________________

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.

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call