Re: [dns-privacy] Datatracker State Update Notice: <draft-ietf-dprive-rfc7626-bis-04.txt>

[Brian Dickson <[e-mail]>]

On Mon, Mar 9, 2020 at 1:14 PM Eric Rescorla <[e-mail]> wrote:

>
>
> On Mon, Mar 9, 2020 at 12:18 PM Brian Dickson <
> [e-mail]> wrote:
>
>>
>>
>> On Mon, Mar 9, 2020 at 8:01 AM Eric Rescorla <[e-mail]> wrote:
>>
>>>
>>>
>>> On Mon, Mar 9, 2020 at 3:55 AM Sara Dickinson <[e-mail]> wrote:
>>>
>>>>
>>>>
>>>> On 6 Mar 2020, at 13:32, Eric Rescorla <[e-mail]> wrote:
>>>>
>>>>
>>>>
>>>> On Mon, Mar 2, 2020 at 7:16 AM Sara Dickinson <[e-mail]> wrote:
>>>>
>>>>>
>>>>>
>>>>> On 29 Feb 2020, at 02:03, Eric Rescorla <[e-mail]> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Feb 28, 2020 at 4:50 PM Brian Dickson <
>>>>> [e-mail]> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Feb 28, 2020 at 3:15 PM Eric Rescorla <[e-mail]> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Feb 26, 2020 at 6:19 AM Sara Dickinson <[e-mail]>
>>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 23 Jan 2020, at 13:53, Eric Rescorla <[e-mail]> wrote:
>>>>>>>>
>>>>>>>> On Thu, Jan 23, 2020 at 5:08 AM Sara Dickinson <[e-mail]>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 20 Jan 2020, at 22:37, Eric Rescorla <[e-mail]> wrote:
>>>>>>>>
>>>>>>>> Review comments attached:
>>>>>>>>
>>>>>>>>
>>>>>>>> COMMENTS
>>>>>>>>> S 3.1.
>>>>>>>>> >      described above, and may not have any confidentiality
>>>>>>>>> requirements.
>>>>>>>>> >      However, the same is not true of a single transaction or a
>>>>>>>>> sequence
>>>>>>>>> >      of transactions; that transaction is not / should not be
>>>>>>>>> public.  A
>>>>>>>>> >      typical example from outside the DNS world is: the web site
>>>>>>>>> of
>>>>>>>>> >      Alcoholics Anonymous is public; the fact that you visit it
>>>>>>>>> should not
>>>>>>>>> >      be.
>>>>>>>>>
>>>>>>>>> Well, technically what you want to conceal is the origin of the
>>>>>>>>> transaction or its linkage to other transactions. The existence of
>>>>>>>>> the
>>>>>>>>> query for that A record isn't secret.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Suggest:
>>>>>>>>>
>>>>>>>>> “that transaction (and specifically the origin of that
>>>>>>>>> transaction) is not / should not be public."
>>>>>>>>>
>>>>>>>>
>>>>>>>> The parenthetical swallows the main sentence. The accurate thing to
>>>>>>>> say is:
>>>>>>>>
>>>>>>>> In general, the existence of a single query is not sensitive --
>>>>>>>> though there may be exceptions
>>>>>>>> for some very low use domains. However, the origin of a given query
>>>>>>>> may leak information
>>>>>>>> about specific users and the ability to link queries reveals
>>>>>>>> information about individual use
>>>>>>>> patterns.
>>>>>>>>
>>>>>>>>
>>>>>>>> To fit with existing text suggest:
>>>>>>>>
>>>>>>>>  However, the same is not true of a single transaction or a sequence
>>>>>>>>  of transactions; those transaction are not / should not be public.
>>>>>>>> A single
>>>>>>>>  transactions reveals both the originator of the query and the
>>>>>>>> query
>>>>>>>>  contents which potentially leaks sensitive information about a
>>>>>>>> specific user. A
>>>>>>>>  typical example from outside the DNS world is: the web site of
>>>>>>>>  Alcoholics Anonymous is public; the fact that you visit it should
>>>>>>>> not
>>>>>>>>  be.
>>>>>>>>
>>>>>>>
>>>>>>> I find this text a bit clumsy, but OK.
>>>>>>>
>>>>>>>
>>>>>>> Furthermore, the ability to link queries reveals information about
>>>>>>>> individual use patterns.
>>>>>>>>
>>>>>>>
>>>>>>> The key thing is "link queries as being from the same user”
>>>>>>>
>>>>>>
>>>>> OK - will include that.
>>>>>
>>>>>
>>>>>
>>>>>>>
>>>>>>>> <snip>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> S 3.4.2.
>>>>>>>>> >      services available.  Given this, the choice of a user to
>>>>>>>>> configure a
>>>>>>>>> >      single resolver (or a fixed set of resolvers) and an
>>>>>>>>> encrypted
>>>>>>>>> >      transport to use in all network environments can actually
>>>>>>>>> serve to
>>>>>>>>> >      identify the user as one that desires privacy and can
>>>>>>>>> provide an
>>>>>>>>> >      added mechanism to track them as they move across network
>>>>>>>>> >      environments.
>>>>>>>>>
>>>>>>>>> I don't understand this paragraph. It's not the choice of specific
>>>>>>>>> resolvers that leaks data, but the choice to turn on encryption, In
>>>>>>>>> fact, from an identification purpose, the more resolvers that
>>>>>>>>> support
>>>>>>>>> encrypted transport, the better signal this is.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> This was driven by an observation that many early adopters set up
>>>>>>>>> their own DoT server and used that from all their devices, which could act
>>>>>>>>> as a way to identify that user.
>>>>>>>>>
>>>>>>>>
>>>>>>>> 1. This seems like an edge case.
>>>>>>>> 2. We already have plenty of people running their own unencrypted
>>>>>>>> resolvers for other reasons.
>>>>>>>>
>>>>>>>>
>>>>>>>> I can live with removing this text, but it does seem there is
>>>>>>>> something to say about the fact configuring a single resolver for a device
>>>>>>>> could differentiate a user….
>>>>>>>>
>>>>>>>
>>>>>>> Sure, but this has nothing to do with DoH or DoT.
>>>>>>>
>>>>>>>
>>>>>> I think the text might be clearer if the bit "as one that desires
>>>>>> privacy and" were removed.
>>>>>> The issue isn't whether a specific user desires privacy, it is
>>>>>> whether a specific user can be identified and tracked.
>>>>>>
>>>>>> This RFC update, is about privacy.
>>>>>> This particular section is on encrypted transport.
>>>>>> This paragraph is highlighting that configuring a static list of
>>>>>> resolvers, even if those use encrypted transport, may expose the user to
>>>>>> privacy risks due to that constant set of resolvers, as the user moves
>>>>>> between networks.
>>>>>> And this risk is inversely proportional to the number of users of the
>>>>>> resolver.
>>>>>> Maybe this last bit needs to be added to emphasis why this is a risk?
>>>>>>
>>>>>> It's about the fact that DoH/DoT don't protect against this or
>>>>>> mitigate it, even if the payload is encrypted. I.e. it doesn't not have
>>>>>> anything to do with DoH/DoT; it's bigger than DoH/DoT, and DoH/DoT don't
>>>>>> fix the problem.
>>>>>>
>>>>>
>>>>> Yes, I agree with that, but this risk is generic to DNS even if you
>>>>> use your own resolver (e.g., pihole) which we know people do. Therefore it
>>>>> does not belong in this section as a risk of DoH/DoT..
>>>>>
>>>>>
>>>>> I think the more general case is alluded to in the forth bullet point
>>>>> of section 3.4.1 without being called out specifically….
>>>>>
>>>>> One option would be update the first sentence of that bullet point to
>>>>> say “The recursive resolver can be a public DNS service (or a privately run
>>>>> DNS resolver hosted on the public internet).” and to add the following
>>>>> sentence to the end of the bullet point
>>>>>
>>>>> “It can be noted that the choice of a user to configure a single
>>>>> resolver (even when using an encrypted transport) can actually serve to aid
>>>>> tracking of that user as they move across network  environments."
>>>>>
>>>>> Then remove the fifth paragraph from section 3.4.2?
>>>>>
>>>>
>>>> This seems close.
>>>>
>>>> "It can be noted that if the user selects a single infrequently used
>>>> resolver (even when using an encrypted transport) it can actually serve to
>>>> aid tracking of that user as they move across network  environment"
>>>>
>>>> I think we can agree that using Google Public DNS probably doesn't have
>>>> this property.
>>>>
>>>>
>>>> Agreed - I might say ’selects a single resolver with a small client
>>>> population (even when….’ just to make clear the infrequent usage relates to
>>>> number of clients not query rate :-)
>>>>
>>>>
>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> S 3.5.1..1.2.
>>>>>>>>> >
>>>>>>>>> >      o  communicate clearly the change in default to users
>>>>>>>>> >
>>>>>>>>> >      o  provide configuration options to change the default
>>>>>>>>> >
>>>>>>>>> >      o  provide configuration options to always use the system
>>>>>>>>> resolver
>>>>>>>>>
>>>>>>>>> I get that you think this is neutral, but all of this is equally
>>>>>>>>> true
>>>>>>>>> about dynamic discovery via DHCP, it's just that that's the status
>>>>>>>>> quo, so you don't notice it. In this context, this text is
>>>>>>>>> tendentious.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The first paragraph of section 3.5.1.1 talks about the variability
>>>>>>>>> of DNS resolution privacy with network (assuming DHCP). I can add some text
>>>>>>>>> there to better explain the status quo if you think it is needed. Suggest:
>>>>>>>>>
>>>>>>>>> “Typically joining a new network requires some form of user action
>>>>>>>>> (e.g physically plugging in a cable or selecting a network in a OS
>>>>>>>>> dialogue) and so a user is also implicitly choosing to use the
>>>>>>>>> DHCP-provided resolver via this action too."
>>>>>>>>>
>>>>>>>>
>>>>>>>> The user has no idea that such a DHCP resolver even exists. And you
>>>>>>>> could say the same thing about the user's choice to install an application
>>>>>>>> with its own resolver selection logic.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> I can’t think of a mobile or desktop OS that doesn’t allow users
>>>>>>>>> to override the DHCP provided DNS settings…. but I could text about that in
>>>>>>>>> section 5.1.1. if you really think it is needed?
>>>>>>>>>
>>>>>>>>
>>>>>>>> This isn't about that. AFAICT most major applications also allow
>>>>>>>> you to use the system resolver choices. Rather, the issue here is the
>>>>>>>> repeated arguments in this discussion (which you implicitly accept above)
>>>>>>>> that the current status quo somehow represents user choice whereas an
>>>>>>>> application choosing its own resolver does not. And both this text and your
>>>>>>>> proposed text implicitly takes a position on that.
>>>>>>>>
>>>>>>>>
>>>>>>>> I think that is reading quite a bit into the text however, to
>>>>>>>> reduce any implicit misinterpretation I propose trying to further align the
>>>>>>>> two sections…
>>>>>>>>
>>>>>>>> 1) Replace the first paragraph in section 3.5.1.1 with the
>>>>>>>> following:
>>>>>>>>
>>>>>>>> "Given all the above considerations, the choice of recursive
>>>>>>>> resolver has direct privacy considerations for end users.  Historically,
>>>>>>>> end user devices have used the DHCP-provided local network recursive
>>>>>>>> resolver. Because of this, the choice by a user to join a particular
>>>>>>>> network  (e.g. by physically plugging in a cable or selecting a network in
>>>>>>>> a OS dialogue) also determines the default system DNS resolver selection;
>>>>>>>> the two are directly coupled in this model.
>>>>>>>>
>>>>>>>> The vast majority of users do not change their default system DNS
>>>>>>>> settings and so implicitly accept the network settings for DNS. The network
>>>>>>>> resolvers have therefore historically been the sole destination for all of
>>>>>>>> the DNS queries from a device. These resolvers may have strong, medium, or
>>>>>>>> weak privacy policies depending on the network.  Privacy policies for these
>>>>>>>> servers may or may not be available and users need to be aware that privacy
>>>>>>>> guarantees will vary with network.
>>>>>>>>
>>>>>>>> All major OS’s expose the system DNS settings and allow users to
>>>>>>>> manually override them if desired.”
>>>>>>>>
>>>>>>>>
>>>>>>>> 2) And replace the second paragraph of 3.5.1.1.2  with this:
>>>>>>>>
>>>>>>>> "Such application-specific settings introduce new control points on
>>>>>>>> end user devices for DNS resolution settings in addition to the
>>>>>>>> historically used system settings discussed in Section 3.5.1.1. They
>>>>>>>> therefore alter the DNS privacy considerations for the device by
>>>>>>>> introducing additional destinations for DNS queries.
>>>>>>>>
>>>>>>>> Users will only be aware that a new control point (with new
>>>>>>>> defaults) exists if an application clearly communicates this to the user on
>>>>>>>> install or upgrade.
>>>>>>>>
>>>>>>>
>>>>>>> This reflects status quo bias. If you want to say this, then you
>>>>>>> need to point out that essentially no OS clearly communicates that it is
>>>>>>> selecting the DHCP resolver.
>>>>>>>
>>>>>>
>>>>>> IMHO, this is fair, and probably adds a bit of clarity; perhaps some
>>>>>> wordsmithing on the start of 3.5.1.1 would benefit both this and other
>>>>>> subsections of 3.5.1.1.
>>>>>> Suggestion:
>>>>>>
>>>>>> Old: "Historically, end user devices have used the DHCP-provided
>>>>>> local network recursive resolver, which may have strong, medium, or
>>>>>> weak privacy policies depending on the network."
>>>>>>
>>>>>> New: "Historically, end user devices have used the OS-selected
>>>>>> recursive resolver, whose identity is not exposed or discoverable.
>>>>>> The OS may have been configured with a static set of resolvers, or may use
>>>>>> a DHCP-provided local network resolver. This OS-selected resolver may have
>>>>>> strong, medium, or weak privacy policies, which for DHCP provided resolvers
>>>>>> may depend on the network."
>>>>>>
>>>>>> The gist of this is, over-riding the default has effects that the
>>>>>> application cannot know, because the OS resolver choice is generally not
>>>>>> known, and by extension, the privacy policies cannot be known.
>>>>>>
>>>>>
>>>>> I don't believe this is accurate. In general there are (not that
>>>>> portable) mechanisms for determining the DNS configuration, as is done in
>>>>> Chromium:
>>>>>
>>>>> https://cs.chromium.org/chromium/src/net/dns/?sq=package:chromium&dr=CSs&g=0
>>>>>
>>>>>
>>>>> I’m fine with Ekr’s original suggestion by replacing the last sentence
>>>>> in the first paragraph with the following:
>>>>>
>>>>> "The choice by a user to join a particular network  (e.g. by
>>>>> physically plugging in a cable or selecting a network in a OS dialogue)
>>>>> typically updates a number of system resources - these can include IP
>>>>> addresses, availability of IPv4/IPv6,  DHCP server, and DNS resolver. These
>>>>> individual changes, including the change in DNS resolver, are not normally
>>>>> communicated directly to the user by the OS when the network is joined. The
>>>>> choice of network has historically determined the default system
>>>>> DNS resolver selection; the two are directly coupled in this model.
>>>>>
>>>>
>>>> WFM.
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> The vast majority of users do not change default
>>>>>>>> application-specific settings and so implicitly accept the
>>>>>>>> application-specific settings for DNS. As with network resolvers, these
>>>>>>>> resolvers may have strong, medium, or weak privacy policies depending on
>>>>>>>> the application.  Privacy policies for these servers may or may not be
>>>>>>>> available and users need to be aware that privacy guarantees will vary with
>>>>>>>> each application.
>>>>>>>>
>>>>>>>> For users to have the ability to inspect and control the
>>>>>>>> application-specific DNS settings in a similar fashion to the OS DNS
>>>>>>>> settings, each application must also:
>>>>>>>>
>>>>>>>>    o  expose the default settings to the user
>>>>>>>>
>>>>>>>>    o  provide configuration options to manually override the
>>>>>>>> default settings
>>>>>>>>
>>>>>>>>    o  provide configuration options to always use the system
>>>>>>>> resolver"
>>>>>>>>
>>>>>>>
>>>>>>> This last point is wrong. The parallel here would be to use the
>>>>>>> *network provided* resolver, not the system resolver. I would suggest that
>>>>>>> you be less prescriptive about this and just say "applications will need to
>>>>>>> provide user-visible options to configure the resolver." I would avoid
>>>>>>> "must" (even in lower case) because this is a statement of fact, not a
>>>>>>> normative one.
>>>>>>>
>>>>>>
>>>>>
>>>>>> No, system resolver is accurate. In addition to not knowing what
>>>>>> possible resolver is offered by DHCP, the application can't know if DHCP
>>>>>> (i.e. network provided) is even being used -- the system could be using a
>>>>>> static choice of resolver, or even other non-DNS resolution services (e.g.
>>>>>> NIS+).
>>>>>>
>>>>>
>>>>> It turns out that there are at least three options here:
>>>>>
>>>>> - Select your own resolver
>>>>> - Select the resolver *configured into the system* (AIUI this is what
>>>>> Chrome does).
>>>>> - Use the system resolver via the conventional API calls.
>>>>>
>>>>>
>>>>> Suggest:
>>>>>
>>>>> "For users to have the ability to inspect and control the
>>>>> application-specific DNS settings in a similar fashion to the OS DNS
>>>>> settings, each application also needs to:
>>>>>
>>>>>    o  expose the default settings to the user
>>>>>
>>>>>    o  provide configuration options to manually override the default
>>>>> settings so that resolution is performed via
>>>>>           * user specified resolvers
>>>>>           * the resolvers configured into the system settings
>>>>>           * the system resolver via conventional API calls
>>>>>
>>>>> If all such applications are updated to use the system resolver, as
>>>>> described in the last bullet point, the device reverts to a single point of
>>>>> control for all DNS queries."
>>>>>
>>>>
>>>> Hmm.... this seems unduly prescriptive. Perhaps.
>>>>
>>>> For users to have the ability to inspect and control the
>>>> application-specific DNS settings in a similar fashion to the OS DNS
>>>> settings, each application also needs to expose the default settings
>>>> to the users and provide a configuration interface to change them.  If
>>>> this interface includes a setting to use the system resolver, then the
>>>> device can be reverted to a single point of control for all DNS
>>>> queries.
>>>>
>>>>
>>>> I think this removes the status quo bias.
>>>>
>>>>
>>>> I’d be OK with removing the sub-second bullet point but I think the
>>>> other two have specific existing use cases:
>>>>
>>>> - ‘change them’ doesn’t explicitly allow for user specified resolvers
>>>> which all OS’s do
>>>> - without the option to disable the application-specific resolution a
>>>> user cannot apply device level controls to their DNS queries (logging,
>>>> filtering or rules directing different queries to different resolvers) in a
>>>> way that can be done today.
>>>>
>>>
>>> But this is what I mean by "status quo bias". And in this case, I
>>> suspect it's not even correct status quo bias because plenty of
>>> applications have been doing their own name resolution for some time (and
>>> of course malware will not have settings for this).
>>>
>>
>> I think this argument suffers from lack of supporting examples, as well
>> as from ambiguous terminology.
>>
>> Two specific terms I see as problematic: "applications"; and "name
>> resolution".
>>
>> The examples that should be included to reduce the ambiguity would be
>> actual applications, including (a) whether those require administrative
>> privileges to install, (b) whether those are end-user applications vs
>> system services (such as mail transport agents), and (c) whether/how they
>> make changes to resolver choice.
>>
>> The term "name resolution" could be anything from making calls to
>> installed libraries such as "ldns", which expose additional APIs but which
>> generally inherit OS resolution, to the "getdns" bindings, to implementing
>> full stub resolver functionality. It's not enough to say some do one thing,
>> some do another, evaluating the assertion being made means having those
>> details for each application that is being offered as an example.
>>
>> I'm aware of SMTP services that necessarily do their own resolution, in
>> order to handle a variety of things (such as MX records, SPF, DMARC, DKIM,
>> and even TLSA), but which largely are system-level services who are
>> generally configured by administrators, and generally conform to the
>> existing environment as far as resolver choice is concerned.
>>
>> I'm not aware of end-user applications doing any kind of DNS, and I'm
>> reasonably confident in saying that a number of platforms, such as Apple
>> iOS, do not support applications that do so.
>>
>
> As I said, Chrome does its own name resolution and has for quite some
> time, using the resolvers configured into the system and then sending its
> own DNS packets. This used to be common practice in SIP softphones, but I
> haven't worked on one in quite some time.  I'm not sure on what basis you
> claim iOS doesn't support this, as that's not my understanding. Can you
> provide a citation here?
>

Sure.

From
https://developer.apple.com/documentation/networkextension/dns_proxy_provider

DNS proxy providers are only supported on supervised iOS devices.


(And the latter is described here:
https://support.apple.com/guide/apple-configurator-2/supervised-devices-apd9e4f64088/mac
 )

So basically, the ability to use third party DNS is limited to managed
devices, corporate or education.
The only other exception is the one done via VPN services, which is a
different set of frameworks, IIUC.
(That's why 1.1.1.1 is a VPN app rather than just a resolver, I believe.)

Brian


>
> -Ekr
>
>
>
>>
>> The existence of a handful of services that do DNS resolution, does not
>> negate the central argument, that the expectation is that the OS-configured
>> resolver being used for DNS is the de facto status quo for end-user systems
>> and infrastructure systems.
>>
>> I also don't understand what the problem of status quo bias actually is,
>> could you explain the problem?
>>
>> Brian
>>
>>
>>
>>>
>>> As I said before, we should hear from people who implement their own
>>> resolver....
>>>
>>> -Ekr
>>>
>>> Sara.
>>>>
>>>> That said, I'd like to hear from people
>>>> who implement their own resolver even for Do53. I know Chrome does
>>>> this and I believe it's quite common for SIP stacks due to performance
>>>> concerns with the system resolver.
>>>>
>>>> -Ekr
>>>>
>>>>
>>>>
>>>>> Sara.
>>>>>
>>>>>
>>>>> -Ekr
>>>>>
>>>>>
>>>>>> Brian
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> The point in section 3.5..1.1.2  terms of privacy considerations
>>>>>>>>> is that any application that uses an application specific DNS setting
>>>>>>>>> introduces another control point on the device for the DNS resolution
>>>>>>>>> setting (which with the current offerings is independent of the network
>>>>>>>>> used), and if or how that is exposed is entirely up to the application. I
>>>>>>>>> suggest adding this text at the start of the second paragraph:
>>>>>>>>>
>>>>>>>>> "Such application-specific settings introduce new control points
>>>>>>>>> on end user devices for DNS resolution settings in addition to the
>>>>>>>>> historically used system settings."
>>>>>>>>>
>>>>>>>>
>>>>>>>> Well, I suppose this is true, but it's also true of (for instance)
>>>>>>>> allowing the user to set a proxy, which we've done forever.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> S 3.5.1.1.2.
>>>>>>>>> >
>>>>>>>>> >      Application-specific changes to default destinations for
>>>>>>>>> users' DNS
>>>>>>>>> >      queries might increase or decrease user privacy - it is
>>>>>>>>> highly
>>>>>>>>> >      dependent on the network context and the
>>>>>>>>> application-specific
>>>>>>>>> >      default.  This is an area of active debate and the IETF is
>>>>>>>>> working on
>>>>>>>>> >      a number of issues related to application-specific DNS
>>>>>>>>> settings.
>>>>>>>>>
>>>>>>>>> This, too, could be said about the current situation.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> See above.
>>>>>>>>>
>>>>>>>>
>>>>>>>> And my response above..
>>>>>>>>
>>>>>>>> -Ekr
>>>>>>>>
>>>>>>>>
>>>>>>>>> Sara.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Mon, Jan 20, 2020 at 1:47 PM Eric Vyncke (evyncke) <
>>>>>>>>> [e-mail]> wrote:
>>>>>>>>>
>>>>>>>>>> Thanks to Sara and Stéphane for the -04 revised I-D.
>>>>>>>>>>
>>>>>>>>>> After reading the -04, I think that most of the IETF Last Call
>>>>>>>>>> comments are addressed (and consensus needs to be balanced -- even for
>>>>>>>>>> informational document) and that the document sticks to facts.
>>>>>>>>>>
>>>>>>>>>> But, as section 3.5.1 ("in the recursive resolvers") raised a lot
>>>>>>>>>> of discussions during the first IETF Last Call, and as the authors reacted
>>>>>>>>>> to those comments by deep changes in the text, let's have a new IETF Last
>>>>>>>>>> Call before proceeding with IESG evaluation.
>>>>>>>>>>
>>>>>>>>>> Again, thank you to the reviewers and the authors
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>>
>>>>>>>>>> -éric
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 20/01/2020, 22:34, "IETF Secretariat" <
>>>>>>>>>> [e-mail]> wrote:
>>>>>>>>>>
>>>>>>>>>>     IESG state changed:
>>>>>>>>>>
>>>>>>>>>>     New State: Last Call Requested
>>>>>>>>>>
>>>>>>>>>>     (The previous state was Waiting for AD Go-Ahead::AD Followup)
>>>>>>>>>>
>>>>>>>>>>     The previous last call raised several points. The authors
>>>>>>>>>> have worked on those points and this new informational IETF draft has
>>>>>>>>>> substantive changes; enough to go trigger a new IETF Last Call.
>>>>>>>>>>
>>>>>>>>>>     -éric
>>>>>>>>>>
>>>>>>>>>>     Datatracker URL:
>>>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-dprive-rfc7626-bis/
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> dns-privacy mailing list
>>>>>>>>>> [e-mail]
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/dns-privacy
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>> dns-privacy mailing list
>>>>>>>> [e-mail]
>>>>>>>> https://www.ietf.org/mailman/listinfo/dns-privacy
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>> dns-privacy mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/dns-privacy
>>>>>>
>>>>>>
>>>>