rfc8205v4.txt		rfc8205.txt
	skipping to change at page 15, line 25		skipping to change at page 15, line 25
	UPDATE message contains two Signature_Blocks and the BGPsec speaker		UPDATE message contains two Signature_Blocks and the BGPsec speaker
	only supports one of the two corresponding algorithm suites, then the		only supports one of the two corresponding algorithm suites, then the
	BGPsec speaker MUST remove the Signature_Block corresponding to the		BGPsec speaker MUST remove the Signature_Block corresponding to the
	algorithm suite that it does not understand. If the BGPsec speaker		algorithm suite that it does not understand. If the BGPsec speaker
	does not support the algorithm suites in any of the Signature_Blocks		does not support the algorithm suites in any of the Signature_Blocks
	contained in the received UPDATE message, then the BGPsec speaker		contained in the received UPDATE message, then the BGPsec speaker
	MUST NOT propagate the route advertisement with the BGPsec_PATH		MUST NOT propagate the route advertisement with the BGPsec_PATH
	attribute. (That is, if it chooses to propagate this route		attribute. (That is, if it chooses to propagate this route
	advertisement at all, it MUST do so as an unsigned BGP UPDATE		advertisement at all, it MUST do so as an unsigned BGP UPDATE
	message. See Section 4.4 for more information on converting to an		message. See Section 4.4 for more information on converting to an
	unsigned BGP message.)		unsigned BGP UPDATE message.)
	Note that in the case where the BGPsec_PATH has two Signature_Blocks		Note that in the case where the BGPsec_PATH has two Signature_Blocks
	(corresponding to different algorithm suites), the validation		(corresponding to different algorithm suites), the validation
	algorithm (see Section 5.2) deems a BGPsec UPDATE message to be		algorithm (see Section 5.2) deems a BGPsec UPDATE message to be
	'Valid' if there is at least one supported algorithm suite (and		'Valid' if there is at least one supported algorithm suite (and
	corresponding Signature_Block) that is deemed 'Valid'. This means		corresponding Signature_Block) that is deemed 'Valid'. This means
	that a 'Valid' BGPsec UPDATE message may contain a Signature_Block		that a 'Valid' BGPsec UPDATE message may contain a Signature_Block
	that is not deemed 'Valid' (e.g., contains signatures that BGPsec		that is not deemed 'Valid' (e.g., contains signatures that BGPsec
	does not successfully verify). Nonetheless, such Signature_Blocks		does not successfully verify). Nonetheless, such Signature_Blocks
	MUST NOT be removed. (See Section 8 for a discussion of the security		MUST NOT be removed. (See Section 8 for a discussion of the security
	skipping to change at page 25, line 16		skipping to change at page 25, line 16
	Next, the BGPsec speaker examines the Signature_Blocks in the		Next, the BGPsec speaker examines the Signature_Blocks in the
	BGPsec_PATH attribute. A Signature_Block corresponding to an		BGPsec_PATH attribute. A Signature_Block corresponding to an
	algorithm suite that the BGPsec speaker does not support is not		algorithm suite that the BGPsec speaker does not support is not
	considered in the validation process. If there is no Signature_Block		considered in the validation process. If there is no Signature_Block
	corresponding to an algorithm suite that the BGPsec speaker supports,		corresponding to an algorithm suite that the BGPsec speaker supports,
	then in order to consider the UPDATE message in the route selection		then in order to consider the UPDATE message in the route selection
	process, the BGPsec speaker MUST strip the Signature_Block(s),		process, the BGPsec speaker MUST strip the Signature_Block(s),
	reconstruct the AS_PATH from the Secure_Path (see Section 4.4), and		reconstruct the AS_PATH from the Secure_Path (see Section 4.4), and
	treat the UPDATE message as if it were received as an unsigned BGP		treat the UPDATE message as if it were received as an unsigned BGP
	update.		UPDATE message.
	For each remaining Signature_Block (corresponding to an algorithm		For each remaining Signature_Block (corresponding to an algorithm
	suite supported by the BGPsec speaker), the BGPsec speaker iterates		suite supported by the BGPsec speaker), the BGPsec speaker iterates
	through the Signature Segments in the Signature_Block, starting with		through the Signature Segments in the Signature_Block, starting with
	the most recently added segment (and concluding with the		the most recently added segment (and concluding with the
	least recently added segment). Note that there is a one-to-one		least recently added segment). Note that there is a one-to-one
	correspondence between Signature Segments and Secure_Path Segments		correspondence between Signature Segments and Secure_Path Segments
	within the BGPsec_PATH attribute. The following steps make use of		within the BGPsec_PATH attribute. The following steps make use of
	this correspondence:		this correspondence:
End of changes. 2 change blocks.
	2 lines changed or deleted		2 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/