Subject: [dns-privacy] Fw: New Version Notification for draft-yan-dprive-local-service-indication-02.txt

From: "Z.W. Yan" <[email-masked]>
Date: Mon, 13 Jul 2020 10:17:57 +0800

Dear All,
The motivation of this draft is to actively indicate the privacy protection capability of the recursive server.
We can consider the extension of ND and DHCP protocols to support this configuration.
BR,
Zhiwei

From: internet-drafts
Date: 2020-07-13 08:41
To: Xinchang Zhang; Zhiwei Yan; Guanggang Geng; Yang Liu
Subject: New Version Notification for draft-yan-dprive-local-service-indication-02.txt
 
A new version of I-D, draft-yan-dprive-local-service-indication-02.txt
has been successfully submitted by Zhiwei Yan and posted to the
IETF repository.
 
Name: draft-yan-dprive-local-service-indication
Revision: 02
Title: Indication of Local DNS Privacy Service During User Access
Document date: 2020-07-12
Group: Individual Submission
Pages: 4
URL:            https://www.ietf.org/internet-drafts/draft-yan-dprive-local-service-indication-02.txt
Status:         https://datatracker.ietf.org/doc/draft-yan-dprive-local-service-indication/
Htmlized:       https://tools.ietf.org/html/draft-yan-dprive-local-service-indication-02
Htmlized:       https://datatracker.ietf.org/doc/html/draft-yan-dprive-local-service-indication
Diff:           https://www.ietf.org/rfcdiff?url2=draft-yan-dprive-local-service-indication-02
 
Abstract:
   This document aims to support the indication of privacy service of
   recursive resolver during the user access.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.
 
The IETF Secretariat

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 20 Jul 2020 21:28:55 +0200

On Mon, Jul 13, 2020 at 10:17:57AM +0800,
 Z.W. Yan <[email-masked]> wrote 
 a message of 120 lines which said:

> The motivation of this draft is to actively indicate the privacy
> protection capability of the recursive server.

The approach in draft-ietf-dnsop-resolver-information seems better since:
* it is more general, not limited to privacy,
* the information is sent by the resolver itself, who probably knows
 better than the DHCP server.

---

From: "Z.W. Yan" <[email-masked]>
Date: Tue, 21 Jul 2020 08:27:52 +0800

Correct, Stephane, the notification from resolver is more direct.
However, based on DHCP/ICMP is also an approach because the end-user is always bootstrapping based on DHCP/ICMP for the address configuration and so on.
Besides, the configuration of resolver can be supported by DHCP/ICMP and only an extension is needed based on RFC3646/4339...

Z.W. Yan
 
From: Stephane Bortzmeyer
Date: 2020-07-21 03:28
To: Z.W. Yan
CC: dns-privacy; gggeng; xincha.zhang; liuyang7
Subject: Re: [dns-privacy] Fw: New Version Notification for draft-yan-dprive-local-service-indication-02.txt
On Mon, Jul 13, 2020 at 10:17:57AM +0800,
Z.W. Yan <[email-masked]> wrote

---

From: Vittorio Bertola <[email-masked]>
Date: Tue, 21 Jul 2020 14:28:31 +0200 (CEST)

>     Il 21/07/2020 02:27 Z.W. Yan <[email-masked]> ha scritto:
>      
>      
I think it makes sense to standardize Do* service discovery via DHCP, then people will decide whether they want to make use of it or not.

I would however note that this draft (subject to assessment by the WG chairs) might be more in topic for the ADD working group - you may want to post it there.

-- 

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

---

From: "Z.W. Yan" <[email-masked]>
Date: Wed, 22 Jul 2020 08:40:50 +0800

Thank you for your comments and suggestions, Vittorio.
I think it is also suitable in Dprive, because Dprive mainly aims to produce the DNS privacy related solutions.
And this service discovery related scheme is tightly related with the solution, but it also depends on the comments of the Chairs, :-)

Z.W. Yan
 
From: Vittorio Bertola
Date: 2020-07-21 20:28
To: Z.W. Yan
CC: gggeng; xincha.zhang; dns-privacy; liuyang7
Subject: Re: [dns-privacy] Fw: New Version Notification for draft-yan-dprive-local-service-indication-02.txt

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

---

From: Brian Haberman <[email-masked]>
Date: Sat, 25 Jul 2020 14:55:13 -0400

Hi all,

> And this service discovery related scheme is tightly related with the solution, but it also depends on the comments of the Chairs, :-)

There are a number of DNS-related drafts that are currently without an
identified WG home. The chairs are working with our AD to initiate a
discussion with chairs and ADs of DNSOP and ADD to discuss this
situation. Once we get through that exercise, someone in leadership will
communicate the proposed direction to the necessary mailing lists.

Regards,
Brian

> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>

---

From: "Z.W. Yan" <[email-masked]>
Date: Tue, 28 Jul 2020 10:39:14 +0800

Dear All,
While we are waiting for the Chairs to indicate the place to discuss this topic, we revised the draft with some details of the service capability indication based on ICMPv6 and DHCPv6.
Basically, a filed should be defined in order to code the privacy capability of the related recursive server. However, in RFC3646, there is no reserved field in the "DNS Recursive Name Server option", then a new option is defined and which must be conjunctively used with "DNS Recursive Name Server option". We leave 4-bit space to include the privacy service capability as an example in the draft.
Your comments are welcome.
Thank you.
BR,
Z.W. Yan