Subject: [Add] The ADD WG has placed draft-box-add-requirements in state "Call For Adoption By WG Issued"

From: IETF Secretariat <[email-masked]>
Date: Wed, 27 Jan 2021 15:16:43 -0800

The ADD WG has placed draft-box-add-requirements in state
Call For Adoption By WG Issued (entered by Glenn Deen)

The document is available at
https://datatracker.ietf.org/doc/draft-box-add-requirements/

Comment:
Based on list and discussion during the January 27th ADD Interim this
document is being put up for call for WG Adoption.

WG Call for adoption is open until February 10th, 2021

---

From: <[email-masked]>
Date: Thu, 28 Jan 2021 13:33:09 +0000

Re-,

I support adoption with the assumption to let it "die" at some point when it achieves its purpose. 

Cheers,
Med

> -----Message d'origine-----
> De : Add [mailto:[email-masked]] De la part de IETF
> Secretariat
> Envoyé : jeudi 28 janvier 2021 00:17
> À : [email-masked]; [email-masked]; draft-box-add-
> [email-masked]
> Objet : [Add] The ADD WG has placed draft-box-add-requirements in
> state "Call For Adoption By WG Issued"
> 
> 
> The ADD WG has placed draft-box-add-requirements in state Call For
> Adoption By WG Issued (entered by Glenn Deen)
> 
> Based on list and discussion during the January 27th ADD Interim
> this document is being put up for call for WG Adoption.
> 
> --
> Add mailing list
> [email-masked]
> 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.

---

From: Chris Box <[email-masked]>
Date: Thu, 28 Jan 2021 14:59:33 +0000

> I support adoption with the assumption to let it "die" at some point when

If "die" means we do not progress to WGLC and submission to IESG, I'm fine
with that. It doesn't need to be an RFC. Its purpose is purely to help the
working group in the development of solutions.

Chris

---

From: Eric Orth <[email-masked]>
Date: Thu, 28 Jan 2021 11:40:21 -0500

I neither support nor oppose adoption, but either way I support continued
work and discussion on the document.

In its current non-adopted status, the document already seems fine at
filling its purpose as a mechanism for helping guide WG direction and
discussions.  I don't see any value in making it "more official" or
anything like that.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 28 Jan 2021 09:48:04 -0800

I am not in favor of adoption. I believe it's served its purpose by helping
to foster discussion, but at this point I think we should focus on the
protocols and I think continued attempts to sharpen the requirements impede
that work.

-Ekr

---

From: Andrew Campling <[email-masked]>
Date: Thu, 28 Jan 2021 20:10:01 +0000

I am in favour of the adoption of this document by the WG and am happy to review/contribute to it as appropriate.  

Andrew

-----Original Message-----
From: IETF Secretariat <[email-masked]> 
Sent: 27 January 2021 23:17
To: [email-masked]; [email-masked]; [email-masked]
Subject: [Add] The ADD WG has placed draft-box-add-requirements in state "Call For Adoption By WG Issued"

The ADD WG has placed draft-box-add-requirements in state Call For Adoption By WG Issued (entered by Glenn Deen)

Comment:
Based on list and discussion during the January 27th ADD Interim this document is being put up for call for WG Adoption.

---

From: "Vinny Parla (vparla)" <[email-masked]>
Date: Thu, 28 Jan 2021 20:17:28 +0000

+1
I also am supportive of adoption of this document and will assist in the
review as needed.
-Vinny

-----Original Message-----
From: Add <[email-masked]> On Behalf Of Andrew Campling
Sent: Thursday, January 28, 2021 3:10 PM
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Add] The ADD WG has placed draft-box-add-requirements in state
"Call For Adoption By WG Issued"

I am in favour of the adoption of this document by the WG and am happy to
review/contribute to it as appropriate.  

Andrew

-----Original Message-----
From: IETF Secretariat <[email-masked]> 
Sent: 27 January 2021 23:17
To: [email-masked]; [email-masked]; [email-masked]
Subject: [Add] The ADD WG has placed draft-box-add-requirements in state
"Call For Adoption By WG Issued"

The ADD WG has placed draft-box-add-requirements in state Call For Adoption
By WG Issued (entered by Glenn Deen)

Comment:

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 28 Jan 2021 20:57:21 +0000

> Call For Adoption By WG Issued (entered by Glenn Deen)

I just had a read.

I'm ambivalent as to whether it ought be adopted. I don't
think it needs to end up as an RFC in either case. I guess
that the WG might have an easier time and be more productive
if it did not need to reach consensus on the text of this
draft. As I'm not sure that the WG needs to reach such a
consensus, in the end I'd be a little bit against
adoption.

If adopted, I will argue that we need a requirement that
clients should to be able to select a recursive based on
the client's evaluation of the network, e.g. I might like
a client that picked a well-known Irish recursive when
the client thinks it is in Ireland but does not pick a
local recursive when the client in in some other locale
renowned for censorship. I think stating such a requirement
would be in scope should this be adopted, whether or not
that leads to a need for some new protocol. (I could
envisage some futures in which some new protocol would
be useful to meet this requirement, perhaps if desirable
recursive locators changed very frequently, but equally
there might not be a need in the end, e.g. if clients tend
to include the required information as part of their install
and updates.)

Cheers,
S.

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 29 Jan 2021 11:26:49 +1100

On Fri, Jan 29, 2021, at 07:57, Stephen Farrell wrote:
> I guess that the WG might have an easier time and be more productive
> if it did not need to reach consensus on the text of this draft. 

This.

We're already past the point of diminishing returns here.  But we're making progress on specifications, and to the extent that this draft has contributed, it's done its job.

---

From: tirumal reddy <[email-masked]>
Date: Fri, 29 Jan 2021 10:48:44 +0530

I support adoption of the draft, it is a good place to discuss evolving use
cases and requirements.

-Tiru

---

From: Chris Box <[email-masked]>
Date: Fri, 29 Jan 2021 11:02:27 +0000

Here's an interesting point we should discuss.

> to include the required information as part of their install

The first thing to say is that this draft is currently only about
discovery, and not selection. And even within the scope of discovery, it
says that

clients may impose arbitrary additional requirements and heuristics as
they see fit

We do need to talk about selection though. Clearly this is also an area
where clients make their own decisions and I don't want to change that.

But I think it's safe to say that in all cases, selection decisions will be
made based on the available data:

   - What the client already knows
   - What the client has learned from the network and the discovery process
   - The results of any additional queries it decides to make (e.g.
   reputation check)
   - Any user input, if it decides to ask

Clearly the network's country can be an important factor in this, as can
the country in which the resolver is located.

As per the other thread, I think the working group does need to start
discussing roughly which categories of information would be useful to
convey to clients as part of their decision-making, although we would not
be allowed to define specifics. Once we have a view on that it would be
desirable to document requirements for the transport of selection
information. This could be added to this draft, or in a new one.

Chris

---

From: Jim Reid <[email-masked]>
Date: Fri, 29 Jan 2021 11:06:05 +0000

I support adoption of this draft.

---

From: Andrew Campling <[email-masked]>
Date: Fri, 29 Jan 2021 11:22:02 +0000

On Fri, 29 Jan 2021 at 11:02, Chris Box <[email-masked]<mailto:[email-masked]>> wrote:

> The first thing to say is that this draft is currently only about discovery, and not selection. And even within the scope of discovery, it says that

> clients may impose arbitrary additional requirements and heuristics as they see fit
> We do need to talk about selection though. Clearly this is also an area where clients make their own decisions and I don't want to change that.
>
> But I think it's safe to say that in all cases, selection decisions will be made based on the available data:

  *   What the client already knows
  *   What the client has learned from the network and the discovery process
  *   The results of any additional queries it decides to make (e.g. reputation check)
  *   Any user input, if it decides to ask
> Clearly the network's country can be an important factor in this, as can the country in which the resolver is located.
>
>As per the other thread, I think the working group does need to start discussing roughly which categories of information would be useful to convey to clients as part of their decision-making, although we would not be allowed to define specifics. Once we have a view on that it would be desirable to document requirements for the transport of selection information. This could be added to this draft, or in a new one.

I agree that server selection would be a good topic to discuss, although the bulk of it may well belong in a second document if it is focused on what information to convey to clients as opposed to the underlying user requirements.  Having some input on context-aware changes to resolver selection may be a useful addition to the user requirements document though, as would input on user requirements for resolver selection where the user is also the network operator (eg enterprise networks where the enterprise also owns the device).

Andrew

---

From: Paul Adair <[email-masked]>
Date: Fri, 29 Jan 2021 16:58:52 +0000

I support adoption of the draft.

---

From: Vittorio Bertola <[email-masked]>
Date: Fri, 29 Jan 2021 18:05:27 +0100 (CET)

> Il 29/01/2021 12:06 Jim Reid <[email-masked]> ha scritto:
> 
>  

I also support adoption of draft-box-add-requirements - clearly there is still consensus to be found on a number of features of these discovery mechanisms, and I think it would be more productive to have an explicit discussion and consensus on which features we want, rather than an implicit discussion whenever some proposed mechanisms expose some features.

-- 
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked] 
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: "Weil, Jason" <[email-masked]>
Date: Fri, 29 Jan 2021 17:38:56 +0000

I support adoption of this draft. It doesn't need to go past adoption but seems proper to agree to work on it. 

Jason

On 1/29/21, 12:06 PM, "Add on behalf of Vittorio Bertola" <[email-masked] on behalf of vittorio.bertola=[email-masked]> wrote:

    CAUTION: The e-mail below is from an external source. Please exercise caution before opening attachments, clicking links, or following guidance.

E-MAIL CONFIDENTIALITY NOTICE: 
The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited.

---

From: "Geist, Dan (CCI-Atlanta)" <[email-masked]>
Date: Fri, 29 Jan 2021 18:41:04 +0000

Thanks.
Dan

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 29 Jan 2021 18:58:19 +0000

I have to admit to being a bit ambivalent, too. This draft has definitely helped frame the discussion. I really appreciate the work that was done on it.
I’m actually not in favor of spending much (or even necessarily any) additional effort on it, but could see some possible value in acknowledging it as a consensus framing of an initial set of use cases and requirements that led to the development of the DEER (DDR?) and RA/DHCP mechanisms. Adoption could provide that sort of acknowledgement, IMO.
However, I would prefer not to use this particular draft as an open-ended collection of use cases and requirements that might lead to additional or different solutions. I’d prefer things like that to come in as individual drafts.
With that said, I’ll admit to being the sort of person who minimizes time spent on analyzing use cases. I find it much easier to discuss specific technical solutions (and outcomes/impacts of specific choices wrt them) than more abstract use cases. And that’s just the way my brain works. I totally appreciate that it’s not how everyone’s brain works. But since there does seem to be widespread agreement that we want to get the DEER and RA/DHCP solutions done ASAP, I’m hoping we can all agree that we should only do more work on the requirements draft right now if we think it’s necessary to get past a hurdle or disagreement in the design of these 2 solutions; in any case, it needs to not slow them down.
Barbara

I neither support nor oppose adoption, but either way I support continued work and discussion on the document.

In its current non-adopted status, the document already seems fine at filling its purpose as a mechanism for helping guide WG direction and discussions.  I don't see any value in making it "more official" or anything like that.

On Wed, Jan 27, 2021 at 6:17 PM IETF Secretariat <[email-masked]<mailto:[email-masked]>> wrote:

The document is available at
https://datatracker.ietf.org/doc/draft-box-add-requirements/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-box-add-requirements/__;!!BhdT!ySu3vgWGh4yHoNq5ooES3Iwi3PlH9hQrHUuPY69yL3nv_qggk_xPti-PFwplxA$>

Comment:

--
Add mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/add<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/add__;!!BhdT!ySu3vgWGh4yHoNq5ooES3Iwi3PlH9hQrHUuPY69yL3nv_qggk_xPti_hOmX-Ng$>