Subject: [Add] My principles for discovery

From: "Martin Thomson" <[email-masked]>
Date: Wed, 25 Mar 2020 15:36:51 +1100

As I raised this in the meeting, I think that it's only fair that I include what I think the principles should be.

In short, I believe that any entity that you interact with should be able to present their views on what resolver you should use.  Client policy will then dictate which - if any - of those is used.  Authentication of the source of these opinions is likely a necessary input for the client policy decision.

It is discussing client policy that has caused us to get into unproductive discussions.  To be clear, I regard the question of whether it is users or the software they choose to run that make policy decisions to be firmly part of this discussion.  We might variously lament the ability of software to properly reflect the wishes of users, but this is not the place to debate that.

That doesn't mean that you should expect the person serving you sausages at a local deli to offer an opinion on what resolver you should use.  But we should look to provide ways in which entities that have some relevant stake to make their opinion known.  As a provider of application software that might be interested in having its own policies, I might expect to receive opinions from the following places:

* The networks that endpoints connect to.
* DNS servers that might be involved in answering queries.
* Other communication endpoints, such as sites or enterprise services, and their representatives, such as CDNs or corporate IT.

These next three might not depend on a protocol that we define here, but we can still recognize that there might be other entities involved in expressing opinions and - for these - even setting policy:

* The operating system configuration.
* Various "owners" or stakeholders for the endpoint, such as an employer or a government (this might not extend all the way to full control of the device MDM-style, but it might still be relevant to the client policy).
* Application configuration.

I don't personally see a lot of value in having entities other than those from the first set of three stand on soapboxes to broadcast their opinions about resolver choice, but there is nothing fundamentally wrong with having other sources of opinions.  So while the IETF could provide more protocols, it's not a good use of our time and resources unless we expect that the information would be acceptable to genuine client policies.

When it comes to setting policy, authentication is important.  When making a decision about whether to use a particular resolver, depending on the policy you have, it might be important that you know whose opinion is guiding the decision.  If you want a server that doesn't store logs of queries for longer than a certain time, then I'm not aware of a technical mechanism for verifying that claim.  You likely have to rely on the assertions of an entity you trust.  Opinions received over the delicatessen counter are unlikely to carry any particular weight.

It was good to see both Tommy and Dan address this question directly; though I'm not sure I totally agree that the right trust anchors were used, building in ways to authenticate an opinion makes it more likely that client policy will allow use of the indicated resolver.

I think that the need to be flexible about authenticity derives largely from the desire to allow networks to have an opinion.  I know of no way to authenticate the output of DHCP or a RA, except to say that this is most likely the provider of the network who is speaking.  That's very weak authentication, so while it carries some weight, it's not a lot.

So, I would suggest that the best we can hope for from this WG is a set of mechanisms that report on resolver options/opinions and some associated information that includes who provided the option/opinion and how.

Cheers,
Martin

p.s., Regarding work on the table, I think that it is clear what the models are driving draft-btw-add-home, draft-peterson-do[th]-dhcp, and draft-pauly-dprive-adaptive-dns-privacy.  I struggle a little with draft-mglt-add-rdp in this regard and I would appreciate a little more clarity about intent.  It is possible that draft-reddy-add-server-policy-selection is firmly in the authentication space, but it seems to be more firmly aimed at communicating policy than I am currently comfortable with right now.

---

From: Vittorio Bertola <[email-masked]>
Date: Wed, 25 Mar 2020 08:32:57 +0100 (CET)

> Il 25/03/2020 05:36 Martin Thomson <[email-masked]> ha scritto:
> 
>  
> In short, I believe that any entity that you interact with should be able to present their views on what resolver you should use.  Client policy will then dictate which - if any - of those is used.

I don't necessarily disagree with the approach, but there is a question to which I need a very convincing answer first.

"Any entity you interact with" already has a way to tell you - even force you - to use a name server they control to effect resolution of their domain names. It's called "authoritative name server".

It seems to me that the model that especially draft-pauly is proposing - i.e. every destination pointing the client to a resolver that the destination controls - is functionally equivalent, in terms of who gets to see which information, to eliminating the concept of an external resolver and having the end-user device implement and run a full resolver on its own.

This, as per Tommy's reply to the question I made at IETF 106, would increase privacy because the resolution process would not provide data to any other party than the "final destination", which would anyway get it when the following HTTPS connection happens. (The fact that the two sets of data are actually the same has been challenged yesterday in the Jabber chat, but that's another discussion.)

I assume that this is also what you are envisaging, since the alternative - every destination pointing the client to a resolver which they don't control, but with which they have commercial or other agreements - opens up the potential for much heavier security threat, centralization and surveillance scenarios than it is ever possible today, so I would expect it to be ruled out much like other out-of-same-origin practices.

So - why do we need to develop all this complex machinery just to let destinations indicate some kind of resolver that does the same thing that their authoritative already does? What's the difference with just implementing a full resolver in the client?

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

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 25 Mar 2020 14:40:33 -0400

On Wed, Mar 25, 2020 at 3:33 AM Vittorio Bertola <vittorio.bertola=
[email-masked]> wrote:

> > As I raised this in the meeting, I think that it's only fair that I
> include what I think the principles should be.
> >
> > In short, I believe that any entity that you interact with should be
> able to present their views on what resolver you should use.  Client policy
> will then dictate which - if any - of those is used.
>
> I don't necessarily disagree with the approach, but there is a question to
> which I need a very convincing answer first.
>
> "Any entity you interact with" already has a way to tell you - even force
> you - to use a name server they control to effect resolution of their
> domain names. It's called "authoritative name server".
>
> It seems to me that the model that especially draft-pauly is proposing -
> i.e. every destination pointing the client to a resolver that the
> destination controls - is functionally equivalent, in terms of who gets to
> see which information, to eliminating the concept of an external resolver
> and having the end-user device implement and run a full resolver on its own.
>
> This, as per Tommy's reply to the question I made at IETF 106, would
> increase privacy because the resolution process would not provide data to
> any other party than the "final destination", which would anyway get it
> when the following HTTPS connection happens. (The fact that the two sets of
> data are actually the same has been challenged yesterday in the Jabber
> chat, but that's another discussion.)
>
> I assume that this is also what you are envisaging, since the alternative
> - every destination pointing the client to a resolver which they don't
> control, but with which they have commercial or other agreements - opens up
> the potential for much heavier security threat, centralization and
> surveillance scenarios than it is ever possible today, so I would expect it
> to be ruled out much like other out-of-same-origin practices.
>

I don't think this is a meaningful distinction.  Authoritative nameserver
operations are commonly outsourced and heavily consolidated today, just as
web hosting is commonly outsourced to large CDNs.  There's certainly no
"out-of-same-origin" rule that prevents using a CDN!

> So - why do we need to develop all this complex machinery just to let
> destinations indicate some kind of resolver that does the same thing that
> their authoritative already does? What's the difference with just
> implementing a full resolver in the client?
>

I actually agree, at least in part: as our proposals develop, we should try
to harmonize them with the work to encrypt recursive->authoritative DNS
queries.  Perhaps we will be able to build encrypted stub, recursive, and
hybrid resolvers from a small set of shared components.

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

---

From: Patrick McManus <[email-masked]>
Date: Wed, 25 Mar 2020 15:00:52 -0400

On Wed, Mar 25, 2020 at 12:37 AM Martin Thomson <[email-masked]> wrote:

>
> In short, I believe that any entity that you interact with should be able
> to present their views on what resolver you should use.  Client policy will
> then dictate which - if any - of those is used.  Authentication of the
> source of these opinions is likely a necessary input for the client policy
> decision.
>
>
I think this is a pretty strong summary and a useful contribution -
thanks!. I might add that their view may include the scope of their
recommendation. (e.g. I'm a general recursive, I'm for this split horizon,
I'm for this authoritative, etc...) and, if we were making mission
statements, emphasize that authentication is something they are implicitly
conveying during presentation (even if its the absence of authentication).

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 25 Mar 2020 16:42:54 -0700

Thanks for this summary, Martin. I completely agree that our focus on discovery as a group needs to be around how the entities a client interacts with offer resolver options to use, along with authentication of these options. The policy decisions of how to use the information is definitionally up to the client, and are not for this group to decide.

I also agree that the entities that might have opinions about resolver selection that are not a client device’s local network, or a server that the device interacts with during usage (such as the OS, application, or MDM configuration) belongs out of scope of any mechanisms we define here. Those boil down to a client policy. I certainly believe that operating systems and applications should be able to implement overriding policies for resolver selection, generally by user opt-in, but such an option is not part of “discovery”.

Any case in which a device dynamically chooses to use a discovered resolver does need to have some sort of authentication. Opinions from entities that the client does not have a relationship with are not useful.

However, when we discuss authentication of the resolver information, we may want to separate out:
- the fact that a given DoT/DoH resolver exists
- the opinion that a client *should* use this resolver for any given queries

I’d posit that the second part here is the more critical to authenticate.

I think any proposal that involves local-network provisioning (be that DHCP, RA, or a local PvD) can only provide the first part of indicating that a given resolver exists. I’d certainly prefer some signaling mechanism that is not too easy to spoof (hence my suggestion for the HTTPS-provided PvD JSON blob), but it’s relatively safe for a client to be aware of a resolver as long as it does not choose to use it until it learns more about it. Some solutions can provide authentication along with initial discovery (DNSSEC signed records, say), but the end set of solutions could include a combination of unauthenticated protocols for discovery that require later confirmation.

Thanks,
Tommy

> On Mar 24, 2020, at 9:36 PM, Martin Thomson <[email-masked]> wrote:
>

---

From: "John Levine" <[email-masked]>
Date: 25 Mar 2020 16:58:44 -0400

>conveying during presentation (even if its the absence of authentication).

This is reminding me of the way people used to build spam filters, and
not in a good way.  When the filters didn't do the right thing with
messages, the nerdy response was to add ever more knobs and buttons
that the users could control to manually adjust the filtering rules.

It didn't work -- most users didn't understand the controls, and for
the ones that did, or thought they did, it was a support nightmare as
they demanded ever more finegrained knobs they could try to tweak.

What everyone does now is to have a very small set of standard
filtering policies that work pretty well, typically one per system or
one per enterprise in shared systems, and to the extent users can
control their filtering, they do it implicitly by putting addresses
they know in their address book and moving messages in and out of the
spam folder.

This isn't a perfect analogy, but I'm quite confident that the fewer
decisions we expect users or their proxies to make, the more likely
this is to work.

R's,
John

---

From: Michael Richardson <[email-masked]>
Date: Thu, 26 Mar 2020 16:45:30 -0400

> include what I think the principles should be.

Thank you.

    > able to present their views on what resolver you should use.  Client
    > policy will then dictate which - if any - of those is used.
    > Authentication of the source of these opinions is likely a necessary
    > input for the client policy decision.

I find this a surprising suggestion.
Will I get different answers if I ask different entities the same question?
This seems to fall into MIF space, and I don't think that you mean to go there.

    > It is discussing client policy that has caused us to get into
    > unproductive discussions.  To be clear, I regard the question of
    > whether it is users or the software they choose to run that make policy
    > decisions to be firmly part of this discussion.  We might variously
    > lament the ability of software to properly reflect the wishes of users,
    > but this is not the place to debate that.

Agreed.

    > That doesn't mean that you should expect the person serving you
    > sausages at a local deli to offer an opinion on what resolver you
    > should use.  But we should look to provide ways in which entities that

Let me expand upon your scenario.

is it: "if you want mustard, you must ask at the counter"
or:    "if you ask at the counter, I'll give you (free) internet"

    > I don't personally see a lot of value in having entities other than
    > those from the first set of three stand on soapboxes to broadcast their
    > opinions about resolver choice, but there is nothing fundamentally
    > wrong with having other sources of opinions.  So while the IETF could
    > provide more protocols, it's not a good use of our time and resources
    > unless we expect that the information would be acceptable to genuine
    > client policies.

Agreed.

    > When it comes to setting policy, authentication is important.  When
    > making a decision about whether to use a particular resolver, depending
    > on the policy you have, it might be important that you know whose
    > opinion is guiding the decision.  If you want a server that doesn't
    > store logs of queries for longer than a certain time, then I'm not
    > aware of a technical mechanism for verifying that claim.

So, to be clear, there is running code for verifying the claim, and a
successful business transaction to do this.
RATS will give us open-standard was to execute the entire stack, but it can
be done in proprietary verticals today with third party auditors.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Thu, 26 Mar 2020 16:49:39 -0400

Vittorio Bertola <vittorio.bertola=[email-masked]> wrote:
    > It seems to me that the model that especially draft-pauly is proposing
    > - i.e. every destination pointing the client to a resolver that the
    > destination controls - is functionally equivalent, in terms of who gets
    > to see which information, to eliminating the concept of an external
    > resolver and having the end-user device implement and run a full
    > resolver on its own.

+1.
Linking against libunbound is already a thing.  You get DNSSEC too.
We used centralized resolvers because of too little ram, and to enable
caching.

The issue that I see are:
  1) so-called "DNS" firewalls, which are imposed as a condition of internet.
     Determining how/if/when we trust them.

  2) IoT devices which have user, and which might really not have enough ram.

While there are split-horizon DNS issues that many organizations deploy
regularly, I think that they architectural concept is old, stale and broken.
IPv6 provides better mechanisms, and we should recommend them.

---

From: Daniel Migault <[email-masked]>
Date: Thu, 26 Mar 2020 20:09:48 -0400

On Wed, Mar 25, 2020 at 12:37 AM Martin Thomson <[email-masked]> wrote:

> It is discussing client policy that has caused us to get into unproductive
> discussions.  To be clear, I regard the question of whether it is users or
> the software they choose to run that make policy decisions to be firmly
> part of this discussion.  We might variously lament the ability of software
> to properly reflect the wishes of users, but this is not the place to
> debate that.
>
>  <mglt>
I think I also agree. The policy should in theory be independent
from the application enforcing that policy. The problem is that a
formal definition of what such policy is likely to never be defined,
and as such a large part of it will be defined by the
application. For that reason, the policy is likely be represented
by the application itself. In other words, not everything is being
configured by the end user and we assume the application
reflects the end user policy. - this also suppose the end user
will have the choice between different applications.

That said, the policy enforced by the application may involve
some interaction of the end user during the selection process. I
also believe that some means may be provided so the application
may notify the end user of the resulting selection.
</mglt>

 That doesn't mean that you should expect the person serving you sausages
> at a local deli to offer an opinion on what resolver you should use.  But
> we should look to provide ways in which entities that have some relevant
> stake to make their opinion known.  As a provider of application software
> that might be interested in having its own policies, I might expect to
> receive opinions from the following places:
>
> * Other communication endpoints, such as sites or enterprise services, and
> their representatives, such as CDNs or corporate IT.
>
>  <mglt>
The end user may have a say in the selection process.  I agree
that interaction with the end user should be limited and that
such interaction is up to the application performing the
selection. It thus sounds to me that some election parameter
should be designed to be presented to the end user. I also do not
think we should go much further than a UTF8 string.
The scenarios I would envision is that a list of resolvers is
proposed to the end user. Another thing is that when one resolver
is chosen or changed, the end user may be notified of that
change or selection.

I am unsure I clearly get the third bullet. I understand it
includes things such as:
* some configuration parameters to perform some resolutions over
* a specific resolver a web site to advertise a preferred
* resolver.
</mglt>
>
> These next three might not depend on a protocol that we define here, but
> we can still recognize that there might be other entities involved in
> expressing opinions and - for these - even setting policy:
>
> * Various "owners" or stakeholders for the endpoint, such as an employer
> or a government (this might not extend all the way to full control of the
> device MDM-style, but it might still be relevant to the client policy).
 <mglt>
I would see those entities as being able to configure/provide
information to the application that proceed to the selection.
</mglt>

> I don't personally see a lot of value in having entities other than those
> from the first set of three stand on soapboxes to broadcast their opinions
> about resolver choice, but there is nothing fundamentally wrong with having
> other sources of opinions.  So while the IETF could provide more protocols,
> it's not a good use of our time and resources unless we expect that the
> information would be acceptable to genuine client policies.
>
> When it comes to setting policy, authentication is important.  When making
> a decision about whether to use a particular resolver, depending on the
> policy you have, it might be important that you know whose opinion is
> guiding the decision.  If you want a server that doesn't store logs of
> queries for longer than a certain time, then I'm not aware of a technical
> mechanism for verifying that claim.  You likely have to rely on the
> assertions of an entity you trust.  Opinions received over the delicatessen
> counter are unlikely to carry any particular weight.
>
>  <mglt>
I believe the end user may decide to trust the delicateness
counter more than other ways. Think of an IETF meeting happening
nearby the deli. I am not convinced it is an easy problem to
select what the end user trust.
</mglt>

 It was good to see both Tommy and Dan address this question directly;
> though I'm not sure I totally agree that the right trust anchors were used,
> building in ways to authenticate an opinion makes it more likely that
> client policy will allow use of the indicated resolver.
>
> I think that the need to be flexible about authenticity derives largely
> from the desire to allow networks to have an opinion.  I know of no way to
> authenticate the output of DHCP or a RA, except to say that this is most
> likely the provider of the network who is speaking.  That's very weak
> authentication, so while it carries some weight, it's not a lot.
>
>  <mglt>
I think RFC3971 and RFC3118 are at least an attempt to provide
authentication. I am unaware of large deployment of these
mechanisms. DHCP / RA may provide  an IP address without
authentication, but this could be used as an hint to retrieved
authenticated information. If DHCP/RA is being spoofed, this may
end up in the resolver you connect NOT being the one proposed by
the ISP, but at least upon the selection you can trust who you
are connected to.
</mglt>

>  So, I would suggest that the best we can hope for from this WG is a set
> of mechanisms that report on resolver options/opinions and some associated
> information that includes who provided the option/opinion and how.
>
>  <mglt>
I agree.
</mglt>

 Cheers,
> Martin
>
> p.s., Regarding work on the table, I think that it is clear what the
> models are driving draft-btw-add-home, draft-peterson-do[th]-dhcp, and
> draft-pauly-dprive-adaptive-dns-privacy.  I struggle a little with
> draft-mglt-add-rdp in this regard and I would appreciate a little more
> clarity about intent.

<mglt>
I am happy to clarify anything that does not appear to be clear.

The intent is (limited) to enable the discovery resolving services
available.
All resolving services provided by example.com are listed under
_dns.example.com and selection parameters are provided through SVCB RRsets.

Since you need example.com to start the discovery, we define a repo that
contains resolving domain the dns client may consider for global resolver.
We
also define a possible way to derive the resolving domain from the local
resolver advertised by the DHCP RA.

Other ways may be defined to communicate resolving domains (DHCP
for example)

Currently the resolving domain take part of the selection by only providing
a
preference on the resolving service.

Since DNS is used to carry this information it may be requested by a dns
client
or eventually provided as additional data by a resolver the dns client
interacts with.

</mglt>

> It is possible that draft-reddy-add-server-policy-selection is firmly in
> the authentication space, but it seems to be more firmly aimed at
> communicating policy than I am currently comfortable with right now.
>
> --
> Add mailing list
> [email-masked]

-- 
Daniel Migault
Ericsson

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 27 Mar 2020 11:44:58 +1100

Thanks for the question.  I agree that this is hard.

On Wed, Mar 25, 2020, at 18:32, Vittorio Bertola wrote:
> "Any entity you interact with" already has a way to tell you - even 
> force you - to use a name server they control to effect resolution of 
> their domain names. It's called "authoritative name server".

This is a good point.  I hesitated before adding this to the list, because I get your point.  What Tommy proposes does look quite a bit like having the client perform recursion itself with different spelling.

But I don't think that is precisely what is being proposed, nor does it have to be designed precisely that way.  For instance, it is conceivable that I might interact with example.com and have it say things about what resolver to use for example.net without following the delegation path (and the DNSSEC chain) from the root.  A client policy in which that is permissible isn't totally implausible.

I don't think that is exactly what Tommy presented and I'm not trying to speak for that group of authors.  I'm trying to be inclusive here and allow for their design and variations on the same.  Because these are entities that *might* have a stake in the success of the eventual interaction that DNS is facilitating.  That is all.

> I assume that this is also what you are envisaging, since the 
> alternative - every destination pointing the client to a resolver which 
> they don't control, but with which they have commercial or other 
> agreements - opens up the potential for much heavier security threat, 
> centralization and surveillance scenarios than it is ever possible 
> today, so I would expect it to be ruled out much like other 
> out-of-same-origin practices.

See, I think that this line of argumentation is firmly out of scope for this group.  I think that it is fine to express your opinions about what policies a client might consider as valid, and to factor those things you identify into how those opinions are formed, but this group is setup specifically not to contemplate that.  Finding ways to express how those opinions manifest within the scope of this group's charter is what we need to try to do.  Which is awkward, but thank you for doing that here:

> destinations indicate some kind of resolver that does the same thing 
> that their authoritative already does? What's the difference with just 

Yes, this is the right question to ask, and totally within scope.  I too am not entirely convinced in the value of the complexity trade-off in the specific case you cited, but I also don't know that I really understand how this works from a hollistic perspective either.  I find the idea that I might allow Google (for example) to point me at 8.8.8.8 for the purposes of name resolutions I make within the context of my interactions with Google of interest.

Of perhaps more interest, is extending that to third party resources that are involved in the same interaction as that might allow for better scoping of how information about my DNS interactions is distributed, to go back to the resolver selection motivation.  I think that it is also has some potential pitfalls in that setup, particularly as it pertains to the distribution of information about individuals and their interests.

But that does mean - at least for me - that there is a policy that leads to something like what Tommy proposes, which might in turn motivate this group to consider designing a mechanism.  And that policy is at least plausible.

That's the careful balance this group has: we can't talk about policies because we know we don't all agree.  But we really need to understand whether there is some motivation for doing the work that is at least plausible.

This is likely a question for chairs, but if we want to avoid the policy discussions, maybe they would prefer to say that as long as there is sufficient interest then work might proceed rather than trying to avoid objections.  Or at least avoiding objections on policy grounds, because there are objections that are in scope and derive from things outside of the contested policy questions.

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 27 Mar 2020 12:06:09 +1100

On Thu, Mar 26, 2020, at 06:00, Patrick McManus wrote:
> recommendation. (e.g. I'm a general recursive, I'm for this split 
> horizon, I'm for this authoritative, etc...) and, if we were making 
> mission statements, emphasize that authentication is something they are 
> implicitly conveying during presentation (even if its the absence of 
> authentication).

I agree about scope.  Though the client might reach different conclusions about what of that scope they want to use. :)

The authentication question seems like it might depend on context.  If you think of an HTTP server that says "use this resolver when you talk to me if you like", then that authentication might be implicit.  But Tommy's presentation relied on authentication via DNSSEC for some sort of delegation record.  That seems like it might not be explicit.

---

From: "Ralf Weber" <[email-masked]>
Date: Fri, 27 Mar 2020 10:56:45 +0100

On 27 Mar 2020, at 1:44, Martin Thomson wrote:
> Yes, this is the right question to ask, and totally within scope.  I 
> too am not entirely convinced in the value of the complexity trade-off 
> in the specific case you cited, but I also don't know that I really 
> understand how this works from a hollistic perspective either.  I find 
> the idea that I might allow Google (for example) to point me at 
> 8.8.8.8 for the purposes of name resolutions I make within the context 
> of my interactions with Google of interest.
Except that you have no idea when you interact with Google. When you go 
to a website these days (e.g nytimes.com - just tested this now, but 
most sites are the same or similar) you without knowing and without 
being warned (GDPR warning) already have interacted with Google. So that 
is why even for stuff that wants to interact with Google I want them to 
go to my resolver so that I can block it there.

Now I understand that there are other scenarios where distributing 
traffic might better from a privacy perspective, but we should make sure 
that whatever we do we come up with something that allows different ways 
to solve this, which IMHO Tommys draft does.

So long
-Ralf
—--
Ralf Weber

---

From: Vittorio Bertola <[email-masked]>
Date: Fri, 27 Mar 2020 12:10:27 +0100 (CET)

> Il 27/03/2020 01:44 Martin Thomson <[email-masked]> ha scritto:
> 

I don't disagree, but the problem is that discovery mechanisms are a tool to implement deployment models, which shape their requirements. But deployment models have policy consequences, some intended and some not, which once understood lead to adding features and fixes to them, which in turn need to be supported by the discovery mechanism.

So the logical order to proceed would be to imagine a deployment model, to discuss collectively its policy implications, to come to reasonable bottom-up agreement (or final disagreement) on possible mitigations, and then to design and implement a discovery mechanism that supports all that. But we cannot do that because we don't have a venue for policy discussions, and even if we had it, the discussion would take much longer than agreeing on technical specs, and could fail altogether.

So, I agree that this is not the right venue for that, but I do think that some policy discussion now, even if hard, would save us much bigger arguments later, especially with people outside of this process.

Also, we might think that we may solve the issue by designing such an open, general and extensible discovery mechanism that it can support each and every conceivable deployment model. However, that could just be wishful thinking, and it might also set the group for a very long technical odyssey before getting anywhere.

> This is likely a question for chairs, but if we want to avoid the policy discussions, maybe they would prefer to say that as long as there is sufficient interest then work might proceed rather than…

A "live and let live" principle could be good: different sub-groups could work on different discovery mechanisms that suit different deployment models, which will all be standardized provided that they are technically sound.

However, I do see a problem: can you really tell technical objections from policy objections? People that don't like other people's deployment models might start to claim that their objection is technical and thus in scope. The first example I can think of: there are people that would like to just add a new option to DHCP and advertise their DoH/DoT resolver there, as they think that the level of security provided today by DHCP is sufficient; others think that this would be too insecure, and object to that mechanism on those grounds. Is that a technical or a policy objection?

--