rfc9665v5.txt		rfc9665.txt
	skipping to change at line 871 ¶		skipping to change at line 871 ¶
	with which the SRP Update was signed.		with which the SRP Update was signed.
	Service Description Instructions do not add any other resource		Service Description Instructions do not add any other resource
	records.		records.
	An SRP registrar MUST correctly handle compressed names in the SRV		An SRP registrar MUST correctly handle compressed names in the SRV
	target.		target.
	3.3.1.3. Host Description Instruction		3.3.1.3. Host Description Instruction
	Every SRP Update alway contains exactly one Host Description		Every SRP Update always contains exactly one Host Description
	Instruction.		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 the following:		appropriate hostname, it contains the following:
	* exactly one "Delete All RRsets From A Name" RR		* exactly one "Delete All RRsets From A Name" RR
	* 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
	the public key corresponding to the private key that was used to		the public key corresponding to the private key that was used to
	sign the message		sign the message
	skipping to change at line 1159 ¶		skipping to change at line 1159 ¶
	SRP requesters SHOULD assume that each lease ends N seconds after the		SRP requesters SHOULD assume that each lease ends N seconds after the
	update was first transmitted (where N is the granted lease duration).		update was first transmitted (where N is the granted lease duration).
	SRP registrars SHOULD assume that each lease ends N seconds after the		SRP registrars SHOULD assume that each lease ends N seconds after the
	update that was successfully processed was received. Because the		update that was successfully processed was received. Because the
	registrar will always receive the update after the SRP requester sent		registrar will always receive the update after the SRP requester sent
	it, this avoids the possibility of a race condition where the SRP		it, this avoids the possibility of a race condition where the SRP
	registrar prematurely removes a service when the SRP requester thinks		registrar prematurely removes a service when the SRP requester thinks
	the lease has not yet expired. In addition, the SRP requester MUST		the lease has not yet expired. In addition, the SRP requester MUST
	begin attempting to renew its lease in advance of the expected		begin attempting to renew its lease in advance of the expected
	expiration time, as required by the DNS Update Lease specification		expiration time, as required by the DNS Update Lease specification
	[RFC9664], to accomodate the situation where the clocks on the SRP		[RFC9664], to accommodate the situation where the clocks on the SRP
	requester and the SRP registrar do not run at precisely the same		requester and the SRP registrar do not run at precisely the same
	rate.		rate.
	SRP registrars MUST reject updates that do not include an EDNS(0)		SRP registrars MUST reject updates that do not include an EDNS(0)
	Update Lease option. DNS authoritative servers that allow both SRP		Update Lease option. DNS authoritative servers that allow both SRP
	and non-SRP DNS updates MAY accept updates that don't include leases,		and non-SRP DNS updates MAY accept updates that don't include leases,
	but they SHOULD differentiate between SRP Updates and other updates		but they SHOULD differentiate between SRP Updates and other updates
	and MUST reject updates that would otherwise be SRP Updates if they		and MUST reject updates that would otherwise be SRP Updates if they
	do not include leases.		do not include leases.
	skipping to change at line 1706 ¶		skipping to change at line 1706 ¶
	[RFC8765] Pusateri, T. and S. Cheshire, "DNS Push Notifications",		[RFC8765] Pusateri, T. and S. Cheshire, "DNS Push Notifications",
	RFC 8765, DOI 10.17487/RFC8765, June 2020,		RFC 8765, DOI 10.17487/RFC8765, June 2020,
	<https://www.rfc-editor.org/info/rfc8765>.		<https://www.rfc-editor.org/info/rfc8765>.
	[RFC9364] Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237,		[RFC9364] Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237,
	RFC 9364, DOI 10.17487/RFC9364, February 2023,		RFC 9364, DOI 10.17487/RFC9364, February 2023,
	<https://www.rfc-editor.org/info/rfc9364>.		<https://www.rfc-editor.org/info/rfc9364>.
	[RFC9664] Cheshire, S. and T. Lemon, "An EDNS(0) Option to Negotiate		[RFC9664] Cheshire, S. and T. Lemon, "An EDNS(0) Option to Negotiate
	Leases on DNS Updates", RFC 9664, DOI 10.17487/RFC9664,		Leases on DNS Updates", RFC 9664, DOI 10.17487/RFC9664,
	October 2024, <https://www.rfc-editor.org/info/rfc9664>.		June 2025, <https://www.rfc-editor.org/info/rfc9664>.
	11.2. Informative References		11.2. Informative References
	[IAB-ARPA] "Internet Architecture Board statement on the registration		[IAB-ARPA] "Internet Architecture Board statement on the registration
	of special use names in the ARPA domain", March 2017,		of special use names in the ARPA domain", March 2017,
	<https://www.iab.org/documents/correspondence-reports-		<https://www.iab.org/documents/correspondence-reports-
	documents/2017-2/iab-statement-on-the-registration-of-		documents/2017-2/iab-statement-on-the-registration-of-
	special-use-names-in-the-arpa-domain/>.		special-use-names-in-the-arpa-domain/>.
	[IPv6] IANA, "IANA IPv6 Special-Purpose Address Registry",		[IPv6] IANA, "IANA IPv6 Special-Purpose Address Registry",
End of changes. 3 change blocks.
	3 lines changed or deleted		3 lines changed or added
This html diff was produced by rfcdiff 1.48.