draft-ietf-dnsop-qname-minimisation-04.txt		draft-ietf-dnsop-qname-minimisation-05.txt
	Domain Name System Operations (dnsop) Working Group S. Bortzmeyer		Domain Name System Operations (dnsop) Working Group S. Bortzmeyer
	Internet-Draft AFNIC		Internet-Draft AFNIC
	Intended status: Experimental June 19, 2015		Intended status: Experimental August 1, 2015
	Expires: December 21, 2015		Expires: February 2, 2016
	DNS query name minimisation to improve privacy		DNS query name minimisation to improve privacy
	draft-ietf-dnsop-qname-minimisation-04		draft-ietf-dnsop-qname-minimisation-05
	Abstract		Abstract
	This document describes one of the techniques that could be used to		This document describes one of the techniques that could be used to
	improve DNS privacy (see [I-D.ietf-dprive-problem-statement]), a		improve DNS privacy (see [I-D.ietf-dprive-problem-statement]), a
	technique called "QNAME minimisation", where the DNS resolver no		technique called "QNAME minimisation", where the DNS resolver no
	longer sends the full original QNAME to the upstream name server.		longer sends the full original QNAME to the upstream name server.
	REMOVE BEFORE PUBLICATION Discussions of the document should take
	place on the DNSOP working group mailing list [dnsop].
	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 December 21, 2015.		This Internet-Draft will expire on February 2, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2015 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction and background . . . . . . . . . . . . . . . . . 2		1. Introduction and background . . . . . . . . . . . . . . . . . 2
	2. QNAME minimisation . . . . . . . . . . . . . . . . . . . . . 3		2. QNAME minimisation . . . . . . . . . . . . . . . . . . . . . 2
	3. Possible issues . . . . . . . . . . . . . . . . . . . . . . . 4		3. Possible issues . . . . . . . . . . . . . . . . . . . . . . . 3
	4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 5		4. Protocol and compatibility discussion . . . . . . . . . . . . 5
	5. Operational considerations . . . . . . . . . . . . . . . . . 5		5. Operational considerations . . . . . . . . . . . . . . . . . 5
	6. Performance considerations . . . . . . . . . . . . . . . . . 5		6. Performance considerations . . . . . . . . . . . . . . . . . 5
	7. Security considerations . . . . . . . . . . . . . . . . . . . 6		7. Security considerations . . . . . . . . . . . . . . . . . . . 6
	8. Implementation status - REMOVE BEFORE PUBLICATION . . . . . . 7		8. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 6
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
	10.1. Normative References . . . . . . . . . . . . . . . . . . 8		10.1. Normative References . . . . . . . . . . . . . . . . . . 8
	10.2. Informative References . . . . . . . . . . . . . . . . . 8		10.2. Informative References . . . . . . . . . . . . . . . . . 8
	10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 9		10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	Appendix A. An algorithm to find the zone cut . . . . . . . . . 9		Appendix A. An algorithm to find the zone cut . . . . . . . . . 9
	Appendix B. Alternatives . . . . . . . . . . . . . . . . . . . . 10		Appendix B. Alternatives . . . . . . . . . . . . . . . . . . . . 10
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
	1. Introduction and background		1. Introduction and background
	The problem statement is exposed in		The problem statement is exposed in
	[I-D.ietf-dprive-problem-statement] TODO: add a reference to the		[I-D.ietf-dprive-problem-statement]. The terminology ("QNAME",
	specific section when ietf-dprive-problem-statement will be published		"resolver", etc) is also defined in this companion document. This
	as RFC. The terminology ("QNAME", "resolver", etc) is also defined		specific solution is not intended to fully solve the DNS privacy
	in this companion document. This specific solution is not intended		problem; instead, it should be viewed as one tool amongst many.
	to fully solve the DNS privacy problem; instead, it should be viewed
	as one tool amongst many.
	It follows the principle explained in section 6.1 of [RFC6973]: the		It follows the principle explained in section 6.1 of [RFC6973]: the
	less data you send out, the fewer privacy problems you'll get.		less data you send out, the fewer privacy problems you'll get.
	Under current practice, when a resolver receives the query "What is		Under current practice, when a resolver receives the query "What is
	the AAAA record for www.example.com?", it sends to the root (assuming		the AAAA record for www.example.com?", it sends to the root (assuming
	a cold resolver, whose cache is empty) the very same question.		a cold resolver, whose cache is empty) the very same question.
	Sending the full QNAME to the authoritative name server is a		Sending the full QNAME to the authoritative name server is a
	tradition, not a protocol requirement. This tradition		tradition, not a protocol requirement. This tradition
	comes[mockapetris-history] from a desire to optimize the number of		comes[mockapetris-history] from a desire to optimize the number of
	skipping to change at page 4, line 15		skipping to change at page 4, line 10
	3. Possible issues		3. Possible issues
	QNAME minimisation is legal, since the original DNS RFC do not		QNAME minimisation is legal, since the original DNS RFC do not
	mandate sending the full QNAME. So, in theory, it should work		mandate sending the full QNAME. So, in theory, it should work
	without any problems. However, in practice, some problems may occur		without any problems. However, in practice, some problems may occur
	(see an analysis in [huque-qnamemin]).		(see an analysis in [huque-qnamemin]).
	Some broken name servers do not react properly to qtype=NS requests.		Some broken name servers do not react properly to qtype=NS requests.
	For instance, some authoritative name servers embedded in load		For instance, some authoritative name servers embedded in load
	balancers reply properly to A queries but send REFUSED to NS queries.		balancers reply properly to A queries but send REFUSED to NS queries.
	REMOVE THIS SENTENCE BEFORE PUBLICATION: As an example of today, look		This behaviour is a gross protocol violation, and there is no need to
	at www.ratp.fr (not ratp.fr). This behaviour is a gross protocol		stop improving the DNS because of such brokenness. However, QNAME
	violation, and there is no need to stop improving the DNS because of		minimisation may still work with such domains since they are only
	such brokenness. However, QNAME minimisation may still work with		leaf domains (no need to send them NS requests). Such setup breaks
	such domains since they are only leaf domains (no need to send them		more than just QNAME minimisation. It breaks negative answers, since
	NS requests). Such setup breaks more than just QNAME minimisation.		the servers don't return the correct SOA, and it also breaks anything
	It breaks negative answers, since the servers don't return the		dependent upon NS and SOA records existing at the top of the zone.
	correct SOA, and it also breaks anything dependent upon NS and SOA
	records existing at the top of the zone.		Another way to deal with such broken name servers would be to try
			with QTYPE=A requests (A being chosen because it is the most common
			and hence a qtype which will be always accepted, while a qtype NS may
			ruffle the feathers of some middleboxes). Instead of querying name
			servers with a query "NS example.com", we could use "A _.example.com"
			and see if we get a referral.
	A problem can also appear when a name server does not react properly		A problem can also appear when a name server does not react properly
	to ENT (Empty Non-Terminals). If ent.example.com has no resource		to ENT (Empty Non-Terminals). If ent.example.com has no resource
	records but foobar.ent.example.com does, then ent.example.com is an		records but foobar.ent.example.com does, then ent.example.com is an
	ENT. A query, whatever the qtype, for ent.example.com must return		ENT. A query, whatever the qtype, for ent.example.com must return
	NODATA (NOERROR / ANSWER: 0). However, some broken name servers		NODATA (NOERROR / ANSWER: 0). However, some broken name servers
	return NXDOMAIN for ENTs. REMOVE THIS SENTENCE BEFORE PUBLICATION:		return NXDOMAIN for ENTs. If a resolver queries only
	As an example of today, look at com.akadns.net or www.upenn.edu with
	its delegations to Akamai. If a resolver queries only
	foobar.ent.example.com, everything will be OK but, if it implements		foobar.ent.example.com, everything will be OK but, if it implements
	QNAME minimisation, it may query ent.example.com and get a NXDOMAIN.		QNAME minimisation, it may query ent.example.com and get a NXDOMAIN.
	See also section 3 of [I-D.vixie-dnsext-resimprove] for the other bad		See also section 3 of [I-D.vixie-dnsext-resimprove] for the other bad
	consequences of this brokenness.		consequences of this brokenness.
	Another way to deal with such broken name servers would be to try
	with QTYPE=A requests (A being chosen because it is the most common
	and hence a qtype which will be always accepted, while a qtype NS may
	ruffle the feathers of some middleboxes). Instead of querying name
	servers with a query "NS example.com", we could use "A _.example.com"
	and see if we get a referral.
	Other strange and non-conformant practices may pose a problem: there		Other strange and non-conformant practices may pose a problem: there
	is a common DNS anti-pattern used by low-end web hosters that also do		is a common DNS anti-pattern used by low-end web hosters that also do
	DNS hosting that exploits the fact that the DNS protocol (pre-DNSSEC)		DNS hosting that exploits the fact that the DNS protocol (pre-DNSSEC)
	allows certain serious misconfigurations, such as parent and child		allows certain serious misconfigurations, such as parent and child
	zones disagreeing on the location of a zone cut. Basically, they		zones disagreeing on the location of a zone cut. Basically, they
	have a single zone with wildcards for each TLD like:		have a single zone with wildcards for each TLD like:
	*.example. 60 IN A 192.0.2.6		*.example. 60 IN A 192.0.2.6
	(It is not known why they don't just wildcard all of "*." and be done		(It is not known why they don't just wildcard all of "*." and be done
	with it.)		with it.)
	This lets them turn up many web hosting customers without having to		This lets them turn up many web hosting customers without having to
	configure thousands of individual zones on their nameservers. They		configure thousands of individual zones on their nameservers. They
	just tell the prospective customer to point their NS records at the		just tell the prospective customer to point their NS records at the
	hoster's nameservers, and the Web hoster doesn't have to provision		hoster's nameservers, and the Web hoster doesn't have to provision
	anything in order to make the customer's domain resolve. NS queries		anything in order to make the customer's domain resolve. NS queries
	to the hoster will therefore do not give the right result, which may		to the hoster will therefore do not give the right result, which may
	endanger QNAME minimisation (it will be a problem for DNSSEC, too).		endanger QNAME minimisation (it will be a problem for DNSSEC, too).
	skipping to change at page 5, line 15		skipping to change at page 5, line 8
	with it.)		with it.)
	This lets them turn up many web hosting customers without having to		This lets them turn up many web hosting customers without having to
	configure thousands of individual zones on their nameservers. They		configure thousands of individual zones on their nameservers. They
	just tell the prospective customer to point their NS records at the		just tell the prospective customer to point their NS records at the
	hoster's nameservers, and the Web hoster doesn't have to provision		hoster's nameservers, and the Web hoster doesn't have to provision
	anything in order to make the customer's domain resolve. NS queries		anything in order to make the customer's domain resolve. NS queries
	to the hoster will therefore do not give the right result, which may		to the hoster will therefore do not give the right result, which may
	endanger QNAME minimisation (it will be a problem for DNSSEC, too).		endanger QNAME minimisation (it will be a problem for DNSSEC, too).
	4. Discussion		4. Protocol and compatibility discussion
	QNAME minimisation is compatible with the current DNS system and		QNAME minimisation is compatible with the current DNS system and
	therefore can easily be deployed; since it is a unilateral change to		therefore can easily be deployed; since it is a unilateral change to
	the resolver, it does not change the protocol. (Because it is an		the resolver, it does not change the protocol. (Because it is an
	unilateral change, resolver implementers may do QNAME minimisation in		unilateral change, resolver implementers may do QNAME minimisation in
	slightly different ways, see the appendices for examples.)		slightly different ways, see the appendices for examples.)
	One should note that the behaviour suggested here (minimising the		One should note that the behaviour suggested here (minimising the
	amount of data sent in QNAMEs from the resolver) is NOT forbidden by		amount of data sent in QNAMEs from the resolver) is NOT forbidden by
	the [RFC1034] (section 5.3.3) or [RFC1035] (section 7.2). As said in		the [RFC1034] (section 5.3.3) or [RFC1035] (section 7.2). As said in
	skipping to change at page 6, line 31		skipping to change at page 6, line 24
	www.host.group.department.example.com where		www.host.group.department.example.com where
	host.group.department.example.com is hosted on example.com's name		host.group.department.example.com is hosted on example.com's name
	servers). Let's assume a resolver which knows only the name servers		servers). Let's assume a resolver which knows only the name servers
	of .example. Without QNAME minimisation, it would send these		of .example. Without QNAME minimisation, it would send these
	.example nameservers a query for		.example nameservers a query for
	www.host.group.department.example.com and immediately get a specific		www.host.group.department.example.com and immediately get a specific
	referral or an answer, without the need for more queries to probe for		referral or an answer, without the need for more queries to probe for
	the zone cut. For such a name, a cold resolver with QNAME		the zone cut. For such a name, a cold resolver with QNAME
	minimisation will, depending how QNAME minimisation is implemented,		minimisation will, depending how QNAME minimisation is implemented,
	send more queries, one per label. Once the cache is warm, there will		send more queries, one per label. Once the cache is warm, there will
	be no difference with a traditional resolver. A possible solution is		be no difference with a traditional resolver. Actual testing is
	to always use the traditional algorithm when the cache is cold and		described in [huque-qnamemin]. Such deep domains are specially
	then to move to QNAME minimisation. This will decrease the privacy a
	bit but will guarantee no degradation of performance. Actual testing
	is described in [huque-qnamemin]. Such deep domains are specially
	common under ip6.arpa.		common under ip6.arpa.
	7. Security considerations		7. Security considerations
	QNAME minimisation's benefits are clear in the case where you want to		QNAME minimisation's benefits are clear in the case where you want to
	decrease exposure to the authoritative name server. But minimising		decrease exposure to the authoritative name server. But minimising
	the amount of data sent also, in part, addresses the case of a wire		the amount of data sent also, in part, addresses the case of a wire
	sniffer as well the case of privacy invasion by the servers.		sniffer as well the case of privacy invasion by the servers.
	(Encryption is of course a better defense against wire sniffers but,		(Encryption is of course a better defense against wire sniffers but,
	unlike QNAME minimisation, it changes the protocol and cannot be		unlike QNAME minimisation, it changes the protocol and cannot be
	deployed unilaterally. Also, the effect of QNAME minimisation on		deployed unilaterally. Also, the effect of QNAME minimisation on
	wire sniffers depend on whether the sniffer is, on the DNS path.)		wire sniffers depend on whether the sniffer is, on the DNS path.)
	QNAME minimisation offers zero protection against the recursive		QNAME minimisation offers zero protection against the recursive
	resolver, which still sees the full request coming from the stub		resolver, which still sees the full request coming from the stub
	resolver.		resolver.
	8. Implementation status - REMOVE BEFORE PUBLICATION		All the alternatives mentioned in Appendix B decrease privacy in the
			hope of improving performances. They must not be used if you want
			the maximum privacy.
			8. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION
	This section records the status of known implementations of the		This section records the status of known implementations of the
	protocol defined by this specification at the time of posting of this		protocol defined by this specification at the time of posting of this
	Internet-Draft, and is based on a proposal described in [RFC6982].		Internet-Draft, and is based on a proposal described in [RFC6982].
	The description of implementations in this section is intended to		The description of implementations in this section is intended to
	assist the IETF in its decision processes in progressing drafts to		assist the IETF in its decision processes in progressing drafts to
	RFCs. Please note that the listing of any individual implementation		RFCs. Please note that the listing of any individual implementation
	here does not imply endorsement by the IETF. Furthermore, no effort		here does not imply endorsement by the IETF. Furthermore, no effort
	has been spent to verify the information presented here that was		has been spent to verify the information presented here that was
	supplied by IETF contributors. This is not intended as, and must not		supplied by IETF contributors. This is not intended as, and must not
	be construed to be, a catalog of available implementations or their		be construed to be, a catalog of available implementations or their
	features. Readers are advised to note that other implementations may		features. Readers are advised to note that other implementations may
	exist.		exist.
	skipping to change at page 7, line 41		skipping to change at page 7, line 36
	The algorithm to find the zone cuts described in Appendix A is		The algorithm to find the zone cuts described in Appendix A is
	implemented with QNAME minimisation in the sample code zonecut.go		implemented with QNAME minimisation in the sample code zonecut.go
	[4]. It is also implemented, for a much longer time, in an option of		[4]. It is also implemented, for a much longer time, in an option of
	dig, "dig +trace", but without QNAME minimisation.		dig, "dig +trace", but without QNAME minimisation.
	Another implementation was done by Shumon Huque for testing, and is		Another implementation was done by Shumon Huque for testing, and is
	described in [huque-qnamemin].		described in [huque-qnamemin].
	9. Acknowledgments		9. Acknowledgments
	Thanks to Olaf Kolkman for the original idea although the concept is		Thanks to Olaf Kolkman for the original idea during a KLM flight from
	probably much older [5]. Thanks for Shumon Huque for implementation		Amsterdam to Vancouver, although the concept is probably much older
			[5]. Thanks for Shumon Huque and Marek Vavrusa for implementation
	and testing. Thanks to Mark Andrews and Francis Dupont for the		and testing. Thanks to Mark Andrews and Francis Dupont for the
	interesting discussions. Thanks to Brian Dickson, Warren Kumari,		interesting discussions. Thanks to Brian Dickson, Warren Kumari,
	Evan Hunt and David Conrad for remarks and suggestions. Thanks to		Evan Hunt and David Conrad for remarks and suggestions. Thanks to
	Mohsen Souissi for proofreading. Thanks to Tony Finch for the zone		Mohsen Souissi for proofreading. Thanks to Tony Finch for the zone
	cut algorithm in Appendix A and for discussion of the algorithm.		cut algorithm in Appendix A and for discussion of the algorithm.
	Thanks to Paul Vixie for pointing out that there are practical		Thanks to Paul Vixie for pointing out that there are practical
	advantages (besides privacy) to QNAME minimisation. Thanks to		advantages (besides privacy) to QNAME minimisation. Thanks to
	Phillip Hallam-Baker for the fallback on A queries, to deal with		Phillip Hallam-Baker for the fallback on A queries, to deal with
	broken servers. Thanks to Robert Edmonds for an interesting anti-		broken servers. Thanks to Robert Edmonds for an interesting anti-
	pattern.		pattern.
	skipping to change at page 8, line 44		skipping to change at page 8, line 44
	Kumari, W., Arends, R., Woolf, S., and D. Migault, "Highly		Kumari, W., Arends, R., Woolf, S., and D. Migault, "Highly
	Automated Method for Maintaining Expiring Records", draft-		Automated Method for Maintaining Expiring Records", draft-
	wkumari-dnsop-hammer-01 (work in progress), July 2014.		wkumari-dnsop-hammer-01 (work in progress), July 2014.
	[I-D.vixie-dnsext-resimprove]		[I-D.vixie-dnsext-resimprove]
	Vixie, P., Joffe, R., and F. Neves, "Improvements to DNS		Vixie, P., Joffe, R., and F. Neves, "Improvements to DNS
	Resolvers for Resiliency, Robustness, and Responsiveness",		Resolvers for Resiliency, Robustness, and Responsiveness",
	draft-vixie-dnsext-resimprove-00 (work in progress), June		draft-vixie-dnsext-resimprove-00 (work in progress), June
	2010.		2010.
	[dnsop] IETF, , "The DNSOP working group of IETF", March 2014,
	<https://datatracker.ietf.org/wg/dnsop/charter/>.
	[mockapetris-history]		[mockapetris-history]
	Mockapetris, P., "Private discussion", January 2015.		Mockapetris, P., "Private discussion", January 2015.
	[kaliski-minimum]		[kaliski-minimum]
	Kaliski, B., "Minimum Disclosure: What Information Does a		Kaliski, B., "Minimum Disclosure: What Information Does a
	Name Server Need to Do Its Job?", March 2015,		Name Server Need to Do Its Job?", March 2015,
	<http://blogs.verisigninc.com/blog/entry/		<http://blogs.verisigninc.com/blog/entry/
	minimum_disclosure_what_information_does>.		minimum_disclosure_what_information_does>.
	[huque-qnamemin]		[huque-qnamemin]
	skipping to change at page 11, line 5		skipping to change at page 10, line 49
	information about the relative use of the various QTYPEs, which may		information about the relative use of the various QTYPEs, which may
	be interesting for researchers (for instance if they try to follow		be interesting for researchers (for instance if they try to follow
	IPv6 deployment by counting the percentage of AAAA vs. A queries). A		IPv6 deployment by counting the percentage of AAAA vs. A queries). A
	variant of QNAME minimisation would be to keep the original QTYPE.		variant of QNAME minimisation would be to keep the original QTYPE.
	Another useful optimisation may be, in the spirit of the HAMMER idea		Another useful optimisation may be, in the spirit of the HAMMER idea
	[I-D.wkumari-dnsop-hammer] to probe in advance for the introduction		[I-D.wkumari-dnsop-hammer] to probe in advance for the introduction
	of zone cuts where none previously existed (i.e. confirm their		of zone cuts where none previously existed (i.e. confirm their
	continued absence, or discover them.)		continued absence, or discover them.)
			To address the "number of queries" issue, described in Section 6, a
			possible solution is to always use the traditional algorithm when the
			cache is cold and then to move to QNAME minimisation. This will
			decrease the privacy but will guarantee no degradation of
			performance.
	Author's Address		Author's Address
	Stephane Bortzmeyer		Stephane Bortzmeyer
	AFNIC		AFNIC
	1, rue Stephenson		1, rue Stephenson
	Montigny-le-Bretonneux 78180		Montigny-le-Bretonneux 78180
	France		France
	Phone: +33 1 39 30 83 46		Phone: +33 1 39 30 83 46
	Email: bortzmeyer+ietf@nic.fr		Email: bortzmeyer+ietf@nic.fr
End of changes. 18 change blocks.
	48 lines changed or deleted		46 lines changed or added
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/