On 13/05/2020 11:27 Vittorio Bertola <[email protected]> wrote:



>> Il 12/05/2020 17:18 Stephane Bortzmeyer 
>> <[email protected]<mailto:[email protected]>> ha scritto:

>>

>> Yes, and I think I know now the root of the problem. 7626bis tries to

>> go too far and, instead of discussing the DNS protocol and its privacy

>> issues, now goes into end hosts and discuss what is done inside the

>> machine, and what should be done. This is certainy interesting, and it

>> certainly has consequences on privacy, user control, etc but:

>>

>> 1) It is a bit outside IETF's domain, since it is not inside the

>> network,

>

>I disagree. There are IETF documents that provide policy-level analysis of 
>complex

>technical issues and do so throughout the entire network architecture, both in 
>terms

>of layers and in terms of hosts. For example, RFC 7754 has an entire section 
>devoted

>to what happens within the endpoints and within applications that run on them.

>

>Also, RFC 6973, which is the document that this draft tries to apply, has an 
>entire

>section of the guidelines (7.2) that instructs to discuss issues of user 
>control, which

>is what 6.1.1.2 deals with. Actually, the first point of the section is:

>

>     "What controls or consent mechanisms does the

>      protocol define or require before personal data or identifiers

>      are shared or exposed via the protocol?  If no such mechanisms or

>     controls are specified, is it expected that control and consent

>    will be handled outside of the protocol?"

>

>There even is an explicit reference to discussing how control and consent is 
>handled outside of the protocol.



I also note that RFC 3552 (Guidelines for Writing RFC Text on Security 
Considerations) includes section 2.3 on systems security so does indeed look 
beyond the network.  So, alongside RFC 7754 and RFC 6973, there seem to be a 
good number of examples where the IETF has reached consensus on documents with 
scope that extends beyond the network.  I’m unclear why this one should not.





Andrew




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

Reply via email to