rfc9989v2.txt		rfc9989.txt
	skipping to change at line 551 ¶		skipping to change at line 551 ¶
	3.2.16. Public Suffix Operator (PSO)		3.2.16. Public Suffix Operator (PSO)
	A PSO is an organization that manages operations within a PSD,		A PSO is an organization that manages operations within a PSD,
	particularly the DNS records published for names at and under that		particularly the DNS records published for names at and under that
	domain name.		domain name.
	3.2.17. PSO-Controlled Domain Names		3.2.17. PSO-Controlled Domain Names
	PSO-Controlled Domain Names are names in the DNS that are managed by		PSO-Controlled Domain Names are names in the DNS that are managed by
	a PSO. PSO-Controlled Domain Names may have one label (e.g., ".com")		a PSO. PSO-Controlled Domain Names may have one label (e.g., ".com")
	or more (e.g., ".co.uk"), depending on the PSD's policy.		or more (e.g., ".co.uk"), depending on the PSO's policy.
	3.2.18. Report Consumer		3.2.18. Report Consumer
	A Report Consumer is an operator that receives reports from another		A Report Consumer is an operator that receives reports from another
	operator implementing the reporting mechanisms described in [RFC9990]		operator implementing the reporting mechanisms described in [RFC9990]
	and [RFC9991]. This term applies collectively to the system		and [RFC9991]. This term applies collectively to the system
	components that receive and process these reports and the		components that receive and process these reports and the
	organizations that operate those components.		organizations that operate those components.
	Report Consumers can receive reports concerning domains for which the		Report Consumers can receive reports concerning domains for which the
	skipping to change at line 3157 ¶		skipping to change at line 3157 ¶
	The Domain Owner from the previous example has used the aggregate		The Domain Owner from the previous example has used the aggregate
	reporting to discover some messaging systems that had not yet		reporting to discover some messaging systems that had not yet
	implemented DKIM correctly, but they are still seeing periodic		implemented DKIM correctly, but they are still seeing periodic
	authentication failures. To diagnose these intermittent problems,		authentication failures. To diagnose these intermittent problems,
	they wish to request per-message failure reports when authentication		they wish to request per-message failure reports when authentication
	failures occur.		failures occur.
	Not all Mail Receivers will honor such a request, but the Domain		Not all Mail Receivers will honor such a request, but the Domain
	Owner feels that any reports it does receive will be helpful enough		Owner feels that any reports it does receive will be helpful enough
	to justify publishing this record. The default per-message failure		to justify publishing this record. The default per-message failure
	report format [RFC6591] meets the Domain Owner's needs in this		report format [RFC9991] meets the Domain Owner's needs in this
	scenario.		scenario.
	The Domain Owner accomplishes this by adding the following to its		The Domain Owner accomplishes this by adding the following to its
	DMARC Policy Record from Appendix B.2.1:		DMARC Policy Record from Appendix B.2.1:
	* Per-message failure reports are sent via email to the address		* Per-message failure reports are sent via email to the address
	"auth-reports@example.com" ("ruf=mailto:auth-reports@example.com")		"auth-reports@example.com" ("ruf=mailto:auth-reports@example.com")
	To publish such a record, the DNS administrator for the Domain Owner		To publish such a record, the DNS administrator for the Domain Owner
	might create an entry like the following in the appropriate zone file		might create an entry like the following in the appropriate zone file
End of changes. 2 change blocks.
	2 lines changed or deleted		2 lines changed or added
This html diff was produced by rfcdiff 1.48.