Re: [Add] WG Adoption Call draft-reddy-add-enterprise-split-dns

Hi all, 

Definitely agree with Diego and Eliot. 

I support adopting this document as a starting point.  

Cheers,
Med

> -----Message d'origine-----
> De : Add <add-bounces@ietf.org> De la part de Diego R. Lopez
> Envoyé : vendredi 13 mai 2022 10:29
> À : Eliot Lear <lear@lear.ch>; Paul Wouters <paul@nohats.ca>;
> bemasc@google.com
> Cc : ADD Mailing list <add@ietf.org>
> Objet : Re: [Add] WG Adoption Call draft-reddy-add-enterprise-
> split-dns
> 
> Hi,
> 
> I take advantage of Eliot's statement to essentially agree with
> him and support adoption. There are a few aspects related to
> choices and enterprise environments I think would require more
> discussion, but this is what adoption is for...
> 
> Be goode,
> 
> --
> "Esta vez no fallaremos, Doctor Infierno"
> 
> Dr Diego R. Lopez
> Telefonica I+D
> https://www.linkedin.com/in/dr2lopez/
> 
> e-mail: diego.r.lopez@telefonica.com
> Mobile:  +34 682 051 091
> ----------------------------------
> 
> On 13/05/2022, 10:20, "Add on behalf of Eliot Lear" <add-
> bounces@ietf.org on behalf of lear@lear.ch> wrote:
> 
>     Hi,
> 
>     On 05.05.22 21:57, Paul Wouters wrote:
>     > The only real solution I see is one similar to the IKEv2
> split-DNS case,
>     > one where there is basically an authenticated and authorized
>     > provisioning step that enables the user to join an
> "enterprise network"
>     > wich can demand all or a subnet of DNS traffic which the
> user is required
>     > to opt-in to. And even that is tricky when a user is kinda
> forced to
>     > accept to get any connectivity, say in a hotel or coffeeshop
> (or
>     > repressive regime)
> 
>     I think you are aiming at the fundamental problem, Paul: is
> there a way
>     for the user to decide who to trust.  Ben's pointed out the UX
> problems
>     with answering that question.  For enterprise assets that
> clearly has to
>     be the enterprise.  The only question really is how to
> bootstrap trust
>     in the enterprise.  Any draft trying to address split DNS has
> to assume
>     that has happened.  That part can't be in scope here.
> 
>     What this or any draft has to do is be a bit clearer in
> stating that and
>     then show how that bootstrapping of trust is leveraged to
> address split
>     DNS, either via resolver selection at a gross or fine level,
> or through
>     other means.  Right now I think it is trying to demonstrate
> that through
>     multiple mechanisms, and that is what is making things rather
> hard to
>     follow.  That's because there is no one-size-fits-all solution
> because
>     enterprises come in many shapes and forms.  To some, leaking a
> modest
>     amount of NS records is okay.  The pollution argument you
> raise is only
>     relevant in as much as domains outside the enterprise control
> would be
>     polluted.  If that's not the case, then it's a matter for an
> enterprise,
>     and nobody else's business.
> 
>     So I support adoption of this draft, but I do think it needs a
> lot more
>     work to be clearer on the bootstrapping that is occurring.
> 
>     Eliot
> 
> 
> 
> 
> ________________________________
> 
> Este mensaje y sus adjuntos se dirigen exclusivamente a su
> destinatario, puede contener información privilegiada o
> confidencial y es para uso exclusivo de la persona o entidad de
> destino. Si no es usted. el destinatario indicado, queda
> notificado de que la lectura, utilización, divulgación y/o copia
> sin autorización puede estar prohibida en virtud de la legislación
> vigente. Si ha recibido este mensaje por error, le rogamos que nos
> lo comunique inmediatamente por esta misma vía y proceda a su
> destrucción.
> 
> The information contained in this transmission is confidential and
> privileged information intended only for the use of the individual
> or entity named above. If the reader of this message is not the
> intended recipient, you are hereby notified that any
> dissemination, distribution or copying of this communication is
> strictly prohibited. If you have received this transmission in
> error, do not read it. Please immediately reply to the sender that
> you have received this communication in error and then delete it.
> 
> Esta mensagem e seus anexos se dirigem exclusivamente ao seu
> destinatário, pode conter informação privilegiada ou confidencial
> e é para uso exclusivo da pessoa ou entidade de destino. Se não é
> vossa senhoria o destinatário indicado, fica notificado de que a
> leitura, utilização, divulgação e/ou cópia sem autorização pode
> estar proibida em virtude da legislação vigente. Se recebeu esta
> mensagem por erro, rogamos-lhe que nos o comunique imediatamente
> por esta mesma via e proceda a sua destruição
> --
> Add mailing list
> Add@ietf.org
> https://www.ietf.org/mailman/listinfo/add

_________________________________________________________________________________________________________________________

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.