Subject: [Add] R2.2-R2.4 (was RE: WGLC for draft-ietf-add-dnr)

From: <[email-masked]>
Date: Thu, 10 Mar 2022 07:35:27 +0000

Re-,

Chris, I’m not sure to get this one. We need to focus on the content not the formatting as there are subtleties that are specific to each mechanism.

Mobile networks can use the RA/DHCP options in this document or create PCO IEs that will echo the content of these options following any guidelines they have for building their IEs. We could create a container that can be encapsulated in every mechanism but I don’t that is needed.

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.

    +-------------+---------------------------------------------------+

    | R2.2        | The format for resolver designation SHOULD be     |

    |             | specified such that provisioning mechanisms       |

    |             | defined outside of the IETF can advertise         |

    |             | encrypted DNS resolvers.                          |

    +-------------+---------------------------------------------------+

    | R2.3        | This format SHOULD convey, at minimum, the        |

    |             | information the client needs to make contact with |

    |             | each designated resolver.                         |

    +-------------+---------------------------------------------------+

    | R2.4        | This format MAY convey additional resolver        |

    |             | information.                                      |

Not met, and it seems to be an easy thing to add. Doing so could make it easier and more consistent for use over, for example, 3GPP mobile networks.

_________________________________________________________________________________________________________________________

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: Ben Schwartz <[email-masked]>
Date: Thu, 10 Mar 2022 12:02:31 -0500

I also feel that we should not attempt to make the format more extensible.
It can already be extended in the ways Med described, and also via SVCB
SvcParams.

On Thu, Mar 10, 2022 at 2:35 AM <[email-masked]> wrote:

> Re-,
>
>
>
> Chris, I’m not sure to get this one. We need to focus on the content not
> the formatting as there are subtleties that are specific to each mechanism.
>
>
>
>
> Mobile networks can use the RA/DHCP options in this document or create PCO
> IEs that will echo the content of these options following any guidelines
> they have for building their IEs. We could create a container that can be
> encapsulated in every mechanism but I don’t that is needed.
>
>
>
> 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.
>
>
>
> --
> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add
>

---

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

On Thu, 10 Mar 2022 at 18:02, Ben Schwartz <[email-masked]> wrote:

> I also feel that we should not attempt to make the format more
> extensible.  It can already be extended in the ways Med described, and also
> via SVCB SvcParams.
>

I wasn't asking for extensibility.

My aim here is consistency of description across network types. SVCB for
"dns" is a common building block that gives us most of that already.

I suggest there is a section that says, in some form, "If you are an SDO
with your own mechanism, here's what we suggest you convey across that,
making only the minimal modifications that are needed."

Chris

---

From: <[email-masked]>
Date: Wed, 23 Mar 2022 14:52:17 +0000

Re-,

Would adding the following address your concern?

NEW:
   Other mechanisms may be considered in other contexts (e.g., secure
   discovery) for the provisioning of encrypted DNS servers.  It is
   RECOMMENDED that at least the following DNR information is made
   available to a requesting host:

   o  A service priority whenever the discovery mechanism does not rely
      on implicit ordering if multiple instances of the encrypted DNS
      are used.

   o  A list of IP addresses to locate the encrypted DNS server

   o  An Authentication domain name for authentication purposes

   o  A list of service parameters

Thanks.

Cheers,
Med

De : Chris Box <[email-masked]>
Envoyé : mercredi 23 mars 2022 10:34
À : Ben Schwartz <[email-masked]>; BOUCADAIR Mohamed INNOV/NET <[email-masked]>
Cc : [email-masked]
Objet : Re: [Add] R2.2-R2.4 (was RE: WGLC for draft-ietf-add-dnr)

    |             | information.                                      |

On Thu, 10 Mar 2022 at 18:02, Ben Schwartz <[email-masked]<mailto:[email-masked]>> wrote:
I also feel that we should not attempt to make the format more extensible.  It can already be extended in the ways Med described, and also via SVCB SvcParams.

My aim here is consistency of description across network types. SVCB for "dns" is a common building block that gives us most of that already.

I suggest there is a section that says, in some form, "If you are an SDO with your own mechanism, here's what we suggest you convey across that, making only the minimal modifications that are needed."

Chris

---

From: Chris Box <[email-masked]>
Date: Wed, 23 Mar 2022 17:38:53 +0100

>    o  A list of service parameters

At first pass, yes I think so. It would benefit from further thinking (by
me and others), but right now it looks like a good improvement.

Chris