rfc9859v1.txt		rfc9859.txt
	skipping to change at line 91 ¶		skipping to change at line 91 ¶
	7.1. Normative References		7.1. Normative References
	7.2. Informative References		7.2. Informative References
	Appendix A. Efficiency and Convergence Issues in DNS Scanning		Appendix A. Efficiency and Convergence Issues in DNS Scanning
	A.1. Original NOTIFY for Zone Transfer Nudging		A.1. Original NOTIFY for Zone Transfer Nudging
	A.2. Similar Issues for DS Maintenance and Beyond		A.2. Similar Issues for DS Maintenance and Beyond
	Acknowledgements		Acknowledgements
	Authors' Addresses		Authors' Addresses
	1. Introduction		1. Introduction
	Traditional DNS notifications [RFC1996], which are here referred to		The original DNS notifications [RFC1996], which are here referred to
	as "NOTIFY(SOA)", are sent from a primary server to a secondary		as "NOTIFY(SOA)", are sent from a primary server to a secondary
	server to minimize the latter's convergence time to a new version of		server to minimize the latter's convergence time to a new version of
	the zone. This mechanism successfully addresses a significant		the zone. This mechanism successfully addresses a significant
	inefficiency in the original protocol.		inefficiency in the original protocol.
	Today, similar inefficiencies occur in new use cases, in particular		Today, similar inefficiencies occur in new use cases, in particular
	delegation maintenance (DS and NS record updates). Just as in the		delegation maintenance (DS and NS record updates). Just as in the
	NOTIFY(SOA) case, a new set of notification types will have a major		NOTIFY(SOA) case, a new set of notification types will have a major
	positive benefit by allowing the DNS infrastructure to completely		positive benefit by allowing the DNS infrastructure to completely
	sidestep these inefficiencies. For additional context, see		sidestep these inefficiencies. For additional context, see
	skipping to change at line 251 ¶		skipping to change at line 251 ¶
	section.		section.
	Parent operators participating in the discovery scheme for the		Parent operators participating in the discovery scheme for the
	purpose of delegation maintenance notifications MUST publish endpoint		purpose of delegation maintenance notifications MUST publish endpoint
	information using the record type defined in Section 2 under the		information using the record type defined in Section 2 under the
	_dsync subdomain of the parent zone, as described in the following		_dsync subdomain of the parent zone, as described in the following
	subsections.		subsections.
	There MUST NOT be more than one DSYNC record for each combination of		There MUST NOT be more than one DSYNC record for each combination of
	RRtype and Scheme. It is RECOMMENDED that zones containing DSYNC		RRtype and Scheme. It is RECOMMENDED that zones containing DSYNC
	records with DNSSEC be secure.		records be secured with DNSSEC.
	For practical purposes, the parent operator MAY delegate the _dsync		For practical purposes, the parent operator MAY delegate the _dsync
	domain as a separate zone and/or synthesize records under it. If		domain as a separate zone and/or synthesize records under it. If
	child-specificity is not needed, the parent can publish a static		child-specificity is not needed, the parent can publish a static
	wildcard DSYNC record.		wildcard DSYNC record.
	3.1. Wildcard Method		3.1. Wildcard Method
	If the parent operator itself performs CDS/CDNSKEY or CSYNC		If the parent operator itself performs CDS/CDNSKEY or CSYNC
	processing for some or all delegations, or if the parent operator		processing for some or all delegations, or if the parent operator
	wants to forward notifications to some other party, a default		wants to relay notifications to some other party, a default
	notification target may be specified as follows:		notification target may be specified as follows:
	*._dsync.example. IN DSYNC CDS NOTIFY port target		*._dsync.example. IN DSYNC CDS NOTIFY port target
	*._dsync.example. IN DSYNC CSYNC NOTIFY port target		*._dsync.example. IN DSYNC CSYNC NOTIFY port target
	To accommodate indirect delegation management models, the designated		To accommodate indirect delegation management models, the designated
	notification target may relay notifications to a third party (such as		notification target may relay notifications to a third party (such as
	the registrar, in ICANN's model). The details of such arrangements		the registrar, in ICANN's model). The details of such arrangements
	are out of scope for this document.		are out of scope for this document.
	skipping to change at line 401 ¶		skipping to change at line 401 ¶
	The recipient's attempt to act upon the delegation update request may		The recipient's attempt to act upon the delegation update request may
	fail for a variety of reasons (e.g., due to violation of the		fail for a variety of reasons (e.g., due to violation of the
	continuity requirement set forth in [RFC7344], Section 4.1). Such		continuity requirement set forth in [RFC7344], Section 4.1). Such
	failures may occur asynchronously, even after the NOTIFY response has		failures may occur asynchronously, even after the NOTIFY response has
	been sent.		been sent.
	In order to learn about such failures, senders MAY include an EDNS0		In order to learn about such failures, senders MAY include an EDNS0
	Report-Channel option [RFC9567] in the NOTIFY message to request that		Report-Channel option [RFC9567] in the NOTIFY message to request that
	the receiving side report any errors by making a report query with an		the receiving side report any errors by making a report query with an
	appropriate extended DNS error code as described in [RFC8914]. (The		appropriate extended DNS error (EDE) code as described in [RFC8914].
	prohibition of this option in queries ([RFC9567], Section 6.1) only		(The prohibition of this option in queries ([RFC9567], Section 6.1)
	applies to resolver queries and thus does not cover NOTIFY messages.)		only applies to resolver queries and thus does not cover NOTIFY
			messages.)
	When including this EDNS0 option, its agent domain MUST be		When including this EDNS0 option, the second label (QTYPE) of the
	subordinate or equal to one of the NS hostnames, as listed in the		report query name is equal to the qtype received in the NOTIFY
	child's delegation in the parent zone. This is to prevent malicious		message. Its agent domain MUST be subordinate or equal to one of the
	senders from causing the NOTIFY recipient to send unsolicited report		NS hostnames, as listed in the child's delegation in the parent zone.
	queries to unrelated third parties.		This is to prevent malicious senders from causing the NOTIFY
			recipient to send unsolicited report queries to unrelated third
			parties.
			For example, when receiving a NOTIFY(CDS) message for "example.com"
			with agent domain "errors.ns1.example.net", and when the requested DS
			update is found to break the delegation, then the following report
			query may be made (preferably over TCP):
			qname: _er.59.example.com.6._er.errors.ns1.example.net.
			qtype: TXT
	4.2.2. Roles		4.2.2. Roles
	While the CDS/CDNSKEY/CSYNC processing that follows the receipt of a		While the CDS/CDNSKEY/CSYNC processing that follows the receipt of a
	NOTIFY will often be performed by the registry, the protocol		NOTIFY will often be performed by the registry, the protocol
	anticipates that in some contexts (especially for ICANN gTLDs)		anticipates that in some contexts (especially for ICANN gTLDs)
	registrars may take on the task. In such cases, the current		registrars may take on the task. In such cases, the current
	registrar notification endpoint may be published, enabling		registrar notification endpoint may be published, enabling
	notifications to be directed to the appropriate target. The		notifications to be directed to the appropriate target. The
	mechanics of how this is arranged between registry and registrar are		mechanics of how this is arranged between registry and registrar are
	out of scope for this document; the protocol only offers the		out of scope for this document; the protocol only offers the
	possibility to arrange things such that from the child perspective,		possibility to arrange things such that from the child perspective,
	how the parent-side parties are organized is inconsequential:		how the parent-side parties are organized is inconsequential:
	Notifications are simply sent to the published address.		Notifications are simply sent to the published address.
	Because of the security model where a notification by itself never		Because of the security model where a notification by itself never
	causes a change (it can only speed up the time until the next check		causes a change (it can only speed up the time until the next check
	for the same thing), the sender's identity is not crucial. This		for the same thing), the sender's identity is not crucial. This
	opens up the possibility of having an arbitrary party (e.g., a side-		opens up the possibility of having an arbitrary party (e.g., a
	car service) send the notifications, enabling this functionality even		service separate from a nameserver) send the notifications, enabling
	before the emergence of native support in nameserver software.		this functionality even before the emergence of built-in support in
			nameserver software.
	4.3. Processing of NOTIFY Messages for Delegation Maintenance		4.3. Processing of NOTIFY Messages for Delegation Maintenance
	The following algorithm applies to NOTIFY(CDS) and NOTIFY(CSYNC)		The following algorithm applies to NOTIFY(CDS) and NOTIFY(CSYNC)
	processing.		processing.
	NOTIFY messages carrying notification payloads (records) for more		NOTIFY messages carrying notification payloads (records) for more
	than one child zone MUST be discarded, as sending them is an error.		than one child zone MUST be discarded, as sending them is an error.
	Otherwise, upon receipt of a (potentially forwarded) NOTIFY message		Otherwise, upon receipt of a (potentially forwarded) NOTIFY message
	skipping to change at line 454 ¶		skipping to change at line 466 ¶
	1. Acknowledge receipt by sending a NOTIFY response as described in		1. Acknowledge receipt by sending a NOTIFY response as described in
	[RFC1996], Section 4.7, and schedule an immediate check of the		[RFC1996], Section 4.7, and schedule an immediate check of the
	CDS/CDNSKEY/CSYNC RRsets published by that particular child zone		CDS/CDNSKEY/CSYNC RRsets published by that particular child zone
	(as appropriate for the type of NOTIFY received).		(as appropriate for the type of NOTIFY received).
	If the NOTIFY message contains an EDNS0 Report-Channel option		If the NOTIFY message contains an EDNS0 Report-Channel option
	[RFC9567] with an agent domain subordinate or equal to one of the		[RFC9567] with an agent domain subordinate or equal to one of the
	NS hostnames listed in the delegation, the processing party		NS hostnames listed in the delegation, the processing party
	SHOULD report any errors occurring during CDS/CDNSKEY/CSYNC		SHOULD report any errors occurring during CDS/CDNSKEY/CSYNC
	processing by sending a report query with an appropriate extended		processing by sending a report query with an appropriate extended
	DNS error code as described in [RFC8914]. Reporting may be done		DNS error (EDE) code as described in [RFC8914]. Reporting may be
	asynchronously (outside of the NOTIFY transaction).		done asynchronously (outside of the NOTIFY transaction).
	When using periodic scanning, notifications preempt the scanning		When using periodic scanning, notifications preempt the scanning
	timer. If the NOTIFY-induced check finds that the CDS/CDNSKEY/		timer. If the NOTIFY-induced check finds that the CDS/CDNSKEY/
	CSYNC RRset is indeed new or has changed, the corresponding		CSYNC RRset is indeed new or has changed, the corresponding
	child's timer may be reset and the scanning frequency reduced		child's timer may be reset and the scanning frequency reduced
	(e.g., to once a week). If a CDS/CDNSKEY/CSYNC change is later		(e.g., to once a week). If a CDS/CDNSKEY/CSYNC change is later
	detected through scanning (without having received a		detected through scanning (without having received a
	notification), the NOTIFY-related state SHOULD be cleared,		notification), the NOTIFY-related state SHOULD be cleared,
	reverting to the default scanning schedule for this child.		reverting to the default scanning schedule for this child.
	skipping to change at line 523 ¶		skipping to change at line 535 ¶
	records of interest (for example, NOTIFY(CDS) will cause CDS/CDNSKEY		records of interest (for example, NOTIFY(CDS) will cause CDS/CDNSKEY
	queries). When done using standard DNS, the size of these queries is		queries). When done using standard DNS, the size of these queries is
	comparable to that of the NOTIFY messages themselves, rendering any		comparable to that of the NOTIFY messages themselves, rendering any
	amplification attempts futile. The number of queries triggered per		amplification attempts futile. The number of queries triggered per
	notification is also limited by the requirement that a NOTIFY message		notification is also limited by the requirement that a NOTIFY message
	can refer to one child only.		can refer to one child only.
	However, when the outgoing query occurs via encrypted transport, some		However, when the outgoing query occurs via encrypted transport, some
	amplification is possible, both with respect to bandwidth and		amplification is possible, both with respect to bandwidth and
	computational burden. In this case, the usual principle of bounding		computational burden. In this case, the usual principle of bounding
	the work applies, even under unreasonable events.		the work applies, even under unforeseen events.
	Therefore, receivers MUST implement rate limiting for notification		Therefore, receivers MUST implement rate limiting for notification
	processing. It is RECOMMENDED to configure rate limiting		processing. It is RECOMMENDED to configure rate limiting
	independently for both the notification's source IP address and the		independently for both the notification's source IP address and the
	name of the zone that is conveyed in the NOTIFY message. Rate		name of the zone that is conveyed in the NOTIFY message. Rate
	limiting also mitigates the processing load from garbage		limiting also mitigates the processing load from garbage
	notifications.		notifications.
	Alternative solutions (such as signing notifications and validating		Alternative solutions (such as signing notifications and validating
	their signatures) appear significantly more expensive without		their signatures) appear significantly more expensive without
	skipping to change at line 570 ¶		skipping to change at line 582 ¶
	IANA has created the following new registry in the "Domain Name		IANA has created the following new registry in the "Domain Name
	System (DNS) Parameters" registry group:		System (DNS) Parameters" registry group:
	Name: DSYNC: Location of Synchronization Endpoints		Name: DSYNC: Location of Synchronization Endpoints
	Registration Procedure: Expert Review		Registration Procedure: Expert Review
	Reference: RFC 9859		Reference: RFC 9859
	The initial contents for the registry are as follows:		The initial contents for the registry are as follows:
	+========+=========+==========+=======================+===========+		+========+===================+==========================+===========+
	| RRtype | Scheme | Mnemonic | Purpose | Reference |		| RRtype | Scheme (Mnemonic) | Purpose | Reference |
	+========+=========+==========+=======================+===========+		+========+===================+==========================+===========+
	| | 0 | | Null scheme (no-op) | RFC 9859 |		| | 0 | Null scheme (no-op) | RFC 9859 |
	+--------+---------+----------+-----------------------+-----------+		+--------+-------------------+--------------------------+-----------+
	| CDS | 1 | NOTIFY | Delegation management | RFC 9859 |		| CDS | 1 (NOTIFY) | Delegation management | RFC 9859 |
	+--------+---------+----------+-----------------------+-----------+		+--------+-------------------+--------------------------+-----------+
	| CSYNC | 1 | NOTIFY | Delegation management | RFC 9859 |		| CSYNC | 1 (NOTIFY) | Delegation management | RFC 9859 |
	+--------+---------+----------+-----------------------+-----------+		+--------+-------------------+--------------------------+-----------+
	| | 2-127 | | Unassigned | |		| | 2-127 | Unassigned | |
	+--------+---------+----------+-----------------------+-----------+		+--------+-------------------+--------------------------+-----------+
	| | 128-255 | | Reserved for Private | RFC 9859 |		| | 128-255 | Reserved for Private | RFC 9859 |
	| | | | Use | |		| | | Use | |
	+--------+---------+----------+-----------------------+-----------+		+--------+-------------------+--------------------------+-----------+
	Table 1		Table 1
	Requests to register additional entries MUST include the following		Requests to register additional entries MUST include the following
	fields:		fields:
	RRtype: An RRtype that is defined for use		RRtype: An RRtype that is defined for use
	Scheme: The mode used for contacting the desired notification		Scheme: The mode used for contacting the desired notification
	address		address
	Mnemonic: The scheme's shorthand string used in presentation format		Mnemonic: The scheme's shorthand string used in presentation format
	skipping to change at line 614 ¶		skipping to change at line 626 ¶
	that the usage is not going to duplicate one that is already		that the usage is not going to duplicate one that is already
	registered and that the point is likely to be used in deployments.		registered and that the point is likely to be used in deployments.
	The code points tagged as "Private Use" are intended for testing		The code points tagged as "Private Use" are intended for testing
	purposes and closed environments. Code points in other ranges		purposes and closed environments. Code points in other ranges
	should not be assigned for testing.		should not be assigned for testing.
	* A specification of a scheme is desirable, but early assignment		* A specification of a scheme is desirable, but early assignment
	before a specification is available is also possible. When		before a specification is available is also possible. When
	specifications are not provided, the description provided needs to		specifications are not provided, the description provided needs to
	have sufficient information to identify what the point is being		have sufficient information to identify what the point is being
	used for.		used for. A scheme number may optionally have exactly one
			mnemonic.
	* Experts should take into account that field values are fit for		* Experts should take into account that field values are fit for
	purpose. For example, the mnemonic should be indicative and have		purpose. For example, the mnemonic should be indicative and have
	a plausible connection to the scheme's notification mechanism.		a plausible connection to the scheme's notification mechanism.
	6.3. _dsync Underscore Name		6.3. _dsync Underscore Name
	Per [RFC8552], IANA has registered the following entries to the		Per [RFC8552], IANA has registered the following entries to the
	"Underscored and Globally Scoped DNS Node Names" registry within the		"Underscored and Globally Scoped DNS Node Names" registry within the
	"Domain Name System (DNS) Parameters" registry group:		"Domain Name System (DNS) Parameters" registry group:
	skipping to change at line 708 ¶		skipping to change at line 721 ¶
	DOI 10.17487/RFC9567, April 2024,		DOI 10.17487/RFC9567, April 2024,
	<https://www.rfc-editor.org/info/rfc9567>.		<https://www.rfc-editor.org/info/rfc9567>.
	[RFC9615] Thomassen, P. and N. Wisiol, "Automatic DNSSEC		[RFC9615] Thomassen, P. and N. Wisiol, "Automatic DNSSEC
	Bootstrapping Using Authenticated Signals from the Zone's		Bootstrapping Using Authenticated Signals from the Zone's
	Operator", RFC 9615, DOI 10.17487/RFC9615, July 2024,		Operator", RFC 9615, DOI 10.17487/RFC9615, July 2024,
	<https://www.rfc-editor.org/info/rfc9615>.		<https://www.rfc-editor.org/info/rfc9615>.
	7.2. Informative References		7.2. Informative References
	[DNSSEC-AUTO]
	Wisser, U., Huque, S., and J. Stenstam, "DNSSEC
	automation", Work in Progress, Internet-Draft, draft-ietf-
	dnsop-dnssec-automation-03, 19 October 2024,
	<https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-
	dnssec-automation-03>.
	[RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC		[RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC
	Operational Practices, Version 2", RFC 6781,		Operational Practices, Version 2", RFC 6781,
	DOI 10.17487/RFC6781, December 2012,		DOI 10.17487/RFC6781, December 2012,
	<https://www.rfc-editor.org/info/rfc6781>.		<https://www.rfc-editor.org/info/rfc6781>.
	[RFC7583] Morris, S., Ihren, J., Dickinson, J., and W. Mekking,		[RFC7583] Morris, S., Ihren, J., Dickinson, J., and W. Mekking,
	"DNSSEC Key Rollover Timing Considerations", RFC 7583,		"DNSSEC Key Rollover Timing Considerations", RFC 7583,
	DOI 10.17487/RFC7583, October 2015,		DOI 10.17487/RFC7583, October 2015,
	<https://www.rfc-editor.org/info/rfc7583>.		<https://www.rfc-editor.org/info/rfc7583>.
	[RFC8901] Huque, S., Aras, P., Dickinson, J., Vcelak, J., and D.		[RFC8901] Huque, S., Aras, P., Dickinson, J., Vcelak, J., and D.
	Blacka, "Multi-Signer DNSSEC Models", RFC 8901,		Blacka, "Multi-Signer DNSSEC Models", RFC 8901,
	DOI 10.17487/RFC8901, September 2020,		DOI 10.17487/RFC8901, September 2020,
	<https://www.rfc-editor.org/info/rfc8901>.		<https://www.rfc-editor.org/info/rfc8901>.
	Appendix A. Efficiency and Convergence Issues in DNS Scanning		Appendix A. Efficiency and Convergence Issues in DNS Scanning
	A.1. Original NOTIFY for Zone Transfer Nudging		A.1. Original NOTIFY for Zone Transfer Nudging
	[RFC1996] introduced the concept of a DNS Notify message, which was		[RFC1996] introduced the concept of a DNS NOTIFY message, which was
	used to improve the convergence time for secondary servers when a DNS		used to improve the convergence time for secondary servers when a DNS
	zone had been updated in the primary server. The basic idea was to		zone had been updated in the primary server. The basic idea was to
	augment the traditional "pull" mechanism (a periodic SOA query) with		augment the original "pull" mechanism (a periodic SOA query) with a
	a "push" mechanism (a Notify) for a common case that was otherwise		"push" mechanism (a NOTIFY) for a common case that was otherwise very
	very inefficient (due to either slow convergence or wasteful and		inefficient (due to either slow convergence or wasteful and overly
	overly frequent scanning of the primary for changes).		frequent scanning of the primary for changes).
	While it is possible to indicate how frequently checks should occur		While it is possible to indicate how frequently checks should occur
	(via the SOA Refresh parameter), these checks did not allow catching		(via the SOA Refresh parameter), these checks did not allow catching
	zone changes that fall between checkpoints. [RFC1996] addressed the		zone changes that fall between checkpoints. [RFC1996] addressed the
	optimization of the time-and-cost trade-off between a secondary		optimization of the time-and-cost trade-off between a secondary
	checking frequently for new versions of a zone and infrequent		server frequently checking for new versions of a zone and infrequent
	checking, by replacing scheduled scanning with the more efficient		checks by replacing scheduled scanning with the more efficient NOTIFY
	NOTIFY mechanism.		mechanism.
	A.2. Similar Issues for DS Maintenance and Beyond		A.2. Similar Issues for DS Maintenance and Beyond
	Today, we have similar issues with slow updates of DNS data in spite		Today, we have similar issues with slow updates of DNS data in spite
	of the data having been published. The two most obvious cases are		of the data having been published. The two most obvious cases are
	CDS and CSYNC scanners deployed in a growing number of TLD		CDS and CSYNC scanners deployed in a growing number of TLD
	registries. Because of the large number of child delegations,		registries. Because of the large number of child delegations,
	scanning for CDS and CSYNC records is rather slow (as in,		scanning for CDS and CSYNC records is rather slow (as in,
	infrequent).		infrequent).
	skipping to change at line 777 ¶		skipping to change at line 783 ¶
	mechanism does not exist for DS-related scanning.		mechanism does not exist for DS-related scanning.
	All of the above also applies to automated NS and glue record		All of the above also applies to automated NS and glue record
	maintenance via CSYNC scanning [RFC7477]. Again, given that CSYNC		maintenance via CSYNC scanning [RFC7477]. Again, given that CSYNC
	records change only rarely, frequent scanning of a large number of		records change only rarely, frequent scanning of a large number of
	delegations seems disproportionately costly, while infrequent		delegations seems disproportionately costly, while infrequent
	scanning causes slower convergence (delay until the delegation is		scanning causes slower convergence (delay until the delegation is
	updated).		updated).
	While use of the NOTIFY mechanism for coordinating the key exchange		While use of the NOTIFY mechanism for coordinating the key exchange
	in multi-signer setups [DNSSEC-AUTO] is conceivable, the detailed		in multi-signer setups [RFC8901] is conceivable, the detailed
	specification is left for future work.		specification is left for future work.
	Acknowledgements		Acknowledgements
	In order of first contribution or review: Joe Abley, Mark Andrews,		The authors acknowledge the contributions and reviews of the
	Christian Elmerot, Ólafur Guðmundsson, Paul Wouters, Brian Dickson,		following individuals (in order of their first contribution or
	Warren Kumari, Patrick Mevzek, Tim Wicinski, Q Misell, Stefan Ubbink,		review): Joe Abley, Mark Andrews, Christian Elmerot, Ólafur
			Guðmundsson, Paul Wouters, Brian Dickson, Warren Kumari, Geoff
			Huston, Patrick Mevzek, Tim Wicinski, Q Misell, Stefan Ubbink,
	Matthijs Mekking, Kevin P. Fleming, Nicolai Leymann, Giuseppe		Matthijs Mekking, Kevin P. Fleming, Nicolai Leymann, Giuseppe
	Fioccola, Peter Yee, Tony Li, Paul Wouters, Roman Danyliw, Peter van		Fioccola, Peter Yee, Tony Li, Paul Wouters, Roman Danyliw, Peter van
	Dijk, John Scudder, and Éric Vyncke.		Dijk, John Scudder, Éric Vyncke, and Oli Schacher.
	Authors' Addresses		Authors' Addresses
	Johan Stenstam		Johan Stenstam
	The Swedish Internet Foundation		The Swedish Internet Foundation
	Email: johan.stenstam@internetstiftelsen.se		Email: johan.stenstam@internetstiftelsen.se
	Peter Thomassen		Peter Thomassen
	deSEC, Secure Systems Engineering		deSEC, Secure Systems Engineering
	Email: peter@desec.io		Email: peter@desec.io
End of changes. 17 change blocks.
	52 lines changed or deleted		60 lines changed or added
This html diff was produced by rfcdiff 1.48.