On Mon, Mar 9, 2020 at 1:14 PM Eric Rescorla <[email protected]> wrote: > > > On Mon, Mar 9, 2020 at 12:18 PM Brian Dickson < > [email protected]> wrote: > >> >> >> On Mon, Mar 9, 2020 at 8:01 AM Eric Rescorla <[email protected]> wrote: >> >>> >>> >>> On Mon, Mar 9, 2020 at 3:55 AM Sara Dickinson <[email protected]> wrote: >>> >>>> >>>> >>>> On 6 Mar 2020, at 13:32, Eric Rescorla <[email protected]> wrote: >>>> >>>> >>>> >>>> On Mon, Mar 2, 2020 at 7:16 AM Sara Dickinson <[email protected]> wrote: >>>> >>>>> >>>>> >>>>> On 29 Feb 2020, at 02:03, Eric Rescorla <[email protected]> wrote: >>>>> >>>>> >>>>> >>>>> On Fri, Feb 28, 2020 at 4:50 PM Brian Dickson < >>>>> [email protected]> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Fri, Feb 28, 2020 at 3:15 PM Eric Rescorla <[email protected]> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Feb 26, 2020 at 6:19 AM Sara Dickinson <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 23 Jan 2020, at 13:53, Eric Rescorla <[email protected]> wrote: >>>>>>>> >>>>>>>> On Thu, Jan 23, 2020 at 5:08 AM Sara Dickinson <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 20 Jan 2020, at 22:37, Eric Rescorla <[email protected]> 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) < >>>>>>>>> [email protected]> 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" < >>>>>>>>>> [email protected]> 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 >>>>>>>>>> [email protected] >>>>>>>>>> https://www.ietf.org/mailman/listinfo/dns-privacy >>>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>> dns-privacy mailing list >>>>>>>> [email protected] >>>>>>>> https://www.ietf.org/mailman/listinfo/dns-privacy >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>> dns-privacy mailing list >>>>>>> [email protected] >>>>>>> https://www.ietf.org/mailman/listinfo/dns-privacy >>>>>> >>>>>> >>>>
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
