draft-ietf-dnssd-push-23.txt		draft-ietf-dnssd-push-24.txt
	Internet Engineering Task Force T. Pusateri		Internet Engineering Task Force T. Pusateri
	Internet-Draft Unaffiliated		Internet-Draft Unaffiliated
	Intended status: Standards Track S. Cheshire		Intended status: Standards Track S. Cheshire
	Expires: January 22, 2020 Apple Inc.		Expires: February 8, 2020 Apple Inc.
	July 21, 2019		August 7, 2019
	DNS Push Notifications		DNS Push Notifications
	draft-ietf-dnssd-push-23		draft-ietf-dnssd-push-24
	Abstract		Abstract
	The Domain Name System (DNS) was designed to return matching records		The Domain Name System (DNS) was designed to return matching records
	efficiently for queries for data that are relatively static. When		efficiently for queries for data that are relatively static. When
	those records change frequently, DNS is still efficient at returning		those records change frequently, DNS is still efficient at returning
	the updated results when polled, as long as the polling rate is not		the updated results when polled, as long as the polling rate is not
	too high. But there exists no mechanism for a client to be		too high. But there exists no mechanism for a client to be
	asynchronously notified when these changes occur. This document		asynchronously notified when these changes occur. This document
	defines a mechanism for a client to be notified of such changes to		defines a mechanism for a client to be notified of such changes to
	skipping to change at page 1, line 38 ¶		skipping to change at page 1, line 38 ¶
	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 January 22, 2020.		This Internet-Draft will expire on February 8, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 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		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 6, line 16 ¶		skipping to change at page 6, line 16 ¶
	(b) A DNS Push Notification client SHOULD NOT routinely keep a DNS		(b) A DNS Push Notification client SHOULD NOT routinely keep a DNS
	Push Notification subscription active 24 hours a day, 7 days a week,		Push Notification subscription active 24 hours a day, 7 days a week,
	just to keep a list in memory up to date so that if the user does		just to keep a list in memory up to date so that if the user does
	choose to bring up an on-screen display of that data, it can be		choose to bring up an on-screen display of that data, it can be
	displayed really fast. DNS Push Notifications are designed to be		displayed really fast. DNS Push Notifications are designed to be
	fast enough that there is no need to pre-load a "warm" list in memory		fast enough that there is no need to pre-load a "warm" list in memory
	just in case it might be needed later.		just in case it might be needed later.
	Generally, as described in the DNS Stateful Operations specification		Generally, as described in the DNS Stateful Operations specification
	[RFC8490], a client must not keep a session to a server open		[RFC8490], a client must not keep a DSO session to a server open
	indefinitely if it has no subscriptions (or other operations) active		indefinitely if it has no subscriptions (or other operations) active
	on that session. A client MAY close a session as soon as it becomes		on that session. A client MAY close a DSO session immediately it
	idle, and then if needed in the future, open a new session when		becomes idle, and then if needed in the future, open a new session
	required. Alternatively, a client MAY speculatively keep an idle		when required. Alternatively, a client MAY speculatively keep an
	session open for some time, subject to the constraint that it MUST		idle DSO session open for some time, subject to the constraint that
	NOT keep a session open that has been idle for more than the		it must not keep a session open that has been idle for more than the
	session's idle timeout (15 seconds by default) [RFC8490].		session's idle timeout (15 seconds by default) [RFC8490].
			Note that a DSO session which has an active DNS Push Notification
			subscription is not considered idle, even if there is no traffic
			flowing for an extended period of time. In this case the DSO
			inactivity timeout does not apply, because the session is not
			inactive, but the keepalive interval does still apply, to ensure
			generation of sufficient messages to maintain state in middleboxes
			(such at NAT gateways or firewalls) and for the client and server to
			periodically verify that they still have connectivity to each other.
			This is described in Section 6.2 of the DSO specification [RFC8490].
	4. State Considerations		4. State Considerations
	Each DNS Push Notification server is capable of handling some finite		Each DNS Push Notification server is capable of handling some finite
	number of Push Notification subscriptions. This number will vary		number of Push Notification subscriptions. This number will vary
	from server to server and is based on physical machine		from server to server and is based on physical machine
	characteristics, network bandwidth, and operating system resource		characteristics, network bandwidth, and operating system resource
	allocation. After a client establishes a session to a DNS server,		allocation. After a client establishes a session to a DNS server,
	each subscription is individually accepted or rejected. Servers may		each subscription is individually accepted or rejected. Servers may
	employ various techniques to limit subscriptions to a manageable		employ various techniques to limit subscriptions to a manageable
	level. Correspondingly, the client is free to establish simultaneous		level. Correspondingly, the client is free to establish simultaneous
	skipping to change at page 7, line 29 ¶		skipping to change at page 7, line 29 ¶
	concerns of state overload at the server which is a potential problem		concerns of state overload at the server which is a potential problem
	with connectionless protocols using spoofed source addresses. All		with connectionless protocols using spoofed source addresses. All
	subscribers are guaranteed to be reachable by the server by virtue of		subscribers are guaranteed to be reachable by the server by virtue of
	the TCP three-way handshake. Flooding attacks are possible with any		the TCP three-way handshake. Flooding attacks are possible with any
	protocol, and a benefit of TCP is that there are already established		protocol, and a benefit of TCP is that there are already established
	industry best practices to guard against SYN flooding and similar		industry best practices to guard against SYN flooding and similar
	attacks [SYN] [RFC4953].		attacks [SYN] [RFC4953].
	Use of TCP also allows DNS Push Notifications to take advantage of		Use of TCP also allows DNS Push Notifications to take advantage of
	current and future developments in TCP, such as Multipath TCP (MPTCP)		current and future developments in TCP, such as Multipath TCP (MPTCP)
	[RFC6824], TCP Fast Open (TFO) [RFC7413], Tail Loss Probe (TLP)		[RFC6824], TCP Fast Open (TFO) [RFC7413], RACK: a time-based fast
	[I-D.dukkipati-tcpm-tcp-loss-probe], and so on.		loss detection algorithm for TCP [I-D.ietf-tcpm-rack], and so on.
	Transport Layer Security (TLS) [RFC8446] is well understood, and used		Transport Layer Security (TLS) [RFC8446] is well understood, and used
	by many application-layer protocols running over TCP. TLS is		by many application-layer protocols running over TCP. TLS is
	designed to prevent eavesdropping, tampering, and message forgery.		designed to prevent eavesdropping, tampering, and message forgery.
	TLS is REQUIRED for every connection between a client subscriber and		TLS is REQUIRED for every connection between a client subscriber and
	server in this protocol specification. Additional security measures		server in this protocol specification. Additional security measures
	such as client authentication during TLS negotiation MAY also be		such as client authentication during TLS negotiation MAY also be
	employed to increase the trust relationship between client and		employed to increase the trust relationship between client and
	server.		server.
	skipping to change at page 15, line 30 ¶		skipping to change at page 15, line 30 ¶
	If neither TYPE nor CLASS are ANY (255) then this is a specific		If neither TYPE nor CLASS are ANY (255) then this is a specific
	subscription to changes for the given NAME, TYPE and CLASS. If one		subscription to changes for the given NAME, TYPE and CLASS. If one
	or both of TYPE or CLASS are ANY (255) then this subscription matches		or both of TYPE or CLASS are ANY (255) then this subscription matches
	any type and/or any class, as appropriate.		any type and/or any class, as appropriate.
	NOTE: A little-known quirk of DNS is that in DNS QUERY requests,		NOTE: A little-known quirk of DNS is that in DNS QUERY requests,
	QTYPE and QCLASS 255 mean "ANY" not "ALL". They indicate that the		QTYPE and QCLASS 255 mean "ANY" not "ALL". They indicate that the
	server should respond with ANY matching records of its choosing, not		server should respond with ANY matching records of its choosing, not
	necessarily ALL matching records. This can lead to some surprising		necessarily ALL matching records. This can lead to some surprising
	and unexpected results, where a query returns some valid answers but		and unexpected results, where a query returns some valid answers but
	not all of them, and makes QTYPE=ANY queries less useful than people		not all of them, and makes QTYPE = 255 (ANY) queries less useful than
	sometimes imagine.		people sometimes imagine.
	When used in conjunction with SUBSCRIBE, TYPE and CLASS 255 should be		When used in conjunction with SUBSCRIBE, TYPE and CLASS 255 should be
	interpreted to mean "ALL", not "ANY". After accepting a subscription		interpreted to mean "ALL", not "ANY". After accepting a subscription
	where one or both of TYPE or CLASS are 255, the server MUST send Push		where one or both of TYPE or CLASS are 255, the server MUST send Push
	Notification Updates for ALL record changes that match the		Notification Updates for ALL record changes that match the
	subscription, not just some of them.		subscription, not just some of them.
	6.2.2. SUBSCRIBE Response		6.2.2. SUBSCRIBE Response
	Each SUBSCRIBE request generates exactly one SUBSCRIBE response from		Each SUBSCRIBE request generates exactly one SUBSCRIBE response from
	skipping to change at page 21, line 36 ¶		skipping to change at page 21, line 36 ¶
	all types in the specified class.		all types in the specified class.
	For collective remove notifications, if CLASS is 255 (ANY), then for		For collective remove notifications, if CLASS is 255 (ANY), then for
	the given name this deletes all records of all types in all classes.		the given name this deletes all records of all types in all classes.
	In this case TYPE MUST be set to zero on transmission, and MUST be		In this case TYPE MUST be set to zero on transmission, and MUST be
	silently ignored on reception.		silently ignored on reception.
	Summary of change notification types:		Summary of change notification types:
	Delete all RRsets from a name, in all classes		Delete all RRsets from a name, in all classes
	TTL=0xFFFFFFFE, RDLENGTH=0, CLASS=255 (ANY)		TTL = 0xFFFFFFFE, RDLEN = 0, CLASS = 255 (ANY)
	Delete all RRsets from a name, in given class:		Delete all RRsets from a name, in given class:
	TTL=0xFFFFFFFE, RDLENGTH=0, CLASS specifies class, TYPE=255 (ANY)		TTL = 0xFFFFFFFE, RDLEN = 0, CLASS gives class, TYPE = 255 (ANY)
	Delete specified RRset from a name, in given class:		Delete specified RRset from a name, in given class:
	TTL=0xFFFFFFFE, RDLENGTH=0		TTL = 0xFFFFFFFE, RDLEN = 0
	CLASS and TYPE specify the RRset being deleted		CLASS and TYPE specify the RRset being deleted
	Delete an individual RR from a name:		Delete an individual RR from a name:
	TTL=0xFFFFFFFF		TTL = 0xFFFFFFFF
	CLASS, TYPE, RDLENGTH and RDATA specify the RR being deleted.		CLASS, TYPE, RDLEN and RDATA specify the RR being deleted.
	Add individual RR to a name		Add individual RR to a name
	TTL⩾0		TTL >= 0 and TTL <= 0x7FFFFFFF
	CLASS, TYPE, RDLENGTH, RDATA and TTL specify the RR being added.		CLASS, TYPE, RDLEN, RDATA and TTL specify the RR being added.
	Note that it is valid for the RDATA of an added or removed DNS		Note that it is valid for the RDATA of an added or removed DNS
	Resource Record to be empty (zero length). For example, an Address		Resource Record to be empty (zero length). For example, an Address
	Prefix List Resource Record [RFC3123] may have empty RDATA.		Prefix List Resource Record [RFC3123] may have empty RDATA.
	Therefore, a change notification with RDLEN=0 does not automatically		Therefore, a change notification with RDLEN = 0 does not
	indicate a remove notification. If RDLEN=0 and TTL is the in the		automatically indicate a remove notification. If RDLEN = 0 and TTL
	range 0 - 0x7FFFFFFF, this change notification signals the addition		is the in the range 0 - 0x7FFFFFFF, this change notification signals
	of a record with the given name, type, class, and empty RDATA. If		the addition of a record with the given name, type, class, and empty
	RDLEN=0 and TTL = 0xFFFFFFFF, this change notification signals the		RDATA. If RDLEN = 0 and TTL = 0xFFFFFFFF, this change notification
	removal specifically of that single record with the given name, type,		signals the removal specifically of that single record with the given
	class, and empty RDATA.		name, type, class, and empty RDATA.
	If the TTL is any value other than 0xFFFFFFFF, 0xFFFFFFFE, or a value		If the TTL is any value other than 0xFFFFFFFF, 0xFFFFFFFE, or a value
	in the range 0 - 0x7FFFFFFF, then the receiver SHOULD silently ignore		in the range 0 - 0x7FFFFFFF, then the receiver SHOULD silently ignore
	this particular change notification record. The connection is not		this particular change notification record. The connection is not
	terminated and other valid change notification records within this		terminated and other valid change notification records within this
	PUSH message are processed as usual.		PUSH message are processed as usual.
	For efficiency, when generating a PUSH message, a server SHOULD		For efficiency, when generating a PUSH message, a server SHOULD
	include as many change notifications as it has immediately available		include as many change notifications as it has immediately available
	to send, rather than sending each change notification as a separate		to send, rather than sending each change notification as a separate
	skipping to change at page 24, line 19 ¶		skipping to change at page 24, line 19 ¶
	record addition/deletion is silently ignored. Processing of other		record addition/deletion is silently ignored. Processing of other
	additions and deletions in this message is not affected. The DSO		additions and deletions in this message is not affected. The DSO
	session is not closed. This is to allow for the unavoidable race		session is not closed. This is to allow for the unavoidable race
	condition where a client sends an outbound UNSUBSCRIBE while inbound		condition where a client sends an outbound UNSUBSCRIBE while inbound
	PUSH messages for that subscription from the server are still in		PUSH messages for that subscription from the server are still in
	flight.		flight.
	In the case where a single change affects more than one active		In the case where a single change affects more than one active
	subscription, only one PUSH message is sent. For example, a PUSH		subscription, only one PUSH message is sent. For example, a PUSH
	message adding a given record may match both a SUBSCRIBE request with		message adding a given record may match both a SUBSCRIBE request with
	the same TYPE and a different SUBSCRIBE request with TYPE=ANY (255).		the same TYPE and a different SUBSCRIBE request with TYPE = 255
	It is not the case that two PUSH messages are sent because the new		(ANY). It is not the case that two PUSH messages are sent because
	record matches two active subscriptions.		the new record matches two active subscriptions.
	The server SHOULD encode change notifications in the most efficient		The server SHOULD encode change notifications in the most efficient
	manner possible. For example, when three AAAA records are deleted		manner possible. For example, when three AAAA records are deleted
	from a given name, and no other AAAA records exist for that name, the		from a given name, and no other AAAA records exist for that name, the
	server SHOULD send a "delete an RRset from a name" PUSH message, not		server SHOULD send a "delete an RRset from a name" PUSH message, not
	three separate "delete an individual RR from a name" PUSH messages.		three separate "delete an individual RR from a name" PUSH messages.
	Similarly, when both an SRV and a TXT record are deleted from a given		Similarly, when both an SRV and a TXT record are deleted from a given
	name, and no other records of any kind exist for that name, the		name, and no other records of any kind exist for that name, the
	server SHOULD send a "delete all RRsets from a name" PUSH message,		server SHOULD send a "delete all RRsets from a name" PUSH message,
	not two separate "delete an RRset from a name" PUSH messages.		not two separate "delete an RRset from a name" PUSH messages.
	skipping to change at page 31, line 33 ¶		skipping to change at page 31, line 33 ¶
	If a client plans to terminate one or more subscriptions on a session		If a client plans to terminate one or more subscriptions on a session
	and doesn't intend to keep that session open, then as an efficiency		and doesn't intend to keep that session open, then as an efficiency
	optimization it MAY instead choose to simply close the session, which		optimization it MAY instead choose to simply close the session, which
	implicitly terminates all subscriptions on that session. This may		implicitly terminates all subscriptions on that session. This may
	occur because the client computer is being shut down, is going to		occur because the client computer is being shut down, is going to
	sleep, the application requiring the subscriptions has terminated, or		sleep, the application requiring the subscriptions has terminated, or
	simply because the last active subscription on that session has been		simply because the last active subscription on that session has been
	cancelled.		cancelled.
	When closing a session, a client should perform an orderly close of		When closing a session, a client should perform an orderly close of
	the TLS session in order to allow for future TLS session resumption		the TLS session. Typical APIs will provide a session close method
	with the server (if available). See Section 7.4 below. Typical APIs		that will send a TLS close_notify alert (see Section 6.1 of the TLS
	will provide a session close method that will send a TLS close_notify		1.3 specification [RFC8446]). This instructs the recipient that the
	alert (see Section 6.1 of the TLS 1.3 specification [RFC8446]). This		sender will not send any more data over the session. After sending
	instructs the recipient that the sender will not send any more data		the TLS close_notify alert the client MUST gracefully close the
	over the session. After sending the TLS close_notify alert the		underlying connection using a TCP FIN, so that the TLS close_notify
	client MUST gracefully close the underlying connection using a TCP		is reliably delivered. The mechanisms for gracefully closing a TCP
	FIN, so that the TLS close_notify is reliably delivered. The		connection with a TCP FIN vary depending on the networking API. For
	mechanisms for gracefully closing a TCP connection with a TCP FIN		example, in the BSD Sockets API, sending a TCP FIN is achieved by
	vary depending on the networking API. For example, in the BSD		calling "shutdown(s,SHUT_WR)" and keeping the socket open until all
	Sockets API, sending a TCP FIN is achieved by calling		remaining data has been read from it.
	"shutdown(s,SHUT_WR)" and keeping the socket open until all remaining
	data has been read from it.
	If the session is forcibly closed at the TCP level by sending a RST		If the session is forcibly closed at the TCP level by sending a RST
	from either end of the connection, data may be lost and TLS session		from either end of the connection, data may be lost.
	resumption of this session will not be possible.
	6.8. Client Fallback to Polling		6.8. Client Fallback to Polling
	There are cases where a client may exhaust all avenues for		There are cases where a client may exhaust all avenues for
	establishing a DNS Push Notification subscription without success.		establishing a DNS Push Notification subscription without success.
	This can happen if the client's configured recursive resolver does		This can happen if the client's configured recursive resolver does
	not support DNS over TLS, or supports DNS over TLS but is not		not support DNS over TLS, or supports DNS over TLS but is not
	listening on TCP port 853, or supports DNS over TLS on TCP port 853		listening on TCP port 853, or supports DNS over TLS on TCP port 853
	but does not support DSO on that port, or for some other reason is		but does not support DSO on that port, or for some other reason is
	unable to provide a DNS Push Notification subscription. In this case		unable to provide a DNS Push Notification subscription. In this case
	skipping to change at page 36, line 23 ¶		skipping to change at page 36, line 23 ¶
	+-----------------------+------+----------------------+-------------+		+-----------------------+------+----------------------+-------------+
	| DNS Push Notification | None | "_dns-push-tls._tcp" | Section 6.1 |		| DNS Push Notification | None | "_dns-push-tls._tcp" | Section 6.1 |
	| Service Type | | | |		| Service Type | | | |
	+-----------------------+------+----------------------+-------------+		+-----------------------+------+----------------------+-------------+
	Table 4: IANA Service Type Assignments		Table 4: IANA Service Type Assignments
	This document also defines four new DNS Stateful Operation TLV types		This document also defines four new DNS Stateful Operation TLV types
	to be recorded in the IANA DSO Type Code Registry.		to be recorded in the IANA DSO Type Code Registry.
	+-------------+------------+--------+-----------------+-------------+		+-------------+------------+---------+-----------------+------------+
	| Name | Value | Early | Status | Definition |		| Name | Value | Early | Status | Definition |
	| | | Data | | |		| | | Data | | |
	+-------------+------------+--------+-----------------+-------------+		+-------------+------------+---------+-----------------+------------+
	| SUBSCRIBE | TBA (0x40) | OK | Standards Track | Section 6.2 |		| SUBSCRIBE | TBA (0x40) | OK | Standards Track | Section |
	| PUSH | TBA (0x41) | NO | Standards Track | Section 6.3 |		| | | | | 6.2 |
	| UNSUBSCRIBE | TBA (0x42) | NO | Standards Track | Section 6.4 |		| PUSH | TBA (0x41) | NO | Standards Track | Section |
	| RECONFIRM | TBA (0x43) | NO | Standards Track | Section 6.5 |		| | | | | 6.3 |
	+-------------+------------+--------+-----------------+-------------+		| UNSUBSCRIBE | TBA (0x42) | NO | Standards Track | Section |
			| | | | | 6.4 |
			| RECONFIRM | TBA (0x43) | NO | Standards Track | Section |
			| | | | | 6.5 |
			+-------------+------------+---------+-----------------+------------+
	Table 5: IANA DSO TLV Type Code Assignments		Table 5: IANA DSO TLV Type Code Assignments
	This document defines no new DNS OPCODEs or RCODEs.		This document defines no new DNS OPCODEs or RCODEs.
	9. Acknowledgements		9. Acknowledgements
	The authors would like to thank Kiren Sekar and Marc Krochmal for		The authors would like to thank Kiren Sekar and Marc Krochmal for
	previous work completed in this field.		previous work completed in this field.
	skipping to change at page 39, line 5 ¶		skipping to change at page 38, line 49 ¶
	[ST] "Service Name and Transport Protocol Port Number		[ST] "Service Name and Transport Protocol Port Number
	Registry", <http://www.iana.org/assignments/		Registry", <http://www.iana.org/assignments/
	service-names-port-numbers/>.		service-names-port-numbers/>.
	10.2. Informative References		10.2. Informative References
	[DisProx] Cheshire, S., "Discovery Proxy for Multicast DNS-Based		[DisProx] Cheshire, S., "Discovery Proxy for Multicast DNS-Based
	Service Discovery", draft-ietf-dnssd-hybrid-10 (work in		Service Discovery", draft-ietf-dnssd-hybrid-10 (work in
	progress), March 2019.		progress), March 2019.
	[I-D.dukkipati-tcpm-tcp-loss-probe]		[I-D.ietf-tcpm-rack]
	Dukkipati, N., Cardwell, N., Cheng, Y., and M. Mathis,		Cheng, Y., Cardwell, N., Dukkipati, N., and P. Jha, "RACK:
	"Tail Loss Probe (TLP): An Algorithm for Fast Recovery of		a time-based fast loss detection algorithm for TCP",
	Tail Losses", draft-dukkipati-tcpm-tcp-loss-probe-01 (work		draft-ietf-tcpm-rack-05 (work in progress), April 2019.
	in progress), February 2013.
	[LLQ] Cheshire, S. and M. Krochmal, "DNS Long-Lived Queries",		[LLQ] Cheshire, S. and M. Krochmal, "DNS Long-Lived Queries",
	draft-sekar-dns-llq-03 (work in progress), March 2019.		draft-sekar-dns-llq-03 (work in progress), March 2019.
	[obs] "Observer Pattern",		[obs] "Observer Pattern",
	<https://en.wikipedia.org/wiki/Observer_pattern>.		<https://en.wikipedia.org/wiki/Observer_pattern>.
	[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS		[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
	NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998,		NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998,
	<https://www.rfc-editor.org/info/rfc2308>.		<https://www.rfc-editor.org/info/rfc2308>.
End of changes. 19 change blocks.
	60 lines changed or deleted		70 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/