< draft-ietf-dmarc-aggregate-reporting-04.txt		draft-ietf-dmarc-aggregate-reporting-05.txt >
	DMARC A. Brotman (ed)		DMARC A. Brotman (ed)
	Internet-Draft Comcast, Inc.		Internet-Draft Comcast, Inc.
	Obsoletes: 7489 (if approved) 13 December 2021		Obsoletes: 7489 (if approved) 20 April 2022
	Intended status: Standards Track		Intended status: Standards Track
	Expires: 16 June 2022		Expires: 22 October 2022
	DMARC Aggregate Reporting		DMARC Aggregate Reporting
	draft-ietf-dmarc-aggregate-reporting-04		draft-ietf-dmarc-aggregate-reporting-05
	Abstract		Abstract
	DMARC allows for domain holders to request aggregate reports from		DMARC allows for domain holders to request aggregate reports from
	receivers. This report is an XML document, and contains extensible		receivers. This report is an XML document, and contains extensible
	elements that allow for other types of data to be specified later.		elements that allow for other types of data to be specified later.
	The aggregate reports can be submitted to the domain holder's		The aggregate reports can be submitted to the domain holder's
	specified destination as supported by the receiver.		specified destination as supported by the receiver.
	This document (along with others) obsoletes RFC7489.		This document (along with others) obsoletes RFC7489.
	skipping to change at page 1, line 37 ¶		skipping to change at page 1, line 37 ¶
	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 16 June 2022.		This Internet-Draft will expire on 22 October 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2022 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
	and restrictions with respect to this document. Code Components		and restrictions with respect to this document. Code Components
	extracted from this document must include Revised BSD License text as		extracted from this document must include Revised BSD License text as
	described in Section 4.e of the Trust Legal Provisions and are		described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Revised BSD License.		provided without warranty as described in the Revised BSD License.
	skipping to change at page 2, line 40 ¶		skipping to change at page 2, line 40 ¶
	2.6.3. Handling of Duplicates . . . . . . . . . . . . . . . 11		2.6.3. Handling of Duplicates . . . . . . . . . . . . . . . 11
	3. Verifying External Destinations . . . . . . . . . . . . . . . 11		3. Verifying External Destinations . . . . . . . . . . . . . . . 11
	4. Extensible Reporting . . . . . . . . . . . . . . . . . . . . 13		4. Extensible Reporting . . . . . . . . . . . . . . . . . . . . 13
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 14		6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 14
	6.1. Data Exposure Considerations . . . . . . . . . . . . . . 15		6.1. Data Exposure Considerations . . . . . . . . . . . . . . 15
	6.2. Report Recipients . . . . . . . . . . . . . . . . . . . . 15		6.2. Report Recipients . . . . . . . . . . . . . . . . . . . . 15
	6.3. Data Contained Within Reports (Tkt64) . . . . . . . . . . 16		6.3. Data Contained Within Reports (Tkt64) . . . . . . . . . . 16
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 16		7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
	8. Appendix A. DMARC XML Schema . . . . . . . . . . . . . . . . 16		8. Appendix A. DMARC XML Schema . . . . . . . . . . . . . . . . 16
	9. Appendix B. Sample Report . . . . . . . . . . . . . . . . . 23		9. Appendix B. Sample Report . . . . . . . . . . . . . . . . . 24
	10. Normative References . . . . . . . . . . . . . . . . . . . . 24		10. Normative References . . . . . . . . . . . . . . . . . . . . 25
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 25		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 25
	1. Introduction		1. Introduction
	A key component of DMARC is the ability for domain holders to request		A key component of DMARC is the ability for domain holders to request
	that receivers provide various types of reports. These reports allow		that receivers provide various types of reports. These reports allow
	domain holders to have insight into which IP addresses are sending on		domain holders to have insight into which IP addresses are sending on
	their behalf, and some insight into whether or not the volume may be		their behalf, and some insight into whether or not the volume may be
	legitimate. These reports expose information relating to the DMARC		legitimate. These reports expose information relating to the DMARC
	policy, as well as the outcome of SPF [RFC7208] & DKIM [RFC6376]		policy, as well as the outcome of SPF [RFC7208] & DKIM [RFC6376]
	skipping to change at page 5, line 7 ¶		skipping to change at page 5, line 7 ¶
	* The policy requested by the Domain Owner and the policy actually		* The policy requested by the Domain Owner and the policy actually
	applied (if different)		applied (if different)
	* The number of successful authentications		* The number of successful authentications
	* The counts of messages based on all messages received, even if		* The counts of messages based on all messages received, even if
	their delivery is ultimately blocked by other filtering agents.		their delivery is ultimately blocked by other filtering agents.
	The format for these reports is defined in Appendix A.		The format for these reports is defined in Appendix A.
	DMARC Aggregate Reports MUST contain two primary sections; one		DMARC Aggregate Reports MUST contain three primary sections; one
	consisting of descriptive information and the other a set of IP-		consisting of descriptive information (with two subsections), and the
	focused row-based data. Each report MUST contain data for only one		other a set of IP-focused row-based data. Each report MUST contain
	Author Domain. A single report MUST contain data for one policy		data for only one Author Domain. A single report MUST contain data
	configuration. If multiple configurations were observed during a		for one policy configuration. If multiple configurations were
	single reporting period, a reporting entity MAY choose to send		observed during a single reporting period, a reporting entity MAY
	multiple reports, otherwise the reporting entity SHOULD note only the		choose to send multiple reports, otherwise the reporting entity
	final configuration observed during the period. See below for		SHOULD note only the final configuration observed during the period.
	further information.		See below for further information.
	The informative section MUST contain two sub-sections. One will be		The informative section MUST contain two sub-sections. One will be
	the metadata section which MUST contain the fields related to		the metadata section which MUST contain the fields related to
	org_name, email, report_id, and date_range. Optional fields MAY		org_name, email, report_id, and date_range. Optional fields MAY
	include extra_contact_info, an error field, and an optional version		include extra_contact_info, an error field, and an optional version
	field. The version field, if present, MUST contain a 1.0 [!@RFC7489]		field. The version field, if present, MUST contain a 1.0 [!@RFC7489]
	or 2.0 [RefNeeded], noting to which version of the aggregate		or 2.0 [RefNeeded], noting to which version of the aggregate
	reporting specification the report adheres. The date_range section		reporting specification the report adheres. The date_range section
	which will note begin and end values as epoch timestamps. The other		which will note begin and end values as epoch timestamps. The other
	sub-section will be the policy_published, and record the policy		sub-section will be the policy_published, and record the policy
	configuration observed by the receiving system. Mandatory fields are		configuration observed by the receiving system. Mandatory fields are
	domain, p, sp. Optional fields are fo, adkim, aspf, and testing.		domain, p, sp. Optional fields are fo, adkim, aspf, testing, and
	There MAY be an optional third section for extensions.		version_published. There MAY be an optional third section for
			extensions.
	Within the data section, the report will contain row(s) of data		Within the data section, the report will contain row(s) of data
	stating which IPs were seen to have delivered messages for the Author		stating which IPs were seen to have delivered messages for the Author
	Domain to the receiving system. For each IP that is being reported,		Domain to the receiving system. For each IP that is being reported,
	there will be at least one record element, which will then have each		there will be at least one record element, which will then have each
	of a row, identifiers, and auth_results sub-element. Within the row		of a row, identifiers, and auth_results sub-element. Within the row
	element, there MUST be source_ip and count. There MUST also exist a		element, there MUST be source_ip and count. There MUST also exist a
	policy_evaluated, with subelements of disposition, dkim, and spf.		policy_evaluated, with sub-elements of disposition, dkim, and spf.
	There MAY be an element for reason, meant to include any notes the		There MAY be an element for reason, meant to include any notes the
	reporter might want to include as to why the disposition policy does		reporter might want to include as to why the disposition policy does
	not match the policy_published, such as a Local Policy override		not match the policy_published, such as a Local Policy override
	(possible values listed in Appendix A). The dkim and spf elements		(possible values listed in Appendix A). The dkim and spf elements
	MUST be the evaluated values as they relate to DMARC, not the values		MUST be the evaluated values as they relate to DMARC, not the values
	the receiver may have used when overriding the policy. Within the		the receiver may have used when overriding the policy. Within the
	identifiers element, there MUST exist the data that was used to apply		identifiers element, there MUST exist the data that was used to apply
	policy for the given IP. In most cases, this will be a header_from		policy for the given IP. In most cases, this will be a header_from
	element, which will contain the 5322.From domain from the message.		element, which will contain the 5322.From domain from the message.
	There MUST be an auth_results element within the 'record' element.		There MUST be an auth_results element within the 'record' element.
	This will contain the data related to authenticating the messages		This will contain the data related to authenticating the messages
	associated with this sending IP. The dkim subelement is optional as		associated with this sending IP. The dkim sub-element is optional as
	not all messages are signed, while there MUST be one spf subelement.		not all messages are signed, while there MUST be one spf sub-element.
	These elements MUST have a domain that was used during validation, as		These elements MUST have a domain that was used during validation, as
	well as result. The dkim element MUST include a selector element		well as result. The dkim element MUST include a selector element
	that was observed during validation. For the spf element, the result		that was observed during validation. For the spf element, the result
	element MUST contain a lower-case string where the value is one of		element MUST contain a lower-case string where the value is one of
	none/neutral/pass/fail/softfail/temperror/permerror. The dkim result		none/neutral/pass/fail/softfail/temperror/permerror. The dkim result
	MUST contain a lower-case string where the value is one of		MUST contain a lower-case string where the value is one of
	none/pass/fail/policy/neutral/temperror/permerror. Both the spf and		none/pass/fail/policy/neutral/temperror/permerror. Both the spf and
	dkim results may optionally include a human_readable field meant for		dkim results may optionally include a human_readable field meant for
	the report to convey more descriptive information back to the domain		the report to convey more descriptive information back to the domain
	holder relating to evaluation failures. There MAY exist an optional		holder relating to evaluation failures. There MAY exist an optional
	skipping to change at page 6, line 26 ¶		skipping to change at page 6, line 27 ¶
	In the same report, there MUST be a single Policy Domain, though		In the same report, there MUST be a single Policy Domain, though
	there could be multiple 5322.From Domains. Each 5322.From domain		there could be multiple 5322.From Domains. Each 5322.From domain
	will create its own record within the report. Consider the case		will create its own record within the report. Consider the case
	where there are three domains with traffic volume to report:		where there are three domains with traffic volume to report:
	example.com, foo.example.com, and bar.example.com. There will be		example.com, foo.example.com, and bar.example.com. There will be
	explicit DMARC records for example.com and bar.example.com, with		explicit DMARC records for example.com and bar.example.com, with
	distinct policies. There is no explicit DMARC record for		distinct policies. There is no explicit DMARC record for
	foo.example.com, so it will be reliant on the policy described for		foo.example.com, so it will be reliant on the policy described for
	example.com. For a report period, there would now be two reports.		example.com. For a report period, there would now be two reports.
	The first will be for bar.example.com, and contain only one record,		The first will be for bar.example.com, and contain only one record,
	for bar.example.com. The second report would be for example comain		for bar.example.com. The second report would be for example domain
	contain multiple record elements, one for example.com and one for		contain multiple record elements, one for example.com and one for
	foo.example.com (and extensibly, other record elements for subdomains		foo.example.com (and extensibly, other record elements for subdomains
	which likewise did not have an explicit DMARC policy declared).		which likewise did not have an explicit DMARC policy declared).
	2.1.2. DKIM Signatures in Aggregate Report		2.1.2. DKIM Signatures in Aggregate Report
	Within a single message, the possibility exists that there could be		Within a single message, the possibility exists that there could be
	multiple DKIM signatures. When validation of the message occurs,		multiple DKIM signatures. When validation of the message occurs,
	some signatures may pass, while some may not. As these pertain to		some signatures may pass, while some may not. As these pertain to
	DMARC, and especially to aggregate reporting, reporters may not find		DMARC, and especially to aggregate reporting, reporters may not find
	skipping to change at page 11, line 33 ¶		skipping to change at page 11, line 33 ¶
	* Discard upon receipt		* Discard upon receipt
	* Inspect the contents to evaluate the timestamps and reported data,		* Inspect the contents to evaluate the timestamps and reported data,
	act as appropriate		act as appropriate
	* Accept the duplicate data		* Accept the duplicate data
	When accepting the data, that's likely in a situation where it's not		When accepting the data, that's likely in a situation where it's not
	yet noticed, or a one-off experience. Long term, duplicate data is		yet noticed, or a one-off experience. Long term, duplicate data is
	not ideal. In the situation of a partial timeframe overlap, there is		not ideal. In the situation of a partial time frame overlap, there
	no clear way to distinguish the impact of the overlap. The receiver		is no clear way to distinguish the impact of the overlap. The
	would need to accept or reject the duplicate data in whole.		receiver would need to accept or reject the duplicate data in whole.
	3. Verifying External Destinations		3. Verifying External Destinations
	It is possible to specify destinations for the different reports that		It is possible to specify destinations for the different reports that
	are outside the authority of the Domain Owner making the request.		are outside the authority of the Domain Owner making the request.
	This allows domains that do not operate mail servers to request		This allows domains that do not operate mail servers to request
	reports and have them go someplace that is able to receive and		reports and have them go someplace that is able to receive and
	process them.		process them.
	Without checks, this would allow a bad actor to publish a DMARC		Without checks, this would allow a bad actor to publish a DMARC
	skipping to change at page 14, line 11 ¶		skipping to change at page 14, line 11 ¶
	future documents that utilize DMARC as a foundation. These		future documents that utilize DMARC as a foundation. These
	extensions MUST be properly formatted XML and meant to exist within		extensions MUST be properly formatted XML and meant to exist within
	the structure of a DMARC report. Extensions MAY exist in one of two		the structure of a DMARC report. Extensions MAY exist in one of two
	places; within the record element, or in a separate extensions		places; within the record element, or in a separate extensions
	element under the feedback element. In either case, the extensions		element under the feedback element. In either case, the extensions
	MUST contain a URI to the definition of the extension so that the		MUST contain a URI to the definition of the extension so that the
	receiver understands how to interpret the data.		receiver understands how to interpret the data.
	Within the record element:		Within the record element:
	...		...
	<record>		<record>
	<row>		<row>
	<source_ip>192.168.1.1</source_ip>		<source_ip>192.168.1.1</source_ip>
	<count>15</count>		<count>15</count>
	...		...
	<extensions>		<extensions>
	<extensionName definition="https://path/to/spec">		<extension name="extensionName" definition="https://path/to/spec">
	...		...
	</extensionName>		</extension>
	</extensions>		</extensions>
	</record>		</record>
	...		...
	Within the feedback element:		Within the feedback element:
	<feedback>		<feedback>
	...		...
	<extensions>		<extensions>
	<extensionName definition="https://path/to/spec">		<extension name="extensionName" definition="https://path/to/spec">
	<data>...</data>		<data>...</data>
	</extensionName>		</extension>
	</extensions>		</extensions>
	</feedback>		</feedback>
	In both cases "extensionName" should be replaced with an appropriate		In both cases "extensionName" should be replaced with an appropriate
	single-word title.		single-word title.
	A DMARC report receiver SHOULD NOT generate a processing error when		A DMARC report receiver SHOULD NOT generate a processing error when
	this <extensions> element is absent or empty. Furthermore, if a		this <extensions> element is absent or empty. Furthermore, if a
	processor is unable to handle an extension in a report, it SHOULD		processor is unable to handle an extension in a report, it SHOULD
	ignore the data, and continue to the next extension.		ignore the data, and continue to the next extension.
	5. IANA Considerations		5. IANA Considerations
	skipping to change at page 18, line 31 ¶		skipping to change at page 18, line 31 ¶
	<!-- The DMARC policy that is published by the sending domain		<!-- The DMARC policy that is published by the sending domain
	in this report. -->		in this report. -->
	<xs:complexType name="PolicyPublishedType">		<xs:complexType name="PolicyPublishedType">
	<xs:all>		<xs:all>
	<!-- The domain at which the DMARC record was found. -->		<!-- The domain at which the DMARC record was found. -->
	<xs:element name="domain" type="xs:string"		<xs:element name="domain" type="xs:string"
	minOccurs="1" maxOccurs="1"/>		minOccurs="1" maxOccurs="1"/>
	<!-- The version declared in the DMARC record found. -->		<!-- The version declared in the DMARC record found. -->
	<xs:element name="version_published" type="xs:decimal"		<xs:element name="version_published" type="xs:decimal"
	minOccurs="1" maxOccurs="1"/>		minOccurs="0" maxOccurs="1"/>
	<!-- The DKIM alignment mode. -->		<!-- The DKIM alignment mode. -->
	<xs:element name="adkim" type="AlignmentType"		<xs:element name="adkim" type="AlignmentType"
	minOccurs="0" maxOccurs="1"/>		minOccurs="0" maxOccurs="1"/>
	<!-- The SPF alignment mode. -->		<!-- The SPF alignment mode. -->
	<xs:element name="aspf" type="AlignmentType"		<xs:element name="aspf" type="AlignmentType"
	minOccurs="0" maxOccurs="1"/>		minOccurs="0" maxOccurs="1"/>
	<!-- The policy published for messages from the domain. -->		<!-- The policy published for messages from the domain. -->
	<xs:element name="p" type="DispositionType"		<xs:element name="p" type="DispositionType"
	minOccurs="0" maxOccurs="1"/>		minOccurs="1" maxOccurs="1"/>
	<!-- The policy published for messages from subdomains. -->		<!-- The policy published for messages from subdomains. -->
	<xs:element name="sp" type="DispositionType"		<xs:element name="sp" type="DispositionType"
	minOccurs="0" maxOccurs="1"/>		minOccurs="1" maxOccurs="1"/>
	<!-- The percent declared in the DMARC record -->		<!-- The percent declared in the DMARC record -->
	<xs:element name="testing" type="TestingType"		<xs:element name="testing" type="TestingType"
	minOccurs="0" maxOccurs="1"/>		minOccurs="0" maxOccurs="1"/>
	<!-- Failure reporting options in effect. -->		<!-- Failure reporting options in effect. -->
	<xs:element name="fo" type="xs:string"		<xs:element name="fo" type="xs:string"
	minOccurs="0" maxOccurs="1"/>		minOccurs="0" maxOccurs="1"/>
	</xs:all>		</xs:all>
	</xs:complexType>		</xs:complexType>
	<!-- Values for Testing mode attached to Policy -->		<!-- Values for Testing mode attached to Policy -->
	<xs:simpleType name="TestingType">		<xs:simpleType name="TestingType">
	skipping to change at page 20, line 40 ¶		skipping to change at page 20, line 40 ¶
	minOccurs="1" maxOccurs="1"/>		minOccurs="1" maxOccurs="1"/>
	<!-- The number of messages for which the		<!-- The number of messages for which the
	PolicyEvaluatedType was applied. -->		PolicyEvaluatedType was applied. -->
	<xs:element name="count" type="xs:integer"		<xs:element name="count" type="xs:integer"
	minOccurs="1" maxOccurs="1"/>		minOccurs="1" maxOccurs="1"/>
	<!-- The DMARC disposition applied to matching		<!-- The DMARC disposition applied to matching
	messages. -->		messages. -->
	<xs:element name="policy_evaluated"		<xs:element name="policy_evaluated"
	type="PolicyEvaluatedType"		type="PolicyEvaluatedType"
	minOccurs="1" maxOccurs="1"/>		minOccurs="1" maxOccurs="1"/>
			<xs:element name="extensions" type="ExtensionType"
			minOccurs="0" maxOccurs"unbounded"/>
	</xs:all>		</xs:all>
	</xs:complexType>		</xs:complexType>
	<xs:complexType name="IdentifierType">		<xs:complexType name="IdentifierType">
	<xs:all>		<xs:all>
	<!-- The envelope recipient domain. -->		<!-- The envelope recipient domain. -->
	<xs:element name="envelope_to" type="xs:string"		<xs:element name="envelope_to" type="xs:string"
	minOccurs="0"/>		minOccurs="0"/>
	<!-- The RFC5321.MailFrom domain. -->		<!-- The RFC5321.MailFrom domain. -->
	<xs:element name="envelope_from" type="xs:string"		<xs:element name="envelope_from" type="xs:string"
	skipping to change at page 22, line 23 ¶		skipping to change at page 22, line 25 ¶
	</xs:restriction>		</xs:restriction>
	</xs:simpleType>		</xs:simpleType>
	<xs:complexType name="SPFAuthResultType">		<xs:complexType name="SPFAuthResultType">
	<xs:all>		<xs:all>
	<!-- The checked domain. -->		<!-- The checked domain. -->
	<xs:element name="domain" type="xs:string"		<xs:element name="domain" type="xs:string"
	minOccurs="1" maxOccurs="1"/>		minOccurs="1" maxOccurs="1"/>
	<!-- The scope of the checked domain. -->		<!-- The scope of the checked domain. -->
	<xs:element name="scope" type="SPFDomainScope"		<xs:element name="scope" type="SPFDomainScope"
	minOccurs="1" maxOccurs="1"/>		minOccurs="0" maxOccurs="1"/>
	<!-- The SPF verification result. -->		<!-- The SPF verification result. -->
	<xs:element name="result" type="SPFResultType"		<xs:element name="result" type="SPFResultType"
	minOccurs="1" maxOccurs="1"/>		minOccurs="1" maxOccurs="1"/>
	<!-- Any extra information		<!-- Any extra information
	(e.g., from Authentication-Results).		(e.g., from Authentication-Results).
	The information in the field below should be for a		The information in the field below should be for a
	person to be provided with additional information		person to be provided with additional information
	that may be useful when debugging SPF authentication		that may be useful when debugging SPF authentication
	issues. This could include broken records, invalid		issues. This could include broken records, invalid
	DNS responses, etc.		DNS responses, etc.
	skipping to change at page 23, line 4 ¶		skipping to change at page 23, line 6 ¶
	<xs:complexType name="AuthResultType">		<xs:complexType name="AuthResultType">
	<xs:sequence>		<xs:sequence>
	<!-- There may be no DKIM signatures, or multiple DKIM		<!-- There may be no DKIM signatures, or multiple DKIM
	signatures. -->		signatures. -->
	<xs:element name="dkim" type="DKIMAuthResultType"		<xs:element name="dkim" type="DKIMAuthResultType"
	minOccurs="0" maxOccurs="unbounded"/>		minOccurs="0" maxOccurs="unbounded"/>
	<!-- There will always be at least one SPF result. -->		<!-- There will always be at least one SPF result. -->
	<xs:element name="spf" type="SPFAuthResultType" minOccurs="1"		<xs:element name="spf" type="SPFAuthResultType" minOccurs="1"
	maxOccurs="unbounded"/>		maxOccurs="unbounded"/>
	</xs:sequence>		</xs:sequence>
	</xs:complexType>		</xs:complexType>
	<!-- This element contains all the authentication results that		<!-- This element contains all the authentication results that
	were evaluated by the receiving system for the given set of		were evaluated by the receiving system for the given set of
	messages. -->		messages. -->
	<xs:complexType name="RecordType">		<xs:complexType name="RecordType">
	<xs:sequence>		<xs:sequence>
	<xs:element name="row" type="RowType"/>		<xs:element name="row" type="RowType"/>
	<xs:element name="identifiers" type="IdentifierType"		<xs:element name="identifiers" type="IdentifierType"
	minOccurs="1" maxOccurs="1"/>		minOccurs="1" maxOccurs="1"/>
	<xs:element name="auth_results" type="AuthResultType"		<xs:element name="auth_results" type="AuthResultType"
	minOccurs="1" maxOccurs="1"/>		minOccurs="1" maxOccurs="1"/>
	</xs:sequence>		</xs:sequence>
	</xs:complexType>		</xs:complexType>
			<xs:complexType name="ExtensionType">
			<xs:sequence>
			<xs:element name="extension" type="xs:string"
			minOccurs="0" maxOccurs="1"/>
			<xs:sequence minOccurs="1" maxOccurs="1">
			<xs:attribute name="name" use="required"/>
			<xs:attribute name="definition" use="required"/>
			</xs:sequence>
			</xs:sequence>
			</xs:complexType>
	<!--		<!--
	version: Version of the report format		version: Version of the report format
	-->		-->
	<!-- Parent -->		<!-- Parent -->
	<xs:element name="feedback">		<xs:element name="feedback">
	<xs:complexType>		<xs:complexType>
	<xs:sequence>		<xs:sequence>
	<xs:element name="version"		<xs:element name="version"
	minOccurs="0" maxOccurs="1" type="xs:decimal"/>		minOccurs="0" maxOccurs="1" type="xs:decimal"/>
	<xs:element name="report_metadata"		<xs:element name="report_metadata"
	minOccurs="1" maxOccurs="1"		minOccurs="1" maxOccurs="1"
	type="ReportMetadataType"/>		type="ReportMetadataType"/>
	<xs:element name="policy_published"		<xs:element name="policy_published"
	minOccurs="1" maxOccurs="1"		minOccurs="1" maxOccurs="1"
	type="PolicyPublishedType"/>		type="PolicyPublishedType"/>
	<xs:element name="record" type="RecordType"		<xs:element name="record" type="RecordType"
	minOccurs="1" maxOccurs="unbounded"/>		minOccurs="1" maxOccurs="unbounded"/>
			<xs:element name="extensions" type="ExtensionType"
			minOccurs="0" maxOccurs"unbounded"/>
	</xs:sequence>		</xs:sequence>
	</xs:complexType>		</xs:complexType>
	</xs:element>		</xs:element>
	</xs:schema>		</xs:schema>
	9. Appendix B. Sample Report		9. Appendix B. Sample Report
	<feedback>		<feedback>
	<report_metadata>		<report_metadata>
	<version>2.0</version>		<version>2.0</version>
End of changes. 22 change blocks.
	51 lines changed or deleted		67 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/