rfc9255xml2.original.xml		rfc9255.xml
	<?xml version="1.0" encoding="utf-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<!-- <!DOCTYPE rfc SYSTEM "rfc2629.dtd"> -->		<!DOCTYPE rfc [
	<?rfc comments="yes"?>		<!ENTITY nbsp "&#160;">
	<?rfc compact="yes"?>		<!ENTITY zwsp "&#8203;">
	<?rfc subcompact="no"?>		<!ENTITY nbhy "&#8209;">
	<?rfc inline="yes"?>		<!ENTITY wj "&#8288;">
	<?rfc sortrefs="yes"?>		]>
	<?rfc symrefs="yes"?>
	<?rfc toc="yes"?>
	<?rfc tocdepth="6"?>
	<?rfc tocindent="yes"?>
	<?rfc tocompact="yes"?>
	<rfc category="std" consensus="true" submissionType="IETF" docName="draft-ietf-s
	idrops-rpki-has-no-identity-07" ipr="trust200902">
	<front>
	<title>The I in RPKI does not stand for Identity</title>		<rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-sidrops-rpki -has-no-identity-07" number="9255" submissionType="IETF" category="std" consensu s="true" ipr="trust200902" sortRefs="true" symRefs="true" tocInclude="true" tocD epth="6" xml:lang="en" updates="" obsoletes="" version="3">
	<author fullname="Randy Bush" initials="R." surname="Bush">		<!-- xml2rfc v2v3 conversion 3.12.2 -->
	<organization>Arrcus &amp; Internet Initiative Japan</organization>		<front>
	<address>		<title>The 'I' in RPKI Does Not Stand for Identity</title>
	<postal>		<seriesInfo name="RFC" value="9255"/>
	<street>5147 Crystal Springs</street>		<author fullname="Randy Bush" initials="R." surname="Bush">
	<city>Bainbridge Island</city>		<organization abbrev="Arrcus &amp; IIJ Research">Arrcus &amp; Internet Ini
	<region>WA</region>		tiative Japan Research</organization>
	<code>98110</code>		<address>
	<country>US</country>		<postal>
			<street>5147 Crystal Springs</street>
			<city>Bainbridge Island</city>
			<region>WA</region>
			<code>98110</code>
			<country>United States of America</country>
	</postal>		</postal>
	<email>randy@psg.com</email>		<email>randy@psg.com</email>
	</address>		</address>
	</author>		</author>
	<author initials="R." surname="Housley" fullname="Russ Housley">		<author initials="R." surname="Housley" fullname="Russ Housley">
	<organization abbrev="Vigil Security">Vigil Security, LLC</organization>		<organization abbrev="Vigil Security">Vigil Security, LLC</organization>
	<address>		<address>
	<postal>		<postal>
	<street>516 Dranesville Road</street>		<street>516 Dranesville Road</street>
	<city>Herndon, VA</city>		<city>Herndon</city>
			<region>VA</region>
	<code>20170</code>		<code>20170</code>
	<country>US</country>		<country>United States of America</country>
	</postal>		</postal>
	<email>housley@vigilsec.com</email>		<email>housley@vigilsec.com</email>
	</address>		</address>
	</author>		</author>
			<date year="2022" month="June" />
			<area>ops</area>
			<workgroup>sidrops</workgroup>
			<keyword>Public Key Infrastructure</keyword>
			<keyword>Security</keyword>
			<keyword>X.509</keyword>
			<keyword>Certificate</keyword>
	<date />		<abstract>
			<t>There is a false notion that Internet Number Resources (INRs) in
	<abstract>
	<t>There is a false notion that Internet Number Resources (INRs) in
	the RPKI can be associated with the real-world identity of the		the RPKI can be associated with the real-world identity of the
	'holder' of an INR. This document specifies that RPKI does not		'holder' of an INR. This document specifies that RPKI does not
	associate to the INR holder.</t>		associate to the INR holder.</t>
			</abstract>
	</abstract>
	<note title="Requirements Language">
	<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
	NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
	"MAY", and "OPTIONAL" in this document are to be interpreted as
	described in BCP 14 <xref target="RFC2119"/> <xref
	target="RFC8174"/> when, and only when, they appear in all capitals,
	as shown here.</t>
	</note>
	</front>		</front>
			<middle>
	<middle>		<section anchor="intro">
			<name>Introduction</name>
	<section anchor="intro" title="Introduction">		<t>The Resource Public Key Infrastructure (RPKI), see <xref target="RFC648
			0"/>, "represents the allocation hierarchy of IP
	<t>The Resource Public Key Infrastructure (RPKI), see <xref
	target="RFC6480"/>, "Represents the allocation hierarchy of IP
	address space and Autonomous System (AS) numbers," which are		address space and Autonomous System (AS) numbers," which are
	collectively known as Internet Number Resources (INRs). Since		collectively known as Internet Number Resources (INRs). Since
	initial deployment, the RPKI has grown to include other similar		initial deployment, the RPKI has grown to include other similar
	resource and routing data, e.g. Router Keying for BGPsec, <xref		resource and routing data, e.g., Router Keying for BGPsec <xref target="RFC8
	target="RFC8635"/>.</t>		635"/>.</t>
			<t>In security terms, the phrase "Public Key" implies there is also
	<t>In security terms, the phrase "Public Key" implies there is also
	a corresponding private key <xref target="RFC5280"/>. The RPKI		a corresponding private key <xref target="RFC5280"/>. The RPKI
	provides strong authority to the current holder of INRs; however,		provides strong authority to the current holder of INRs; however,
	some people a have a desire to use RPKI private keys to sign		some people have a desire to use RPKI private keys to sign
	arbitrary documents as the INR 'holder' of those resources with the		arbitrary documents as the INR 'holder' of those resources with the
	inappropriate expectation that the signature will be considered an		inappropriate expectation that the signature will be considered an
	attestation to the authenticity of the document content. But in		attestation to the authenticity of the document content. But, in
	reality, the RPKI certificate is only an authorization to speak for		reality, the RPKI certificate is only an authorization to speak for
	the explicitly identified INRs; it is explicitly not intended for		the explicitly identified INRs; it is explicitly not intended for
	authentication of the 'holders' of the INRs. This situation is		authentication of the 'holders' of the INRs. This situation is
	emphasized in Section 2.1 of <xref target="RFC6480"/>.</t>		emphasized in <xref target="RFC6480" section="2.1" sectionFormat="of"/>.</t>
			<t>It has been suggested that one could authenticate real-world
	<t>It has been suggested that one could authenticate real-world		business transactions with the signatures of INR holders. For example,
	business transactions with the signatures of INR holders. E.g.
	Bill's Bait and Sushi (BB&amp;S) could use the private key attesting		Bill's Bait and Sushi (BB&amp;S) could use the private key attesting
	to that they are the holder of their AS in the RPKI to sign a Letter		to that they are the holder of their AS in the RPKI to sign a Letter
	of Authorization (LOA) for some other party to rack and stack		of Authorization (LOA) for some other party to rack and stack
	hardware owned by BB&amp;S. Unfortunately, while this may be		hardware owned by BB&amp;S. Unfortunately, while this may be
	technically possible, it is neither appropriate nor meaningful.</t>		technically possible, it is neither appropriate nor meaningful.</t>
			<t>The 'I' in RPKI actually stands for "Infrastructure," as in
	<t>The I in RPKI actually stands for "Infrastructure," as in
	Resource Public Key Infrastructure, not for "Identity". In fact,		Resource Public Key Infrastructure, not for "Identity". In fact,
	the RPKI does not provide any association between INRs and the real		the RPKI does not provide any association between INRs and the real-world ho
	world holder(s) of those INRs. The RPKI provides authorization to		lder(s) of those INRs. The RPKI provides authorization to
	make assertions only regarding Internet Number Resources, such as IP		make assertions only regarding Internet Number Resources, such as IP
	prefixes or AS numbers, and data such as ASPA <xref		prefixes or AS numbers, and data such as <xref target="I-D.ietf-sidrops-aspa
	target="I-D.ietf-sidrops-aspa-profile"/>records.</t>		-profile">Autonomous System Provider Authorization (ASPA) records</xref>.</t>
			<t>In short, avoid the desire to use RPKI certificates for any
	<t>In short, avoid the desire to use RPKI certificates for any
	purpose other than the verification of authorizations associated		purpose other than the verification of authorizations associated
	with the delegation of INRs or attestations related to INRs.		with the delegation of INRs or attestations related to INRs.
	Instead, recognize that these authorizations and attestations take		Instead, recognize that these authorizations and attestations take
	place irrespective of the identity of a RPKI private key holder.</t>		place irrespective of the identity of an RPKI private key holder.</t>
			<section>
			<name>Requirements Language</name>
			<t>
			The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
			"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
			",
			"<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
			"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
			"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
			be
			interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
			target="RFC8174"/> when, and only when, they appear in all capitals, as
			shown here.
			</t>
	</section>		</section>
			</section>
	<section anchor="bottom" title="The RPKI is for Authorization">		<section anchor="bottom">
			<name>The RPKI is for Authorization</name>
	<t>The RPKI was designed and specified to sign certificates for use		<t>The RPKI was designed and specified to sign certificates for use
	within the RPKI itself and to generate Route Origin Authorizations		within the RPKI itself and to generate Route Origin Authorizations
	(ROAs), <xref target="RFC6480"/>, for use in routing. Its design		(ROAs) <xref target="RFC6480"/> for use in routing. Its design
	intentionally precluded use for attesting to real-world identity as,		intentionally precluded use for attesting to real-world identity as,
	among other issues, it would expose the Certification Authority (CA)		among other issues, it would expose the Certification Authority (CA)
	to liability.</t>		to liability.</t>
			<t>That the RPKI does not authenticate real-world identity is by
	<t>That the RPKI does not authenticate real-world identity is by
	design. If it tried to do so, aside from the liability, it would		design. If it tried to do so, aside from the liability, it would
	end in a world of complexity with no proof of termination.</t>		end in a world of complexity with no proof of termination.</t>
			<t>Registries such as the Regional Internet Registries (RIRs)
	<t>Registries such as the Regional Internet Registries (RIRs)		provide INR to real-world identity mapping through WHOIS <xref target="RFC39
	provide INR to real-world identity mapping through WHOIS, <xref		12"/> and similar services. They claim to be
	target="RFC3912"/>, and similar services. They claim to be		authoritative, at least for the INRs that they allocate.</t>
	authoritative, at least for the INRs which they allocate.</t>		<t>That is, RPKI-based credentials of INRs <bcp14>MUST NOT</bcp14> be used
			to
	<t>That is, RPKI-based credentials of INRs MUST NOT be used to
	authenticate real-world documents or transactions. That might be		authenticate real-world documents or transactions. That might be
	done with some formal external authentication of authority allowing		done with some formal external authentication of authority allowing
	an otherwise anonymous INR holder to authenticate the particular		an otherwise anonymous INR holder to authenticate the particular
	document or transaction. Given such external, i.e. non-RPKI,		document or transaction. Given such external, i.e. non-RPKI,
	verification of authority, the use of RPKI-based credentials adds no		verification of authority, the use of RPKI-based credentials adds no
	authenticity.</t>		authenticity.</t>
	</section>		</section>
			<section anchor="discuss">
	<section anchor="discuss" title="Discussion">		<name>Discussion</name>
			<t><xref target="RFC6480" section="2.1" sectionFormat="of">the RPKI base d
	<t>The RPKI base document, <xref target="RFC6480"/>, Section 2.1		ocument</xref> says explicitly "An important property of this PKI is that
	says explicitly "An important property of this PKI is that
	certificates do not attest to the identity of the subject."</t>		certificates do not attest to the identity of the subject."</t>
			<t><xref target="RFC7382" section="3.1" sectionFormat="of">"Template for a
	<t>The Template for a Certification Practice Statement (CPS) for the		Certification Practice Statement (CPS) for the Resource PKI (RPKI)"</xref> stat
	Resource PKI (RPKI) <xref target="RFC7382"/> Section 3.1, Naming,		es that
	makes very clear that "The Subject name in each certificate SHOULD		the Subject name in each certificate SHOULD NOT be meaningful
	NOT be meaningful;" and goes on to do so at some length.</t>		and goes on to explain this at some length.</t>
			<t>Normally, the INR holder does not hold the private key attesting
	<t>Normally, the INR holder does not hold the private key attesting		to their resources; the CA does. The INR
	to their resources; the Certification Authority (CA) does. The INR
	holder has a real-world business relationship with the CA for which		holder has a real-world business relationship with the CA for which
	they have likely signed real-world documents.</t>		they have likely signed real-world documents.</t>
			<t>As the INR holder does not have the keying material, they rely on
	<t>As the INR holder does not have the keying material, they rely on
	the CA, to which they presumably present credentials, to manipulate		the CA, to which they presumably present credentials, to manipulate
	their INRs. These credentials may be userid/password (with two		their INRs. These credentials may be user ID and password (with two-factor
	factor authentication one hopes), a hardware token, client browser		authentication one hopes), a hardware token, client browser
	certificates, etc.</t>		certificates, etc.</t>
			<t>Hence schemes such as Resource Tagged Attestations <xref target="I-D.ie
	<t>Hence schemes such as <xref target="I-D.ietf-sidrops-rpki-rta"/>		tf-sidrops-rpki-rta"/>
	and <xref target="I-D.ietf-sidrops-rpki-rsc"/> must go to great		and Signed Checklists <xref target="I-D.ietf-sidrops-rpki-rsc"/> must go to
			great
	lengths to extract the supposedly relevant keys from the CA.</t>		lengths to extract the supposedly relevant keys from the CA.</t>
			<t>For some particular INR, say, Bill's Bait and Sushi's Autonomous
	<t>For some particular INR, say Bill's Bait and Sushi's Autonomous
	System (AS) number, someone out on the net probably has the		System (AS) number, someone out on the net probably has the
	credentials to the CA account in which BB&amp;S's INRs are		credentials to the CA account in which BB&amp;S's INRs are
	registered. That could be the owner of BB&amp;S, Roberto's Taco		registered. That could be the owner of BB&amp;S, Randy's Taco
	Stand, an IT vendor, or the Government of Elbonia. One simply can		Stand, an IT vendor, or the Government of Elbonia. One simply can
	not know.</t>		not know.</t>
			<t>In large organizations, INR management is often compartmentalized
	<t>In large organizations, INR management is often compartmentalized
	with no authority over anything beyond dealing with INR		with no authority over anything beyond dealing with INR
	registration. The INR manager for Bill's Bait and Sushi is unlikely		registration. The INR manager for Bill's Bait and Sushi is unlikely
	to be authorized to conduct bank transactions for BB&amp;S, or even		to be authorized to conduct bank transactions for BB&amp;S, or even
	to authorize access to BB&amp;S's servers in some colocation		to authorize access to BB&amp;S's servers in some colocation
	facility.</t>		facility.</t>
			<t>Then there is the temporal issue. The holder of that AS may be
	<t>Then there is the temporal issue. The holder of that AS may be
	BB&amp;S today when some document was signed, and could be the		BB&amp;S today when some document was signed, and could be the
	Government of Elbonia tomorrow. Or the resource could have been		Government of Elbonia tomorrow. Or the resource could have been
	administratively moved from one CA to another, likely requiring a		administratively moved from one CA to another, likely requiring a
	change of keys. If so, how does one determine if the signature on		change of keys. If so, how does one determine if the signature on
	the real-world document is still valid?</t>		the real-world document is still valid?</t>
			<t>While Ghostbuster Records <xref target="RFC6493"/> may seem to
	<t>While Ghostbuster Records <xref target="RFC6493"/> may seem to
	identify real-world entities, their semantic content is completely		identify real-world entities, their semantic content is completely
	arbitrary, and does not attest to holding of any INRs. They are		arbitrary and does not attest to holding of any INRs. They are
	merely clues for operational support contact in case of technical		merely clues for operational support contact in case of technical
	RPKI problems.</t>		RPKI problems.</t>
			<t>Usually, before registering INRs, CAs require proof of an INR
	<t>Usually, before registering INRs, CAs require proof of an INR
	holding via external documentation and authorities. It is somewhat		holding via external documentation and authorities. It is somewhat
	droll that the CPS Template, <xref target="RFC7382"/>, does not		droll that the CPS Template <xref target="RFC7382"/> does not
	mention any diligence the CA must, or even might, conduct to assure		mention any diligence the CA must, or even might, conduct to assure
	the INRs are in fact owned by a registrant.</t>		the INRs are in fact owned by a registrant.</t>
			<t>That someone can provide 'proof of possession' of the private key
	<t>That someone can provide 'proof of possession' of the private key
	signing over a particular INR should not be taken to imply that they		signing over a particular INR should not be taken to imply that they
	are a valid legal representative of the organization in possession		are a valid legal representative of the organization in possession
	of that INR. They could be just an INR administrative person.</t>		of that INR. They could be in an INR administrative role, and not be a forma
			l
	<t>Autonomous System Numbers do not identify real-world entities.		representative of the organization.</t>
			<t>Autonomous System Numbers do not identify real-world entities.
	They are identifiers some network operators 'own' and are only used		They are identifiers some network operators 'own' and are only used
	for loop detection in routing. They have no inherent semantics other		for loop detection in routing. They have no inherent semantics other
	than uniqueness.</t>		than uniqueness.</t>
	</section>		</section>
			<section anchor="security">
	<section anchor="security" title="Security Considerations">		<name>Security Considerations</name>
			<t>Attempts to use RPKI data to authenticate real-world documents or
	<t>Attempts to use RPKI data to authenticate real-world documents or
	other artifacts requiring identity, while possibly cryptographically		other artifacts requiring identity, while possibly cryptographically
	valid within the RPKI, are misleading as to any authenticity.</t>		valid within the RPKI, are misleading as to any authenticity.</t>
			<t>When a document is signed with the private key associated with an
	<t>When a document is signed with the private key associated with an		RPKI certificate, the signer is speaking for the INRs (the IP address
	RPKI certificate, the signer is speaking for the INRs, the IP		space and AS numbers) in the certificate. This is not an identity; this
	address space and Autonomous System (AS) numbers, in the		is an authorization. In schemes such as Resource Tagged Attestations
	certificate. This is not an identity; this is an authorization. In		<xref target="I-D.ietf-sidrops-rpki-rta"/> and Signed Checklists <xref
	schemes such as <xref target="I-D.ietf-sidrops-rpki-rta"/> and <xref		target="I-D.ietf-sidrops-rpki-rsc"/>, the signed message further narrows
	target="I-D.ietf-sidrops-rpki-rsc"/> the signed message further		this scope of INRs. The INRs in the message are a subset of the INRs in
	narrows this scope of INRs. The INRs in the message are a subset of		the certificate. If the signature is valid, the message content comes
	the INRs in the certificate. If the signature is valid, the message		from a party that is authorized to speak for that subset of INRs.</t>
	content comes from a party that is authorized to speak for that		<t>Control of INRs for an entity could be used to falsely authorize
	subset of INRs.</t>
	<t>Control of INRs for an entity could be used to falsely authorize
	transactions or documents for which the INR manager has no		transactions or documents for which the INR manager has no
	authority.</t>		authority.</t>
	<!--
	<t>RPKI-based credentials of INRs MUST NOT be used to authenticate
	real-world documents or transactions without some formal external
	authentication of the INR and the authority for the actually
	anonymous INR holder to authenticate the particular document or
	transaction.</t>
	</section>
	<section anchor="iana" title="IANA Considerations">
	<t>This document has no IANA Considerations.</t>
	<!--
	<t>Note to RFC Editor: this section may be replaced on publication
	as an RFC.</t>
	-->
	</section>		</section>
			<section anchor="iana">
			<name>IANA Considerations</name>
			<t>This document has no IANA actions.</t>
			</section>
			</middle>
			<back>
	<section anchor="acks" title="Acknowledgments">		<displayreference target="I-D.ietf-sidrops-rpki-rsc" to="RPKI-RSC"/>
			<displayreference target="I-D.ietf-sidrops-rpki-rta" to="RPKI-RTA"/>
			<displayreference target="I-D.ietf-sidrops-aspa-profile" to="ASPA-PROFILE"/>
	<t>The authors thank George Michaelson and Job Snijders for lively		<references>
	discussion, Geoff Huston for some more formal text, Ties de Kock for		<name>References</name>
	useful suggestions, many directorate and IESG reviewers, and last		<references>
	but not least, Biff for the loan of Bill's Bait and Sushi.</t>		<name>Normative References</name>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.2119.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.5280.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.6480.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.7382.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.8174.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.8635.xml"/>
			</references>
			<references>
			<name>Informative References</name>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.3912.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.6493.xml"/>
	</section>		<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D .ietf-sidrops-rpki-rsc.xml"/>
	</middle>		<!-- [I-D.ietf-sidrops-rpki-rta] IESG state Expired.
			Full ref in order to correct initials. -->
			<reference anchor="I-D.ietf-sidrops-rpki-rta">
			<front>
			<title>A profile for Resource Tagged Attestations (RTAs)</title>
			<author initials="G." surname="Michaelson" fullname="George G. Michaelson"
			>
			<organization>Asia Pacific Network Information Centre</organization>
			</author>
			<author initials="G." surname="Huston" fullname="Geoff Huston">
			<organization>Asia Pacific Network Information Centre</organization>
			</author>
			<author initials="T." surname="Harrison" fullname="Tom Harrison">
			<organization>Asia Pacific Network Information Centre</organization>
			</author>
			<author initials="T." surname="Bruijnzeels" fullname="Tim Bruijnzeels">
			<organization>NLNet Labs B.V.</organization>
			</author>
			<author initials="M." surname="Hoffmann" fullname="Martin Hoffmann">
			<organization>NLNet Labs B.V.</organization>
			</author>
			<date month="January" day="21" year="2021" />
			</front>
			<seriesInfo name="Internet-Draft" value="draft-ietf-sidrops-rpki-rta-00" />
			</reference>
	<back>		<!-- [I-D.ietf-sidrops-aspa-profile] IESG state I-D Exists -->
	<references title="Normative References">		<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
	<?rfc include="reference.RFC.2119.xml"?>		.ietf-sidrops-aspa-profile.xml"/>
	<?rfc include="reference.RFC.5280.xml"?>		</references>
	<?rfc include="reference.RFC.6480.xml"?>
	<?rfc include="reference.RFC.7382.xml"?>
	<?rfc include="reference.RFC.8174.xml"?>
	<?rfc include="reference.RFC.8635.xml"?>
	</references>		</references>
	<references title="Informative References">		<section anchor="acks" numbered="false">
	<?rfc include="reference.RFC.3912.xml"?>		<name>Acknowledgments</name>
	<?rfc include="reference.RFC.6493.xml"?>		<t>The authors thank <contact fullname="George Michaelson"/> and <contact
	<?rfc include="reference.I-D.ietf-sidrops-rpki-rsc.xml"?>		fullname="Job Snijders"/> for lively
	<?rfc include="reference.I-D.ietf-sidrops-rpki-rta.xml"?>		discussion, <contact fullname="Geoff Huston"/> for some more formal text, <c
	<?rfc include="reference.I-D.ietf-sidrops-aspa-profile.xml"?>		ontact fullname="Ties de Kock"/> for
	</references>		useful suggestions, many directorate and IESG reviewers, and last
			but not least, Biff for the loan of Bill's Bait and Sushi.</t>
			</section>
	</back>		</back>
	</rfc>		</rfc>
End of changes. 51 change blocks.
	186 lines changed or deleted		199 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/