rfc9498v10.txt		rfc9498.txt
	skipping to change at line 425 ¶		skipping to change at line 425 ¶
	originating zone or the record sets.		originating zone or the record sets.
	Local Host | Remote		Local Host | Remote
	| Storage		| Storage
	|		|
	| +---------+		| +---------+
	| / /|		| / /|
	| +---------+ |		| +---------+ |
	+-----------+ Name +----------+ Recursive | | | |		+-----------+ Name +----------+ Recursive | | | |
	| | Lookup | | Resolution | | Record | |		| | Lookup | | Resolution | | Record | |
	|Application|----------| Resolver |-------------|->| Storage | |		|Application|--------->| Resolver |-------------|->| Storage | |
	| |<---------| |<------------|--| |/		| |<---------| |<------------|--| |/
	+-----------+ Results +----------+ Intermediate| +---------+		+-----------+ Results +----------+ Intermediate| +---------+
	A Results |		A Results |
	| |		| |
	+---------+ |		+---------+ |
	/ | /| |		/ | /| |
	+---------+ | |		+---------+ | |
	| | | |		| | | |
	| Start | | |		| Start | | |
	| Zones | | |		| Zones | | |
	skipping to change at line 522 ¶		skipping to change at line 522 ¶
	Section 9.3 -- apply.		Section 9.3 -- apply.
	4.1. Zone Top-Level Domain (zTLD)		4.1. Zone Top-Level Domain (zTLD)
	A zTLD is a string that encodes the zone type and zone key into a		A zTLD is a string that encodes the zone type and zone key into a
	domain name suffix. A zTLD is used as a globally unique reference to		domain name suffix. A zTLD is used as a globally unique reference to
	a zone in the process of name resolution. It is created by encoding		a zone in the process of name resolution. It is created by encoding
	a binary concatenation of the zone type and zone key (see Figure 3).		a binary concatenation of the zone type and zone key (see Figure 3).
	The used encoding is a variation of the Crockford Base32 encoding		The used encoding is a variation of the Crockford Base32 encoding
	[CrockfordB32] called Base32GNS. The encoding and decoding symbols		[CrockfordB32] called Base32GNS. The encoding and decoding symbols
	for Base32GNS, including this variation, are defined in Table 4		for Base32GNS, including this variation, are defined in Table 4,
	(Appendix C). The functions for encoding and decoding based on		found in Appendix C. The functions for encoding and decoding based
	Table 4 are called Base32GNS-Encode and Base32GNS-Decode,		on Table 4 are called Base32GNS-Encode and Base32GNS-Decode,
	respectively.		respectively.
	0 8 16 24 32 40 48 56		0 8 16 24 32 40 48 56
	+-----+-----+-----+-----+-----+-----+-----+-----+		+-----+-----+-----+-----+-----+-----+-----+-----+
	| ZONE TYPE | ZONE KEY /		| ZONE TYPE | ZONE KEY /
	+-----+-----+-----+-----+ /		+-----+-----+-----+-----+ /
	/ /		/ /
	/ /		/ /
	+-----+-----+-----+-----+-----+-----+-----+-----+		+-----+-----+-----+-----+-----+-----+-----+-----+
	Figure 3: The Binary Representation of the zTLD		Figure 3: The Binary Representation of the zTLD
	The ZONE TYPE must be encoded in network byte order. The format of		The ZONE TYPE MUST be encoded in network byte order. The format of
	the ZONE KEY depends entirely on the ZONE TYPE.		the ZONE KEY depends entirely on the ZONE TYPE.
	Consequently, a zTLD is encoded and decoded as follows:		Consequently, a zTLD is encoded and decoded as follows:
	zTLD := Base32GNS-Encode(ztype||zkey)		zTLD := Base32GNS-Encode(ztype||zkey)
	ztype||zkey := Base32GNS-Decode(zTLD)		ztype||zkey := Base32GNS-Decode(zTLD)
	where "||" is the concatenation operator.		where "||" is the concatenation operator.
	The zTLD can be used "as is" as a rightmost label in a GNS name. If		The zTLD can be used "as is" as a rightmost label in a GNS name. If
	skipping to change at line 771 ¶		skipping to change at line 771 ¶
	The TTL field in the revocation message is informational. A		The TTL field in the revocation message is informational. A
	revocation MAY be discarded without checking the POW values or the		revocation MAY be discarded without checking the POW values or the
	signature if the TTL (in combination with TIMESTAMP) indicates that		signature if the TTL (in combination with TIMESTAMP) indicates that
	the revocation has already expired. The actual validity period of		the revocation has already expired. The actual validity period of
	the revocation MUST be determined by examining the leading zeroes in		the revocation MUST be determined by examining the leading zeroes in
	the POW values.		the POW values.
	The validity period of the revocation is calculated as (D'-D+1) *		The validity period of the revocation is calculated as (D'-D+1) *
	EPOCH * 1.1. The EPOCH is extended by 10% in order to deal with		EPOCH * 1.1. The EPOCH is extended by 10% in order to deal with
	unsynchronized clocks. The validity period added on top of the		poorly synchronized clocks. The validity period added on top of the
	TIMESTAMP yields the expiration date. If the current time is after		TIMESTAMP yields the expiration date. If the current time is after
	the expiration date, the revocation is considered stale.		the expiration date, the revocation is considered stale.
	Verified revocations MUST be stored locally. The implementation MAY		Verified revocations MUST be stored locally. The implementation MAY
	discard stale revocations and evict them from the local store at any		discard stale revocations and evict them from the local store at any
	time.		time.
	Implementations MUST broadcast received revocations if they are valid		It is important that implementations broadcast received revocations
	and not stale. Should the calculated validity period differ from the		if they are valid and not stale. Should the calculated validity
	TTL field value, the calculated value MUST be used as the TTL field		period differ from the TTL field value, the calculated value MUST be
	value when forwarding the revocation message. Systems might disagree		used as the TTL field value when forwarding the revocation message.
	on the current time, so implementations MAY use stale but otherwise		Systems might disagree on the current time, so implementations MAY
	valid revocations but SHOULD NOT broadcast them. Forwarded stale		use stale but otherwise valid revocations but SHOULD NOT broadcast
	revocations MAY be discarded by the receiver.		them. Forwarded stale revocations MAY be discarded by the receiver.
	Any locally stored revocation MUST be considered during delegation		Any locally stored revocation MUST be considered during delegation
	record processing (see Section 7.3.4).		record processing (see Section 7.3.4).
	5. Resource Records		5. Resource Records
	A GNS implementation SHOULD provide a mechanism for creating and		A GNS implementation SHOULD provide a mechanism for creating and
	managing local zones as well as a persistence mechanism (such as a		managing local zones as well as a persistence mechanism (such as a
	local database) for resource records. A new local zone is		local database) for resource records. A new local zone is
	established by selecting a zone type and creating a zone key pair.		established by selecting a zone type and creating a zone key pair.
End of changes. 5 change blocks.
	13 lines changed or deleted		13 lines changed or added
This html diff was produced by rfcdiff 1.48.