draft-ietf-dnssd-srp-06.txt		draft-ietf-dnssd-srp-07.txt
	Internet Engineering Task Force T. Lemon		Internet Engineering Task Force T. Lemon
	Internet-Draft S. Cheshire		Internet-Draft S. Cheshire
	Intended status: Standards Track Apple Inc.		Intended status: Standards Track Apple Inc.
	Expires: 22 May 2021 18 November 2020		Expires: 21 June 2021 18 December 2020
	Service Registration Protocol for DNS-Based Service Discovery		Service Registration Protocol for DNS-Based Service Discovery
	draft-ietf-dnssd-srp-06		draft-ietf-dnssd-srp-07
	Abstract		Abstract
	The Service Registration Protocol for DNS-Based Service Discovery		The Service Registration Protocol for DNS-Based Service Discovery
	uses the standard DNS Update mechanism to enable DNS-Based Service		uses the standard DNS Update mechanism to enable DNS-Based Service
	Discovery using only unicast packets. This makes it possible to		Discovery using only unicast packets. This makes it possible to
	deploy DNS Service Discovery without multicast, which greatly		deploy DNS Service Discovery without multicast, which greatly
	improves scalability and improves performance on networks where		improves scalability and improves performance on networks where
	multicast service is not an optimal choice, particularly 802.11		multicast service is not an optimal choice, particularly 802.11
	(Wi-Fi) and 802.15.4 (IoT) networks. DNS-SD Service registration		(Wi-Fi) and 802.15.4 (IoT) networks. DNS-SD Service registration
	skipping to change at page 1, line 38 ¶		skipping to change at page 1, line 38 ¶
	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 https://datatracker.ietf.org/drafts/current/.		Drafts is at https://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 22 May 2021.		This Internet-Draft will expire on 21 June 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 (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 2, line 22 ¶		skipping to change at page 2, line 22 ¶
	2.1. Protocol Variants . . . . . . . . . . . . . . . . . . . . 5		2.1. Protocol Variants . . . . . . . . . . . . . . . . . . . . 5
	2.1.1. Full-featured Hosts . . . . . . . . . . . . . . . . . 5		2.1.1. Full-featured Hosts . . . . . . . . . . . . . . . . . 5
	2.1.2. Constrained Hosts . . . . . . . . . . . . . . . . . . 6		2.1.2. Constrained Hosts . . . . . . . . . . . . . . . . . . 6
	2.1.3. Why two variants? . . . . . . . . . . . . . . . . . . 6		2.1.3. Why two variants? . . . . . . . . . . . . . . . . . . 6
	2.2. Protocol Details . . . . . . . . . . . . . . . . . . . . 6		2.2. Protocol Details . . . . . . . . . . . . . . . . . . . . 6
	2.2.1. What to publish . . . . . . . . . . . . . . . . . . . 7		2.2.1. What to publish . . . . . . . . . . . . . . . . . . . 7
	2.2.2. Where to publish it . . . . . . . . . . . . . . . . . 7		2.2.2. Where to publish it . . . . . . . . . . . . . . . . . 7
	2.2.3. How to publish it . . . . . . . . . . . . . . . . . . 8		2.2.3. How to publish it . . . . . . . . . . . . . . . . . . 8
	2.2.4. How to secure it . . . . . . . . . . . . . . . . . . 9		2.2.4. How to secure it . . . . . . . . . . . . . . . . . . 9
	2.2.5. Service Behavior . . . . . . . . . . . . . . . . . . 9		2.2.5. Service Behavior . . . . . . . . . . . . . . . . . . 9
	2.3. SRP Server Behavior . . . . . . . . . . . . . . . . . . . 11		2.3. SRP Server Behavior . . . . . . . . . . . . . . . . . . . 12
	2.3.1. Validation of Adds . . . . . . . . . . . . . . . . . 11		2.3.1. Validation of Adds . . . . . . . . . . . . . . . . . 12
	2.3.2. Valid SRP Update Requirements . . . . . . . . . . . . 13		2.3.2. Valid SRP Update Requirements . . . . . . . . . . . . 14
	2.3.3. FCFS Name And Signature Validation . . . . . . . . . 14		2.3.3. FCFS Name And Signature Validation . . . . . . . . . 14
	2.3.4. SRP Update response . . . . . . . . . . . . . . . . . 14		2.3.4. SRP Update response . . . . . . . . . . . . . . . . . 15
	2.3.5. Optional Behavior . . . . . . . . . . . . . . . . . . 14		2.3.5. Optional Behavior . . . . . . . . . . . . . . . . . . 15
	3. TTL Consistency . . . . . . . . . . . . . . . . . . . . . . . 15		3. TTL Consistency . . . . . . . . . . . . . . . . . . . . . . . 16
	4. Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . 16		4. Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . 17
	4.1. Cleaning up stale data . . . . . . . . . . . . . . . . . 16		4.1. Cleaning up stale data . . . . . . . . . . . . . . . . . 17
	5. Sleep Proxy . . . . . . . . . . . . . . . . . . . . . . . . . 17		5. Sleep Proxy . . . . . . . . . . . . . . . . . . . . . . . . . 18
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 18		6. Security Considerations . . . . . . . . . . . . . . . . . . . 19
	6.1. Source Validation . . . . . . . . . . . . . . . . . . . . 18		6.1. Source Validation . . . . . . . . . . . . . . . . . . . . 20
	6.2. SRP Server Authentication . . . . . . . . . . . . . . . . 19		6.2. SRP Server Authentication . . . . . . . . . . . . . . . . 20
	6.3. Required Signature Algorithm . . . . . . . . . . . . . . 19		6.3. Required Signature Algorithm . . . . . . . . . . . . . . 21
	7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19		7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 21
	8. Delegation of 'service.arpa.' . . . . . . . . . . . . . . . . 20		8. Delegation of 'service.arpa.' . . . . . . . . . . . . . . . . 21
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
	9.1. Registration and Delegation of 'service.arpa' as a		9.1. Registration and Delegation of 'service.arpa' as a
	Special-Use Domain Name . . . . . . . . . . . . . . . . . 20		Special-Use Domain Name . . . . . . . . . . . . . . . . . 21
	9.2. 'dnssd-srp' Service Name . . . . . . . . . . . . . . . . 20		9.2. 'dnssd-srp' Service Name . . . . . . . . . . . . . . . . 22
	9.3. 'dnssd-srp-tls' Service Name . . . . . . . . . . . . . . 20		9.3. 'dnssd-srp-tls' Service Name . . . . . . . . . . . . . . 22
	9.4. Anycast Address . . . . . . . . . . . . . . . . . . . . . 21		9.4. Anycast Address . . . . . . . . . . . . . . . . . . . . . 22
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21		10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
	11. Normative References . . . . . . . . . . . . . . . . . . . . 22		11. Normative References . . . . . . . . . . . . . . . . . . . . 23
	12. Informative References . . . . . . . . . . . . . . . . . . . 23		12. Informative References . . . . . . . . . . . . . . . . . . . 25
	Appendix A. Testing using standard RFC2136-compliant servers . . 24		Appendix A. Testing using standard RFC2136-compliant servers . . 26
	Appendix B. How to allow services to update standard		Appendix B. How to allow services to update standard
	RFC2136-compliant servers . . . . . . . . . . . . . . . . 25		RFC2136-compliant servers . . . . . . . . . . . . . . . . 27
	Appendix C. Sample BIND9 configuration for		Appendix C. Sample BIND9 configuration for
	default.service.arpa. . . . . . . . . . . . . . . . . . . 25		default.service.arpa. . . . . . . . . . . . . . . . . . . 27
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
	1. Introduction		1. Introduction
	DNS-Based Service Discovery [RFC6763] is a component of Zero		DNS-Based Service Discovery [RFC6763] is a component of Zero
	Configuration Networking [RFC6760] [ZC] [I-D.cheshire-dnssd-roadmap].		Configuration Networking [RFC6760] [ZC] [I-D.cheshire-dnssd-roadmap].
	This document describes an enhancement to DNS-Based Service Discovery		This document describes an enhancement to DNS-Based Service Discovery
	[RFC6763] that allows services to register their services using the		[RFC6763] that allows services to register their services using the
	DNS protocol rather than using Multicast DNS [RFC6762] (mDNS). There		DNS protocol rather than using Multicast DNS [RFC6762] (mDNS). There
	is already a large installed base of DNS-SD clients that can discover		is already a large installed base of DNS-SD clients that can discover
	skipping to change at page 9, line 42 ¶		skipping to change at page 9, line 42 ¶
	2.2.5.1. Public/Private key pair generation and storage		2.2.5.1. Public/Private key pair generation and storage
	The service generates a public/private key pair. This key pair MUST		The service generates a public/private key pair. This key pair MUST
	be stored in stable storage; if there is no writable stable storage		be stored in stable storage; if there is no writable stable storage
	on the SRP client, the SRP client MUST be pre-configured with a		on the SRP client, the SRP client MUST be pre-configured with a
	public/private key pair in read-only storage that can be used. This		public/private key pair in read-only storage that can be used. This
	key pair MUST be unique to the device. This key pair MUST be unique		key pair MUST be unique to the device. This key pair MUST be unique
	to the device. A device with rewritable storage should retain this		to the device. A device with rewritable storage should retain this
	key indefinitely. When the device changes ownership, it may be		key indefinitely. When the device changes ownership, it may be
	appropriate to erase the old key and install a new one. Therefore		appropriate to erase the old key and install a new one. Therefore,
	the key MAY be overwritten as a result of a full reset of the device		the SRP client on the device SHOULD provide a mechanism to overwrite
	(e.g., a "factory reset").		the key, for example as the result of a "factory reset."
	When sending DNS updates, the service includes a KEY record		When sending DNS updates, the service includes a KEY record
	containing the public portion of the key in each Host Description		containing the public portion of the key in each Host Description
	update and each Service Description update. Each KEY record MUST		update and each Service Description update. Each KEY record MUST
	contain the same public key. The update is signed using SIG(0),		contain the same public key. The update is signed using SIG(0),
	using the private key that corresponds to the public key in the KEY		using the private key that corresponds to the public key in the KEY
	record. The lifetimes of the records in the update is set using the		record. The lifetimes of the records in the update is set using the
	EDNS(0) Update Lease option [I-D.sekar-dns-ul].		EDNS(0) Update Lease option [I-D.sekar-dns-ul].
	The KEY record in Service Description updates MAY be omitted for		The KEY record in Service Description updates MAY be omitted for
	skipping to change at page 11, line 13 ¶		skipping to change at page 11, line 13 ¶
	cleaned up and made available for re-use.		cleaned up and made available for re-use.
	2.2.5.4. Compression in SRV records		2.2.5.4. Compression in SRV records
	Although [RFC2782] requires that the target name in the SRV record		Although [RFC2782] requires that the target name in the SRV record
	not be compressed, an SRP client SHOULD compress the target in the		not be compressed, an SRP client SHOULD compress the target in the
	SRV record. The motivation for _not_ compressing in RFC2782 is not		SRV record. The motivation for _not_ compressing in RFC2782 is not
	stated, but is assumed to be because a caching resolver that does not		stated, but is assumed to be because a caching resolver that does not
	understand the format of the SRV record might store it as binary data		understand the format of the SRV record might store it as binary data
	and thus return an invalid pointer in response to a query. This does		and thus return an invalid pointer in response to a query. This does
	not apply in the case of SRP case: an SRP server needs to understand		not apply in the case of SRP: an SRP server needs to understand SRV
	SRV records in order to validate the SRP update. Compression of the		records in order to validate the SRP update. Compression of the
	target potentially saves substantial space in the SRP update.		target potentially saves substantial space in the SRP update.
	2.2.5.5. Removing published services		2.2.5.5. Removing published services
	To remove a service registration, the SRP client retransmits its most		2.2.5.5.1. Removing all published services
	recent update with an Update Lease option that has a LEASE value of
	zero. If the registration is to be permanently removed, KEY-LEASE		To remove all the services registered to a particular host, the SRP
	should also be zero. Otherwise, it should have the same value it had		client retransmits its most recent update with an Update Lease option
	previously; this holds the name in reserve for when the SRP client is		that has a LEASE value of zero. If the registration is to be
	once again able to provide the service.		permanently removed, KEY-LEASE should also be zero. Otherwise, it
			should have the same value it had previously; this holds the name in
			reserve for when the SRP client is once again able to provide the
			service.
	SRP clients are normally expected to remove all service instances		SRP clients are normally expected to remove all service instances
	when removing a host. However, in some cases a SRP client may not		when removing a host. However, in some cases a SRP client may not
	have retained sufficient state to know that some service instance is		have retained sufficient state to know that some service instance is
	pointing to a host that it is removing. An SRP server can assume		pointing to a host that it is removing. This method of removing
	that all service instances pointing to a host entry that's being		services is intended for the case where the client is going offline
	removed are no longer valid. Therefore, SRP servers MAY remove all		and does not want its services advertised. Therefore, it is
	service instances pointing to a host when a host is removed, even if		sufficient for the client to send the Host Description Instruction
	the SRP client doesn't remove them explicitly.		(Section 2.3.1.3).
			To support this, when removing services based on the lease time being
			zero, an SRP server MUST remove all service instances pointing to a
			host when a host is removed, even if the SRP client doesn't list them
			explicitly. If the key lease time is nonzero, the SRP server MUST
			NOT delete the KEY records for these SRP clients.
			2.2.5.5.2. Removing some published services
			In some use cases a client may need to remove some specific service,
			without removing its other services. This can be accomplished in one
			of two ways. The first alternative is to send a valid SRP update
			where the only Service Discovery instruction is a remove-only
			instruction, and the only Service Description instruction is a
			remove-only instruction. In this case, the host lease will be
			updated with the lease time provided in the SRP update.
			The second alternative is to send a normal SRP update, but as in the
			first alternative, including a Service Discovery Instruction and a
			Service Description that delete the service being removed. This can
			be particularly useful when one service is being replaced with
			another, since this can be done in a single SRP Update.
			In neither of these cases is it permissible to delete the host. All
			services must point to a host. If a host is to be deleted, this must
			be done using the zero-lease deletion method.
	2.3. SRP Server Behavior		2.3. SRP Server Behavior
	2.3.1. Validation of Adds		2.3.1. Validation of Adds
	The SRP server first validates that the DNS Update is a syntactically		The SRP server first validates that the DNS Update is a syntactically
	and semantically valid DNS Update according to the rules specified in		and semantically valid DNS Update according to the rules specified in
	RFC2136.		RFC2136.
	SRP Updates consist of a set of _instructions_ that together add one		SRP Updates consist of a set of _instructions_ that together add or
	or more services. Each instruction consists either of a single add,		remove one or more services. Each instruction consists either of a
	or a delete followed by an add. When an instruction contains a		single add, a single delete, or a delete optionally followed by an
	delete and an add, the delete MUST precede the add.		add. When an instruction contains a delete and an add, the delete
			MUST precede the add.
	The SRP server checks each instruction in the SRP update to see that		The SRP server checks each instruction in the SRP update to see that
	it is either a Service Discovery update, a Service Description		it is either a Service Discovery update, a Service Description
	update, or a Host Description update. Order matters in DNS updates.		update, or a Host Description update. Order matters in DNS updates.
	Specifically, deletes must precede adds for records that the deletes		Specifically, deletes must precede adds for records that the deletes
	would affect; otherwise the add will have no effect. This is the		would affect; otherwise the add will have no effect. This is the
	only ordering constraint; aside from this constraint, updates may		only ordering constraint; aside from this constraint, updates may
	appear in whatever order is convenient when constructing the update.		appear in whatever order is convenient when constructing the update.
	Because the SRP update is a DNS update, it MUST contain a single		Because the SRP update is a DNS update, it MUST contain a single
	question that indicates the zone to be updated. Every delete and		question that indicates the zone to be updated. Every delete and
	update in an SRP update MUST be within the zone that is specified for		update in an SRP update MUST be within the zone that is specified for
	the SRP Update.		the SRP Update.
	2.3.1.1. Service Discovery Instruction		2.3.1.1. Service Discovery Instruction
	An Instruction is a Service Discovery Instruction if it contains		An instruction is a Service Discovery Instruction if it contains
	* exactly one "Add to an RRSet" ([RFC2136], Section 2.5.1) RR,		* exactly one "Add to an RRSet" or one "Delete an RR from an RRSet"
	* which is a PTR RR,		([RFC2136], Section 2.5.1) RR update,
			* which updates a PTR RR,
	* which points to a Service Instance Name		* which points to a Service Instance Name
	* for which a Service Description Instruction is present in the SRP		* for which a Service Description Instruction is present in the SRP
	Update.		Update
	* Service Discovery Instructions do not contain any deletes, and do
	not contain any other adds.		* if the Service Discovery update is an "Add to an RRSet"
			instruction, the Service Description Instruction does not match if
			it does not contain an "Add to an RRset" update for the SRV RR
			describing that service.
			* if the Service Discovery Instruction is an "Delete an RR from an
			RRSet" update, the Service Description Instruction does not match
			if it contains an "Add to an RRset" update.
			* Service Discovery Instructions do not contain any other add or
			delete updates.
	2.3.1.2. Service Description Instruction		2.3.1.2. Service Description Instruction
	An Instruction is a Service Description Instruction if, for the		An instruction is a Service Description Instruction if, for the
	appropriate Service Instance Name, it contains		appropriate Service Instance Name, it contains
	* exactly one "Delete all RRsets from a name" update for the service		* exactly one "Delete all RRsets from a name" update for the service
	instance name ([RFC2136], Section 2.5.3),		instance name ([RFC2136], Section 2.5.3),
	* exactly one "Add to an RRset" SRV RR,		* zero or one "Add to an RRset" SRV RR,
	* zero or one "Add to an RRset" KEY RR that contains the public key		* zero or one "Add to an RRset" KEY RR that, if present, contains
	corresponding to the private key that was used to sign the message		the public key corresponding to the private key that was used to
	(if present, the KEY MUST match the KEY RR given in the Host		sign the message (if present, the KEY MUST match the KEY RR given
	Description),		in the Host Description),
	* one or more "Add to an RRset" TXT RRs,		* zero or more "Add to an RRset" TXT RRs,
	* and the target of the SRV RR Add points to a hostname for which		* If there is one "Add to an RRset" SRV update, there MUST be at
	there is a Host Description Instruction in the SRP Update.		least one "Add to an RRset" TXT update.
			* the target of the SRV RR Add, if present points to a hostname for
			which there is a Host Description Instruction in the SRP Update,
			or
			* if there is no "Add to an RRset" SRV RR, then there is an existing
			SRV RR on the name specified in the "Delete all RRsets from a
			name" update that to a hostname for which there is a Host
			Description Instruction in the SRP Update, and there is a KEY RR
			on that name which matches the key with which the SRP Update was
			signed.
	* Service Descriptions Instructions do not modify any other RRs.		* Service Descriptions Instructions do not modify any other RRs.
	An SRP server MUST correctly handle compressed names in the SRV		An SRP server MUST correctly handle compressed names in the SRV
	target.		target.
	2.3.1.3. Host Description Instruction		2.3.1.3. Host Description Instruction
	An Instruction is a Host Description Instruction if, for the		An instruction is a Host Description Instruction if, for the
	appropriate hostname, it contains		appropriate hostname, it contains
	* exactly one "Delete all RRsets from a name" RR,		* exactly one "Delete all RRsets from a name" RR,
	* one or more "Add to an RRset" RRs of type A and/or AAAA,		* one or more "Add to an RRset" RRs of type A and/or AAAA,
	* A and/or AAAA records must be of sufficient scope to be reachable		* A and/or AAAA records must be of sufficient scope to be reachable
	by all hosts that might query the DNS. If a link-scope address or		by all hosts that might query the DNS. If a link-scope address or
	IPv4 autoconfiguration address is provided by the SRP client, the		IPv4 autoconfiguration address is provided by the SRP client, the
	SRP server MUST treat this as if no address records were received;		SRP server MUST treat this as if no address records were received;
	that is, the Host Description is not valid.		that is, the Host Description is not valid.
	* exactly one "Add to an RRset" RR that adds a KEY RR that contains		* exactly one "Add to an RRset" RR that adds a KEY RR that contains
	skipping to change at page 16, line 39 ¶		skipping to change at page 17, line 33 ¶
	The reasoning behind the different lease times is discussed in the		The reasoning behind the different lease times is discussed in the
	section on first-come, first-served naming (Section 2.2.4.1). SRP		section on first-come, first-served naming (Section 2.2.4.1). SRP
	servers may be configured with limits for these values. A default		servers may be configured with limits for these values. A default
	limit of two hours for the Lease and 14 days for the SIG(0) KEY are		limit of two hours for the Lease and 14 days for the SIG(0) KEY are
	currently thought to be good choices. Constrained devices with		currently thought to be good choices. Constrained devices with
	limited battery that wake infrequently are likely to negotiate longer		limited battery that wake infrequently are likely to negotiate longer
	leases. SRP clients that are going to continue to use names on which		leases. SRP clients that are going to continue to use names on which
	they hold leases should update well before the lease ends, in case		they hold leases should update well before the lease ends, in case
	the registration service is unavailable or under heavy load.		the registration service is unavailable or under heavy load.
			The lease time applies specifically to the host. All service
			instances, and all service entries for such service instances, depend
			on the host. When the lease on a host expires, the host and all
			services that reference it MUST be removed at the same time-it is
			never valid for a service instance to remain when the host it
			references has been removed. If the KEY record for the host is to
			remain, the KEY record for any services that reference it MUST also
			remain. However, the service PTR record MUST be removed, since it
			has no key associated with it, and since it is never valid to have a
			service PTR record for which there is no service instance on the
			target of the PTR record.
			SRP Servers SHOULD also track a lease time per service instance. The
			reason for doing this is that a client may re-register a host with a
			different set of services, and not remember that some different
			service instance had previously been registered. In this case, when
			that service instance lease expires, the SRP server SHOULD remove the
			service instance (although the KEY record for the service instance
			SHOULD be retained until the key lease on that service expires).
			This is beneficial because if the SRP client continues to renew the
			host, but never mentions the stale service again, the stale service
			will continue to be advertised.
	The SRP server MUST include an EDNS(0) Update Lease option in the		The SRP server MUST include an EDNS(0) Update Lease option in the
	response if the lease time proposed by the service has been shortened		response if the lease time proposed by the service has been shortened
	or lengthened. The service MUST check for the EDNS(0) Update Lease		or lengthened. The service MUST check for the EDNS(0) Update Lease
	option in the response and MUST use the lease times from that option		option in the response and MUST use the lease times from that option
	in place of the options that it sent to the server when deciding when		in place of the options that it sent to the server when deciding when
	to update its registration. The times may be shorter or longer than		to update its registration. The times may be shorter or longer than
	those specified in the SRP update; the SRP client must honor them in		those specified in the SRP update; the SRP client must honor them in
	either case.		either case.
	SRP clients should assume that each lease ends N seconds after the		SRP clients should assume that each lease ends N seconds after the
	skipping to change at page 19, line 18 ¶		skipping to change at page 20, line 39 ¶
	rules. However, in the case of a DNS service that accepts SRP		rules. However, in the case of a DNS service that accepts SRP
	updates, the intersection of the SRP update rules and whatever other		updates, the intersection of the SRP update rules and whatever other
	update rules are present must be considered very carefully.		update rules are present must be considered very carefully.
	For example, a normal, authenticated DNS update to any RR that was		For example, a normal, authenticated DNS update to any RR that was
	added using SRP, but that is authenticated using a different key,		added using SRP, but that is authenticated using a different key,
	could be used to override a promise made by the registration		could be used to override a promise made by the registration
	protocol, by replacing all or part of the service registration		protocol, by replacing all or part of the service registration
	information with information provided by an SRP client. An		information with information provided by an SRP client. An
	implementation that allows both kinds of updates should not allow DNS		implementation that allows both kinds of updates should not allow DNS
	Update clients to updateupdate records added by SRP clients using		Update clients that are using different authentication and
	different authentication and authorization credentials.		authorization credentialsto to update records added by SRP clients.
	6.2. SRP Server Authentication		6.2. SRP Server Authentication
	This specification does not provide a mechanism for validating		This specification does not provide a mechanism for validating
	responses from DNS servers to SRP clients. In the case of		responses from DNS servers to SRP clients. In the case of
	Constrained Network/Constrained Node clients, such validation isn't		Constrained Network/Constrained Node clients, such validation isn't
	practical because there's no way to establish trust. In principle, a		practical because there's no way to establish trust. In principle, a
	KEY RR could be used by a non-constrained SRP client to validate		KEY RR could be used by a non-constrained SRP client to validate
	responses from the server, but this is not required, nor do we		responses from the server, but this is not required, nor do we
	specify a mechanism for determining which key to use.		specify a mechanism for determining which key to use.
	skipping to change at page 21, line 48 ¶		skipping to change at page 23, line 34 ¶
	+----------------------+-----------------------------+		+----------------------+-----------------------------+
	| Global | True |		| Global | True |
	+----------------------+-----------------------------+		+----------------------+-----------------------------+
	| Reserved-by-protocol | False |		| Reserved-by-protocol | False |
	+----------------------+-----------------------------+		+----------------------+-----------------------------+
	Table 1		Table 1
	10. Acknowledgments		10. Acknowledgments
	Thanks to Toke Høiland-Jørgensen, Jonathan Hui and Esko		Thanks to Toke Høiland-Jørgensen, Jonathan Hui and Esko Dijk for
	Dijk for their thorough technical reviews, to Tamara Kemper for doing		their thorough technical reviews, to Tamara Kemper for doing a nice
	a nice developmental edit, Tim Wattenberg for doing a service		developmental edit, Tim Wattenberg for doing a service implementation
	implementation at the Montreal Hackathon at IETF 102, and Tom		at the Montreal Hackathon at IETF 102, and Tom Pusateri for reviewing
	Pusateri for reviewing during the hackathon and afterwards.		during the hackathon and afterwards.
	11. Normative References		11. Normative References
	[I-D.sekar-dns-ul]		[I-D.sekar-dns-ul]
	Cheshire, S. and T. Lemon, "Dynamic DNS Update Leases",		Cheshire, S. and T. Lemon, "Dynamic DNS Update Leases",
	Work in Progress, Internet-Draft, draft-sekar-dns-ul-02, 2		Work in Progress, Internet-Draft, draft-sekar-dns-ul-02, 2
	August 2018,		August 2018,
	<https://tools.ietf.org/html/draft-sekar-dns-ul-02>.		<https://tools.ietf.org/html/draft-sekar-dns-ul-02>.
	[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor		[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
End of changes. 23 change blocks.
	73 lines changed or deleted		144 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/