< draft-ietf-dprive-bcp-op-11.txt		draft-ietf-dprive-bcp-op-12.txt >
	dprive S. Dickinson		dprive S. Dickinson
	Internet-Draft Sinodun IT		Internet-Draft Sinodun IT
	Intended status: Best Current Practice B. Overeinder		Intended status: Best Current Practice B. Overeinder
	Expires: January 3, 2021 R. van Rijswijk-Deij		Expires: January 7, 2021 R. van Rijswijk-Deij
	NLnet Labs		NLnet Labs
	A. Mankin		A. Mankin
	Salesforce		Salesforce
	July 2, 2020		July 6, 2020
	Recommendations for DNS Privacy Service Operators		Recommendations for DNS Privacy Service Operators
	draft-ietf-dprive-bcp-op-11		draft-ietf-dprive-bcp-op-12
	Abstract		Abstract
	This document presents operational, policy, and security		This document presents operational, policy, and security
	considerations for DNS recursive resolver operators who choose to		considerations for DNS recursive resolver operators who choose to
	offer DNS Privacy services. With these recommendations, the operator		offer DNS Privacy services. With these recommendations, the operator
	can make deliberate decisions regarding which services to provide,		can make deliberate decisions regarding which services to provide,
	and how the decisions and alternatives impact the privacy of users.		and how the decisions and alternatives impact the privacy of users.
	This document also presents a non-normative framework to assist		This document also presents a non-normative framework to assist
	writers of a DNS Recursive Operator Privacy Statement (analogous to		writers of a Recursive operator Privacy statement (analogous to DNS
	DNS Security Extensions (DNSSEC) Policies and DNSSEC Practice		Security Extensions (DNSSEC) Policies and DNSSEC Practice Statements
	Statements described in RFC6841).		described in RFC6841).
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on January 3, 2021.		This Internet-Draft will expire on January 7, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 44 ¶		skipping to change at page 2, line 44 ¶
	5.2.1. Data handling . . . . . . . . . . . . . . . . . . . . 14		5.2.1. Data handling . . . . . . . . . . . . . . . . . . . . 14
	5.2.2. Data minimization of network traffic . . . . . . . . 15		5.2.2. Data minimization of network traffic . . . . . . . . 15
	5.2.3. IP address pseudonymization and anonymization methods 16		5.2.3. IP address pseudonymization and anonymization methods 16
	5.2.4. Pseudonymization, anonymization, or discarding of		5.2.4. Pseudonymization, anonymization, or discarding of
	other correlation data . . . . . . . . . . . . . . . 16		other correlation data . . . . . . . . . . . . . . . 16
	5.2.5. Cache snooping . . . . . . . . . . . . . . . . . . . 17		5.2.5. Cache snooping . . . . . . . . . . . . . . . . . . . 17
	5.3. Data sent onwards from the server . . . . . . . . . . . . 17		5.3. Data sent onwards from the server . . . . . . . . . . . . 17
	5.3.1. Protocol recommendations . . . . . . . . . . . . . . 17		5.3.1. Protocol recommendations . . . . . . . . . . . . . . 17
	5.3.2. Client query obfuscation . . . . . . . . . . . . . . 18		5.3.2. Client query obfuscation . . . . . . . . . . . . . . 18
	5.3.3. Data sharing . . . . . . . . . . . . . . . . . . . . 19		5.3.3. Data sharing . . . . . . . . . . . . . . . . . . . . 19
	6. DNS Recursive Operator Privacy (DROP) statement . . . . . . . 19		6. Recursive operator Privacy Statement (RPS) . . . . . . . . . 19
	6.1. Outline of a DROP statement . . . . . . . . . . . . . . . 20		6.1. Outline of an RPS . . . . . . . . . . . . . . . . . . . . 20
	6.1.1. Policy . . . . . . . . . . . . . . . . . . . . . . . 20		6.1.1. Policy . . . . . . . . . . . . . . . . . . . . . . . 20
	6.1.2. Practice . . . . . . . . . . . . . . . . . . . . . . 21		6.1.2. Practice . . . . . . . . . . . . . . . . . . . . . . 21
	6.2. Enforcement/accountability . . . . . . . . . . . . . . . 22		6.2. Enforcement/accountability . . . . . . . . . . . . . . . 22
	7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 22		7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 22
	8. Security considerations . . . . . . . . . . . . . . . . . . . 22		8. Security considerations . . . . . . . . . . . . . . . . . . . 22
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
	10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23		10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23
	11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 23		11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 23
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 26		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
	12.1. Normative References . . . . . . . . . . . . . . . . . . 26		12.1. Normative References . . . . . . . . . . . . . . . . . . 26
	skipping to change at page 3, line 23 ¶		skipping to change at page 3, line 23 ¶
	B.1. Categorization of techniques . . . . . . . . . . . . . . 36		B.1. Categorization of techniques . . . . . . . . . . . . . . 36
	B.2. Specific techniques . . . . . . . . . . . . . . . . . . . 37		B.2. Specific techniques . . . . . . . . . . . . . . . . . . . 37
	B.2.1. Google Analytics non-prefix filtering . . . . . . . . 37		B.2.1. Google Analytics non-prefix filtering . . . . . . . . 37
	B.2.2. dnswasher . . . . . . . . . . . . . . . . . . . . . . 37		B.2.2. dnswasher . . . . . . . . . . . . . . . . . . . . . . 37
	B.2.3. Prefix-preserving map . . . . . . . . . . . . . . . . 38		B.2.3. Prefix-preserving map . . . . . . . . . . . . . . . . 38
	B.2.4. Cryptographic Prefix-Preserving Pseudonymization . . 38		B.2.4. Cryptographic Prefix-Preserving Pseudonymization . . 38
	B.2.5. Top-hash Subtree-replicated Anonymization . . . . . . 38		B.2.5. Top-hash Subtree-replicated Anonymization . . . . . . 38
	B.2.6. ipcipher . . . . . . . . . . . . . . . . . . . . . . 39		B.2.6. ipcipher . . . . . . . . . . . . . . . . . . . . . . 39
	B.2.7. Bloom filters . . . . . . . . . . . . . . . . . . . . 39		B.2.7. Bloom filters . . . . . . . . . . . . . . . . . . . . 39
	Appendix C. Current policy and privacy statements . . . . . . . 39		Appendix C. Current policy and privacy statements . . . . . . . 39
	Appendix D. Example DROP statement . . . . . . . . . . . . . . . 40		Appendix D. Example RPS . . . . . . . . . . . . . . . . . . . . 40
	D.1. Policy . . . . . . . . . . . . . . . . . . . . . . . . . 40		D.1. Policy . . . . . . . . . . . . . . . . . . . . . . . . . 40
	D.2. Practice . . . . . . . . . . . . . . . . . . . . . . . . 43		D.2. Practice . . . . . . . . . . . . . . . . . . . . . . . . 43
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44
	1. Introduction		1. Introduction
	The Domain Name System (DNS) is at the core of the Internet; almost		The Domain Name System (DNS) is at the core of the Internet; almost
	every activity on the Internet starts with a DNS query (and often		every activity on the Internet starts with a DNS query (and often
	several). However the DNS was not originally designed with strong		several). However the DNS was not originally designed with strong
	security or privacy mechanisms. A number of developments have taken		security or privacy mechanisms. A number of developments have taken
	skipping to change at page 4, line 36 ¶		skipping to change at page 4, line 36 ¶
	significant activity. Providing detailed practice advice about these		significant activity. Providing detailed practice advice about these
	areas to the operator is out of scope, but Section 5.3.3 describes		areas to the operator is out of scope, but Section 5.3.3 describes
	some mitigations of data sharing risk.		some mitigations of data sharing risk.
	This document has two main goals:		This document has two main goals:
	o To provide operational and policy guidance related to DNS over		o To provide operational and policy guidance related to DNS over
	encrypted transports and to outline recommendations for data		encrypted transports and to outline recommendations for data
	handling for operators of DNS privacy services.		handling for operators of DNS privacy services.
	o To introduce the DNS Recursive Operator Privacy (DROP) statement		o To introduce the Recursive operator Privacy Statement (RPS) and
	and present a framework to assist writers of a DROP statement. A		present a framework to assist writers of an RPS. An RPS is a
	DROP statement is a document that an operator should publish which		document that an operator should publish which outlines their
	outlines their operational practices and commitments with regard		operational practices and commitments with regard to privacy,
	to privacy, thereby providing a means for clients to evaluate both		thereby providing a means for clients to evaluate both the
	the measurable and claimed privacy properties of a given DNS		measurable and claimed privacy properties of a given DNS privacy
	privacy service. The framework identifies a set of elements and		service. The framework identifies a set of elements and specifies
	specifies an outline order for them. This document does not,		an outline order for them. This document does not, however,
	however, define a particular Privacy statement, nor does it seek		define a particular privacy statement, nor does it seek to provide
	to provide legal advice as to the contents.		legal advice as to the contents.
	A desired operational impact is that all operators (both those		A desired operational impact is that all operators (both those
	providing resolvers within networks and those operating large public		providing resolvers within networks and those operating large public
	services) can demonstrate their commitment to user privacy thereby		services) can demonstrate their commitment to user privacy thereby
	driving all DNS resolution services to a more equitable footing.		driving all DNS resolution services to a more equitable footing.
	Choices for users would (in this ideal world) be driven by other		Choices for users would (in this ideal world) be driven by other
	factors, e.g., differing security policies or minor difference in		factors, e.g., differing security policies or minor difference in
	operator policy, rather than gross disparities in privacy concerns.		operator policy, rather than gross disparities in privacy concerns.
	Community insight [or judgment?] about operational practices can		Community insight [or judgment?] about operational practices can
	skipping to change at page 6, line 22 ¶		skipping to change at page 6, line 22 ¶
	DNS terminology is as described in [RFC8499] with one modification:		DNS terminology is as described in [RFC8499] with one modification:
	we restate the clause in the original definition of Privacy-enabling		we restate the clause in the original definition of Privacy-enabling
	DNS server in [RFC8310] to include the requirement that a DNS over		DNS server in [RFC8310] to include the requirement that a DNS over
	(D)TLS server should also offer at least one of the credentials		(D)TLS server should also offer at least one of the credentials
	described in Section 8 of [RFC8310] and implement the (D)TLS profile		described in Section 8 of [RFC8310] and implement the (D)TLS profile
	described in Section 9 of [RFC8310].		described in Section 9 of [RFC8310].
	Other Terms:		Other Terms:
	o DROP: DNS Recursive Operator Privacy statement, see Section 6.		o RPS: Recursive operator Privacy Statement, see Section 6.
	o DNS privacy service: The service that is offered via a privacy-		o DNS privacy service: The service that is offered via a privacy-
	enabling DNS server and is documented either in an informal		enabling DNS server and is documented either in an informal
	statement of policy and practice with regard to users privacy or a		statement of policy and practice with regard to users privacy or a
	formal DROP statement.		formal RPS.
	5. Recommendations for DNS privacy services		5. Recommendations for DNS privacy services
	In the following sections we first outline the threats relevant to		In the following sections we first outline the threats relevant to
	the specific topic and then discuss the potential actions that can be		the specific topic and then discuss the potential actions that can be
	taken to mitigate them.		taken to mitigate them.
	We describe two classes of threats:		We describe two classes of threats:
	o Threats described in [RFC6973] 'Privacy Considerations for		o Threats described in [RFC6973] 'Privacy Considerations for
	skipping to change at page 19, line 46 ¶		skipping to change at page 19, line 46 ¶
	specific circumstance they should publish the terms under which data		specific circumstance they should publish the terms under which data
	is shared.		is shared.
	Operators should consider including specific guidelines for the		Operators should consider including specific guidelines for the
	collection of aggregated and/or anonymized data for research		collection of aggregated and/or anonymized data for research
	purposes, within or outside of their own organization. This can		purposes, within or outside of their own organization. This can
	benefit not only the operator (through inclusion in novel research)		benefit not only the operator (through inclusion in novel research)
	but also the wider Internet community. See the policy published by		but also the wider Internet community. See the policy published by
	SURFnet [SURFnet-policy] on data sharing for research as an example.		SURFnet [SURFnet-policy] on data sharing for research as an example.
	6. DNS Recursive Operator Privacy (DROP) statement		6. Recursive operator Privacy Statement (RPS)
	To be compliant with this Best Common Practices document, a DNS		To be compliant with this Best Common Practices document, a DNS
	Recursive Operator SHOULD publish a DNS Recursive Operator Privacy		recursive operator SHOULD publish a Recursive operator Privacy
	Statement. Adopting the outline, and including the headings in the		Statement (RPS). Adopting the outline, and including the headings in
	order provided, is a benefit to persons comparing multiple operators'		the order provided, is a benefit to persons comparing RPSs from
	DROP statements.		multiple operators.
	Appendix C provides a comparison of some existing policy and privacy		Appendix C provides a comparison of some existing policy and privacy
	statements.		statements.
	6.1. Outline of a DROP statement		6.1. Outline of an RPS
	The contents of Section 6.1.1 and Section 6.1.2 are non-normative,		The contents of Section 6.1.1 and Section 6.1.2 are non-normative,
	other than the order of the headings. Material under each topic is		other than the order of the headings. Material under each topic is
	present to assist the operator developing their own DROP statement		present to assist the operator developing their own RPS and:
	and:
	o Relates _only_ to matters around to the technical operation of DNS		o Relates _only_ to matters around to the technical operation of DNS
	privacy services, and not on any other matters.		privacy services, and not on any other matters.
	o Does not attempt to offer an exhaustive list for the contents of a		o Does not attempt to offer an exhaustive list for the contents of
	DROP statement.		an RPS.
	o Is not intended to form the basis of any legal/compliance		o Is not intended to form the basis of any legal/compliance
	documentation.		documentation.
	Appendix D provides an example (also non-normative) of a DROP		Appendix D provides an example (also non-normative) of an RPS
	statement for a specific operator scenario.		statement for a specific operator scenario.
	6.1.1. Policy		6.1.1. Policy
	1. Treatment of IP addresses. Make an explicit statement that IP		1. Treatment of IP addresses. Make an explicit statement that IP
	addresses are treated as personal data.		addresses are treated as personal data.
	2. Data collection and sharing. Specify clearly what data		2. Data collection and sharing. Specify clearly what data
	(including IP addresses) is:		(including IP addresses) is:
	skipping to change at page 22, line 38 ¶		skipping to change at page 22, line 38 ¶
	o ECS, QNAME minimization, EDNS(0) padding, etc.		o ECS, QNAME minimization, EDNS(0) padding, etc.
	o Filtering.		o Filtering.
	o Uptime.		o Uptime.
	This is by analogy with several TLS or website analysis tools that		This is by analogy with several TLS or website analysis tools that
	are currently available e.g., [SSL-Labs] or [Internet.nl].		are currently available e.g., [SSL-Labs] or [Internet.nl].
	Additionally operators could choose to engage the services of a third		Additionally operators could choose to engage the services of a third
	party auditor to verify their compliance with their published DROP		party auditor to verify their compliance with their published RPS.
	statement.
	7. IANA considerations		7. IANA considerations
	None		None
	8. Security considerations		8. Security considerations
	Security considerations for DNS-over-TCP are given in [RFC7766], many		Security considerations for DNS-over-TCP are given in [RFC7766], many
	of which are generally applicable to session based DNS. Guidance on		of which are generally applicable to session based DNS. Guidance on
	operational requirements for DNS-over-TCP are also available in [I-		operational requirements for DNS-over-TCP are also available in [I-
	D.dnsop-dns-tcp-requirements]. Security considerations for DoT are		D.dnsop-dns-tcp-requirements]. Security considerations for DoT are
	given in [RFC7858] and [RFC8310], those for DoH in [RFC8484].		given in [RFC7858] and [RFC8310], those for DoH in [RFC8484].
	Security considerations for DNSSEC are given in [RFC4033], [RFC4034]		Security considerations for DNSSEC are given in [RFC4033], [RFC4034]
	and [RFC4035].		and [RFC4035].
	9. Acknowledgements		9. Acknowledgements
	Many thanks to Amelia Andersdotter for a very thorough review of the		Many thanks to Amelia Andersdotter for a very thorough review of the
	first draft of this document and Stephen Farrell for a thorough		first draft of this document and Stephen Farrell for a thorough
	review at WGLC and for suggesting the inclusion of an example DROP		review at WGLC and for suggesting the inclusion of an example RPS.
	statement. Thanks to John Todd for discussions on this topic, and to		Thanks to John Todd for discussions on this topic, and to Stephane
	Stephane Bortzmeyer, Puneet Sood and Vittorio Bertola for review.		Bortzmeyer, Puneet Sood and Vittorio Bertola for review. Thanks to
	Thanks to Daniel Kahn Gillmor, Barry Green, Paul Hoffman, Dan York,		Daniel Kahn Gillmor, Barry Green, Paul Hoffman, Dan York, Jon Reed,
	Jon Reed, Lorenzo Colitti for comments at the mic. Thanks to		Lorenzo Colitti for comments at the mic. Thanks to Loganaden
	Loganaden Velvindron for useful updates to the text.		Velvindron for useful updates to the text.
	Sara Dickinson thanks the Open Technology Fund for a grant to support		Sara Dickinson thanks the Open Technology Fund for a grant to support
	the work on this document.		the work on this document.
	10. Contributors		10. Contributors
	The below individuals contributed significantly to the document:		The below individuals contributed significantly to the document:
	John Dickinson		John Dickinson
	Sinodun Internet Technologies		Sinodun Internet Technologies
	skipping to change at page 23, line 42 ¶		skipping to change at page 23, line 42 ¶
	Jim Hague		Jim Hague
	Sinodun Internet Technologies		Sinodun Internet Technologies
	Magdalen Centre		Magdalen Centre
	Oxford Science Park		Oxford Science Park
	Oxford OX4 4GA		Oxford OX4 4GA
	United Kingdom		United Kingdom
	11. Changelog		11. Changelog
			draft-ietf-dprive-bcp-op-12
			o Change DROP to RPS throughout
	draft-ietf-dprive-bcp-op-11		draft-ietf-dprive-bcp-op-11
	o Improve text around use of normative language		o Improve text around use of normative language
	o Fix section 5.1.3.2 bullets		o Fix section 5.1.3.2 bullets
	o Improve text in 6.1.2. item 2.		o Improve text in 6.1.2. item 2.
	o Rework text of 6.1.2. item 5 and update example DROP		o Rework text of 6.1.2. item 5 and update example DROP
	o Various editorial improvements		o Various editorial improvements
			draft-ietf-dprive-bcp-op-10
	o Remove direct references to draft-ietf-dprive-rfc7626-bis, instead		o Remove direct references to draft-ietf-dprive-rfc7626-bis, instead
	have one general reference RFC7626		have one general reference RFC7626
	o Clarify that the DROP statement outline is non-normative and add		o Clarify that the DROP statement outline is non-normative and add
	some further qualifications about content		some further qualifications about content
	o Update wording on data sharing to remove explicit discussion of		o Update wording on data sharing to remove explicit discussion of
	consent		consent
	o Move table in section 5.2.3 to an appendix		o Move table in section 5.2.3 to an appendix
	skipping to change at page 39, line 42 ¶		skipping to change at page 39, line 42 ¶
	performed a particular query. Large numbers of queries can be		performed a particular query. Large numbers of queries can be
	tracked in a memory-efficient way. As filter status is stored, this		tracked in a memory-efficient way. As filter status is stored, this
	approach cannot be used to regenerate traffic, and so cannot be used		approach cannot be used to regenerate traffic, and so cannot be used
	with tools used to process live traffic.		with tools used to process live traffic.
	Anonymized: Generalization.		Anonymized: Generalization.
	Appendix C. Current policy and privacy statements		Appendix C. Current policy and privacy statements
	A tabular comparison of policy and privacy statements from various		A tabular comparison of policy and privacy statements from various
	DNS Privacy service operators based loosely on the proposed DROP		DNS Privacy service operators based loosely on the proposed RPS
	structure can be found at [policy-comparison]. The analysis is based		structure can be found at [policy-comparison]. The analysis is based
	on the data available in December 2019.		on the data available in December 2019.
	We note that the existing set of policies vary widely in style,		We note that the existing set of policies vary widely in style,
	content and detail and it is not uncommon for the full text for a		content and detail and it is not uncommon for the full text for a
	given operator to equate to more than 10 pages of moderate font sized		given operator to equate to more than 10 pages of moderate font sized
	A4 text. It is a non-trivial task today for a user to extract a		A4 text. It is a non-trivial task today for a user to extract a
	meaningful overview of the different services on offer.		meaningful overview of the different services on offer.
	It is also noted that Mozilla have published a DoH resolver policy		It is also noted that Mozilla have published a DoH resolver policy
	[DoH-resolver-policy], which describes the minimum set of policy		[DoH-resolver-policy], which describes the minimum set of policy
	requirements that a party must satisfy to be considered as a		requirements that a party must satisfy to be considered as a
	potential partner for Mozilla's Trusted Recursive Resolver (TRR)		potential partner for Mozilla's Trusted Recursive Resolver (TRR)
	program.		program.
	Appendix D. Example DROP statement		Appendix D. Example RPS
	The following example DROP statement is very loosely based on some		The following example RPS is very loosely based on some elements of
	elements of published privacy statements for some public resolvers,		published privacy statements for some public resolvers, with
	with additional fields populated to illustrate the what the full		additional fields populated to illustrate the what the full contents
	contents of a DROP statement might look like. This should not be		of an RPS might look like. This should not be interpreted as
	interpreted as
	o having been reviewed or approved by any operator in any way		o having been reviewed or approved by any operator in any way
	o having any legal standing or validity at all		o having any legal standing or validity at all
	o being complete or exhaustive		o being complete or exhaustive
	This is a purely hypothetical example of a DROP statement to outline		This is a purely hypothetical example of an RPS to outline example
	example contents - in this case for a public resolver operator		contents - in this case for a public resolver operator providing a
	providing a basic DNS Privacy service via one IP address and one DoH		basic DNS Privacy service via one IP address and one DoH URI with
	URI with security based filtering. It does aim to meet minimal		security based filtering. It does aim to meet minimal compliance as
	compliance as specified in Section 5.		specified in Section 5.
	D.1. Policy		D.1. Policy
	1. Treatment of IP addresses. Many nations classify IP addresses as		1. Treatment of IP addresses. Many nations classify IP addresses as
	personal data, and we take a conservative approach in treating IP		personal data, and we take a conservative approach in treating IP
	addresses as personal data in all jurisdictions in which our		addresses as personal data in all jurisdictions in which our
	systems reside.		systems reside.
	2. Data collection and sharing.		2. Data collection and sharing.
End of changes. 24 change blocks.
	53 lines changed or deleted		57 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/