Subject: [Add] R1.1 (was RE: WGLC for draft-ietf-add-dnr)

From: <[email-masked]>
Date: Thu, 10 Mar 2022 06:32:45 +0000

Hi Chris,

Thank you for the comments and for sharing this assessment.

I will reply to each of the comments in a separate message for convenience.

Please see inline.

Cheers,
Med

De : Add <[email-masked]> De la part de Chris Box
Envoyé : mercredi 9 mars 2022 18:36
À : Deen, Glenn <Glenn_Deen=[email-masked]>
Cc : [email-masked]
Objet : Re: [Add] WGLC for draft-ietf-add-dnr

Hi everyone.

I've assessed DNR against relevant parts of draft-ietf-add-requirements.
Here's the first.

    +=============+===================================================+

    | Requirement | Description                                       |

    +=============+===================================================+

    | R1.1        | Discovery SHOULD provide a local network the      |

    |             | ability to announce to clients a set of, or       |

    |             | absence of, designated resolvers.                 |

It's not clear to me how you use DNR to advertise the absence of local encrypted DNS. Are we saying the router should send a frame with zero option length (if that is considered a multiple of 16), and zero ADN length? If yes, we should write that. If that's a bad design, we should think about what is better.

[Med] A network that does not support an encrypted DNS scheme (or configured to not supply an encrypted DNS to a requestor (*)) won’t advertise the DNS options when servicing that host. This is the normal behavior that is followed for configuration information (refer to rfc8415#section-18.3).

(*) the exact procedure for this case is specified in: https://datatracker.ietf.org/doc/draft-boucadair-opsawg-add-encrypted-dns/.

_________________________________________________________________________________________________________________________

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.

---

From: Chris Box <[email-masked]>
Date: Wed, 23 Mar 2022 10:16:39 +0100

Med,

With apologies for the delayed followup, I can now respond to the various
points.

> It's not clear to me how you use DNR to advertise the *absence *of local encrypted DNS. Are we saying the router should send a frame with zero option length (if that is considered a multiple of 16), and zero ADN length? If yes, we should write that. If that's a bad design, we should think about what is better.
>
>
>
> *[Med] A network that does not support an encrypted DNS scheme (or
> configured to not supply an encrypted DNS to a requestor (*)) won’t
> advertise the DNS options when servicing that host. This is the normal
> behavior that is followed for configuration information (refer to
> rfc8415#section-18.3). *
>
>
> I'm guessing you're referring to this part?

   If the client included an
   Option Request option (see Section 21.7) in its message, the server
   includes options in the response message containing configuration
   parameters for all of the options identified in the Option Request
   option that the server has been configured to return to the client.
   The server MAY return additional options to the client if it has been
   configured to do so.

In other words, DHCPv6 servers that have not been configured with Encrypted
DNS information, would simply omit the Encrypted DNS option response. I
think this is ok.

The same principle appears to apply to DHCPv4 and RA, and Ben agrees, so
I've convinced myself that R1.1 is met.

Chris