Subject: Re: [Add] ADD Calls for WF Adoption

From: "Vinny Parla (vparla)" <[email-masked]>
Date: Mon, 1 Nov 2021 13:31:49 +0000

Hi,
I think there are a number of Enterprise use cases, including VPN/RA scenarios, that are driven by domain-based split-tunnel policies not IP policies, that could potentially benefit from this proposal.

I have not seen any other proposals that help in this area. 

-Vinny

-----Original Message-----
From: Add <[email-masked]> On Behalf Of Tommy Pauly
Sent: Sunday, October 31, 2021 4:22 PM
To: Geoff Huston <[email-masked]>
Cc: Eric Rescorla <[email-masked]>; [email-masked]; Deen, Glenn <Glenn_Deen=[email-masked]>
Subject: Re: [Add] ADD Calls for WF Adoption

> On Oct 31, 2021, at 12:17 PM, Geoff Huston <[email-masked]> wrote:
> 
> Hi Eric,
> 
> So here we are in a call as to whether documents should be discussed by the WG and we are doing just that. Seems to me that the adoption question is already answered.
> 
> No, I do not believe that WG adoption means that the document describes a good idea nor one that is going to lead to some published document(s). It means that a bunch of folk want to talk about it and discuss their various interpretations of the concepts exposed in the document(s). It may lead somewhere. Or it may be a set of terrible ideas and lead nowhere. And that’s fine. WG Adoption is not an endorsement of the concepts, nor should it ever be.
> 
> I support DISCUSSING these draft. I don’t necessarily agree with the draft, nor can I (or anyone else for that matter) claim that the WG “supports” these drafts until the WG discusses them. I don’t support peremptorily stopping discussion of these drafts by not adopting these document. It appears that they are in scope for the WG’s area of study, and I that’s a reasonable position to support adoption by the WG group.

On the case of the split-DNS document, I think the main crux of the issue is how a network establishes ownership over a domain in a way that clients can trust, and should trust more than other alternatives. That might be something that’s in scope if we discuss it, but I’m seriously wondering if that is a bigger problem that needs a more general mechanism that just what’s used for bootstrapping an encrypted resolver (the topic of ADD). I think having these private-scoped PvDs is quite interesting, but given that a lot of work was done for PvDs elsewhere (like in intarea), it may be that this mechanism mainly belongs in another group or a new group entirely. That’s the kind of discussion that’s useful to have prior to adoption. 

Thanks,
Tommy 
> 
> regards,
> 
>   Geoff
> 
> 
> 
> 
> 
>> On 29 Oct 2021, at 3:11 pm, Eric Rescorla <[email-masked]> wrote:
>> 
>> Hi Glenn,
>> 
>> Let me start by saying that I don't agree with a number of your 
>> assertions here, in particular about the requirements for adoption. 
>> While it's not *simply* a matter of numbers, having a reasonable 
>> level of support is in fact necessary for consensus.
>> 
>> However, before we debate those, let's start by getting to common 
>> facts. I believe Tommy wrote you with concerns about both drafts, but 
>> let's start with draft-boucadair-add-deployment-considerations.
>> 
>> I have provided you with a list of the people expressing each 
>> position. Your message lists Jim Reid and Diego Lopez.  I am unable 
>> to find a message indicating support for this draft from Diego though 
>> did find one from Jim Reid. However, in that search I also find a 
>> message somewhat opposing adoption from Martin Thomson (I belive he 
>> is opposed so I'm sure I can arrange for a more direct message if you like).
>> 
>> So, can you please provide links to the messages from people who are 
>> in support of this draft?
>> 
>> -Ekr
>> 
>> On Tue, Oct 12, 2021 at 8:57 AM Deen, Glenn <Glenn_Deen=[email-masked]> wrote:
>> Hi ADD,
>> 
>> 
>> 
>> I wanted to bring to the ADD Group’s attention that 2 documents have entered into CALL for WG Adoption in the last couple of days:
>> 
>> 
>> 
>> 
>> 
>>    • Draft-reddy-add-enterprise-split-dns   https://datatracker.ietf.org/doc/draft-reddy-add-enterprise-split-dns/
>> 
>> 
>>    • Draft-boucadair-add-deployment-considerations 
>> https://datatracker.ietf.org/doc/draft-boucadair-add-deployment-consi
>> derations/
>> 
>> 
>> 
>> 
>> 
>> 
>> Both drafts are material that has had good discussion both on list and during past ADD meetings so please consult the archive and meeting minutes, especially IETF110 and IETF111 if you need additional background.
>> 
>> 
>> 
>> Both are in a 2 week call for adoption, with the first ending on Oct 26,2021 and the second on Oct 27,2021.
>> 
>> 
>> 
>> Please respond on list with comments on these calls.
>> 
>> 
>> 
>> Regards
>> 
>> Glenn
>> 
>> --
>> Add mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/add
>> --
>> Add mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/add
> 
> --
> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add

--
Add mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/add

---

From: Daniel Migault <[email-masked]>
Date: Tue, 2 Nov 2021 10:56:06 -0400

I support -deployment-considerations adoption so guidance be provided
regarding the deployment and usage of anr/ddr for internet providers.
Similarly, I -enterprise-split-dns addresses a common scenario and
discussions/clarification for a scenario will be welcome. As such I also
support the adoption of the document.

Yours,
Daniel

On Mon, Nov 1, 2021 at 9:32 AM Vinny Parla (vparla) <vparla=
[email-masked]> wrote:

> Hi,
> I think there are a number of Enterprise use cases, including VPN/RA
> scenarios, that are driven by domain-based split-tunnel policies not IP
> policies, that could potentially benefit from this proposal.
>
> > So here we are in a call as to whether documents should be discussed by
> the WG and we are doing just that. Seems to me that the adoption question
> is already answered.
> >
> > No, I do not believe that WG adoption means that the document describes
> a good idea nor one that is going to lead to some published document(s). It
> means that a bunch of folk want to talk about it and discuss their various
> interpretations of the concepts exposed in the document(s). It may lead
> somewhere. Or it may be a set of terrible ideas and lead nowhere. And
> that’s fine. WG Adoption is not an endorsement of the concepts, nor should
> it ever be.
> >
> > I support DISCUSSING these draft. I don’t necessarily agree with the
> draft, nor can I (or anyone else for that matter) claim that the WG
> “supports” these drafts until the WG discusses them. I don’t support
> peremptorily stopping discussion of these drafts by not adopting these
> document. It appears that they are in scope for the WG’s area of study, and
> I that’s a reasonable position to support adoption by the WG group.
>
> On the case of the split-DNS document, I think the main crux of the issue
> is how a network establishes ownership over a domain in a way that clients
> can trust, and should trust more than other alternatives. That might be
> something that’s in scope if we discuss it, but I’m seriously wondering if
> that is a bigger problem that needs a more general mechanism that just
> what’s used for bootstrapping an encrypted resolver (the topic of ADD). I
> think having these private-scoped PvDs is quite interesting, but given that
> a lot of work was done for PvDs elsewhere (like in intarea), it may be that
> this mechanism mainly belongs in another group or a new group entirely.
> That’s the kind of discussion that’s useful to have prior to adoption.
>
> Thanks,
> Tommy
> >
> > regards,
> >
> >   Geoff
> >
> >
> >
> >
> >
> >> I wanted to bring to the ADD Group’s attention that 2 documents have
> entered into CALL for WG Adoption in the last couple of days:
> >>
> >>
> >>
> >>
> >>
> >>    • Draft-reddy-add-enterprise-split-dns
> https://datatracker.ietf.org/doc/draft-reddy-add-enterprise-split-dns/
> >>
> >>
> >> Both drafts are material that has had good discussion both on list and
> during past ADD meetings so please consult the archive and meeting minutes,
> especially IETF110 and IETF111 if you need additional background.
> >>
> >>
> >>

-- 
Daniel Migault
Ericsson