draft-bellis-dnsop-session-signal-00.txt		draft-bellis-dnsop-session-signal-01.txt
	DNSOP Working Group R. Bellis		DNSOP Working Group R. Bellis
	Internet-Draft ISC		Internet-Draft ISC
	Intended status: Standards Track S. Cheshire		Intended status: Standards Track S. Cheshire
	Expires: January 7, 2017 Apple Inc.		Expires: January 22, 2017 Apple Inc.
	J. Dickinson		J. Dickinson
			S. Dickinson
	Sinodun		Sinodun
	A. Mankin		A. Mankin
			Salesforce
	T. Pusateri		T. Pusateri
	Unaffiliated		Unaffiliated
	July 6, 2016		July 21, 2016
	DNS Session Signaling		DNS Session Signaling
	draft-bellis-dnsop-session-signal-00		draft-bellis-dnsop-session-signal-01
	Abstract		Abstract
	The Extension Mechanisms for DNS (EDNS(0)) [RFC6891] is explicitly		The Extension Mechanisms for DNS (EDNS(0)) [RFC6891] is explicitly
	defined to only have "per-message" semantics. This document defines		defined to only have "per-message" semantics. This document defines
	a new Session Signaling OpCode used to carry persistent "per-session"		a new Session Signaling OpCode used to carry persistent "per-session"
	type-length-values (TLVs), and defines an initial set of TLVs used to		type-length-values (TLVs), and defines an initial set of TLVs used to
	handle feature negotiation and to manage session timeouts and		manage session timeouts and termination.
	termination.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 http://datatracker.ietf.org/drafts/current/.		Drafts is at http://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 7, 2017.		This Internet-Draft will expire on January 22, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 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
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://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 2, line 17 ¶		skipping to change at page 2, line 20 ¶
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 3		3. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 3
	3.1. Message Format . . . . . . . . . . . . . . . . . . . . . 3		3.1. Message Format . . . . . . . . . . . . . . . . . . . . . 4
	3.2. Message Handling . . . . . . . . . . . . . . . . . . . . 4		3.2. Message Handling . . . . . . . . . . . . . . . . . . . . 4
	3.3. TLV Format . . . . . . . . . . . . . . . . . . . . . . . 4		3.3. TLV Format . . . . . . . . . . . . . . . . . . . . . . . 5
	4. Mandatory TLVs . . . . . . . . . . . . . . . . . . . . . . . 5		4. Mandatory TLVs . . . . . . . . . . . . . . . . . . . . . . . 6
	4.1. Feature Negotiation . . . . . . . . . . . . . . . . . . . 5		4.1. Session Management Support TLVs . . . . . . . . . . . . . 6
	4.1.1. TypeCode Support . . . . . . . . . . . . . . . . . . 5		4.1.1. "Not Implemented" . . . . . . . . . . . . . . . . . . 6
	4.2. Layer 4 Connection Management TLVs . . . . . . . . . . . 6		4.2. Session Management TLVs . . . . . . . . . . . . . . . . . 6
	4.2.1. Terminate . . . . . . . . . . . . . . . . . . . . . . 6		4.2.1. Start Session . . . . . . . . . . . . . . . . . . . . 6
	4.2.2. Idle Timeout . . . . . . . . . . . . . . . . . . . . 6		4.2.2. Terminate Session . . . . . . . . . . . . . . . . . . 6
			4.2.3. Idle Timeout . . . . . . . . . . . . . . . . . . . . 7
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	5.1. DNS Session Signaling OpCode Registration . . . . . . . . 7		5.1. DNS Session Signaling Opcode Registration . . . . . . . . 8
	5.2. DNS Session Signaling Status Codes Registry . . . . . . . 7		5.2. DNS Session Signaling Type Codes Registry . . . . . . . . 8
	5.3. DNS Session Signaling Type Codes Registry . . . . . . . . 7
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 8		6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
	8. Normative References . . . . . . . . . . . . . . . . . . . . 8		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
			8.1. Normative References . . . . . . . . . . . . . . . . . . 9
			8.2. Informative References . . . . . . . . . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
	1. Introduction		1. Introduction
	The Extension Mechanisms for DNS (EDNS(0)) [RFC6891] is explicitly		The Extension Mechanisms for DNS (EDNS(0)) [RFC6891] is explicitly
	defined to only have "per-message" semantics. This document defines		defined to only have "per-message" semantics. This document defines
	a new Session Signaling OpCode used to carry persistent "per-session"		a new Session Signaling OpCode used to carry persistent "per-session"
	type-length-values (TLVs), and defines an initial set of TLVs used to		type-length-values (TLVs), and defines an initial set of TLVs used to
	handle feature negotiation and to manage session timeouts and		manage session timeouts and termination.
	termination.
	A further issue with EDNS(0) is that there is no standard mechanism		A further issue with EDNS(0) is that there is no standard mechanism
	for a client to be able to tell whether a server has processed or		for a client to be able to tell whether a server has processed or
	otherwise acted upon the individual options contained with an OPT RR.		otherwise acted upon the individual options contained with an OPT RR.
	The Session Signaling Opcode therefore requires an explicit response		The Session Signaling OpCode therefore requires an explicit response
	to each TLV within a request.		to each request message.
	The message format (see Section 3.1) does not completely conform to		It should be noted that the message format (see Section 3.1) does not
	the standard DNS packet format but is designed such that existing DNS		conform to the standard DNS packet format.
	protocol parsers should be able to read the packet header and then
	simply ignore the extra data that appears thereafter.
	2. Terminology		2. Terminology
	The terms "initiator" and "responder" correspond respectively to the		The terms "initiator" and "responder" correspond respectively to the
	initial sender and subsequent receiver of a Session Signaling TLV,		initial sender and subsequent receiver of a Session Signaling TLV,
	regardless of which was the "client" and "server" in the usual DNS		regardless of which was the "client" and "server" in the usual DNS
	sense. The term "sender" may apply to either an initiator or		sense. The term "sender" may apply to either an initiator or
	responder.		responder.
			The term "session" in the context of this document means the exchange
			of DNS messages over a single connection using an end-to-end
			transport protocol where:
			o connections can be long-lived
			o either end of the connection may initiate requests
			o message delivery order is guaranteed
			o it is guaranteed that the same two endpoints are in communication
			for the entire lifetime of the session.
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	3. Protocol Details		3. Protocol Details
	Session Signaling messages MUST only be carried in protocols and in		Session Signaling messages MUST only be carried in protocols and in
	environments that can guarantee that the same two endpoints are in		environments where a session may be established according to the
	communication for the entire lifetime of the session.		definition above. Standard DNS over TCP [RFC1035], and DNS over TLS
			[RFC7858] are appropriate protocols. DNS over plain UDP is not
			appropriate since it fails on both the bi-directional initiation
			requirement and the message order delivery requirement.
	Session Signaling messages relate only to the specific session in		Session Signaling messages relate only to the specific session in
	which they are being carried. Where a middle box (e.g. a DNS proxy,		which they are being carried. Where a middle box (e.g. a DNS proxy,
	forwarder, or session multiplexer) is in the path the message MUST		forwarder, or session multiplexer) is in the path the message MUST
	NOT be blindly forwarded in either direction by that middle box.		NOT be blindly forwarded in either direction by that middle box.
	This does not preclude the use of these messages in the presence of a		This does not preclude the use of these messages in the presence of a
	NAT box that rewrites Layer 3 or Layer 4 headers but otherwise		NAT box that rewrites Layer 3 or Layer 4 headers but otherwise
	maintains the effect of a single session.		maintains the effect of a single session.
	<< RB: OSI Layer 5 session analog? This is obviously intended for		A server MUST NOT initiate Session Signaling messages until a client-
	TCP "sessions" which aren't distinct from Layer 4, but is this also		initiated Session Signaling message is received first. This
	applicable to DNS-o-DTLS, or DNS over UDP with an EDNS cookie - I		requirement is to ensure that the client does not observe unsolicited
	think probably "yes" for the former, but "no" for the latter. I'm		inbound messages until it has indicated its ability to handle them.
	wondering whether "session" is even the right term to be using
	here >>		Session Signaling support is therefore said to be confirmed from the
			client's point of view after the first session signaling TLV has been
			sent by that client and subsequently successfully acknowledged by the
			server.
			Use of Session Signaling by a client should be taken as an implicit
			request for a long-lived session.
	3.1. Message Format		3.1. Message Format
	A message containing a Session Signaling Opcode does not conform to		A message containing a Session Signaling OpCode does not conform to
	the usual DNS message format. The 12 octet header format from		the usual DNS message format. The 4 octet header format from
	[RFC1035] is preserved, but the four section count fields (QDCOUNT,		[RFC1035] is however preserved, since that includes the message ID
	ANCOUNT, NSCOUNT and ARCOUNT) MUST all be set to zero.		and OpCode and RCODE fields, and the QR bit that differentiates
			requests from responses.
	A list of TLVs are used in place of the usual sections, and MUST		Each message MUST contain only a single TLV.
	appear immediately after the 12 octet header. The total size of the
	TLVs is calculated from the value of the standard two octet framing		1 1 1 1 1 1
	word minus the 12 octets of the DNS header.		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
			+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
			| MESSAGE ID |
			+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
			|QR | OpCode | Z | RCODE |
			+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
			| |
			/ TLV-DATA /
			/ /
			+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
			The MESSAGE ID, QR, OpCode and RCODE fields have their usual meaning
			as defined in [RFC1035].
			The Z bits are currently unused, and SHOULD be set to zero (0) in
			requests and responses unless re-defined in a later specification.
	3.2. Message Handling		3.2. Message Handling
	Both clients and servers may unilaterally send Session Signaling		Both clients and servers may unilaterally send Session Signaling
	messages at any point in the lifetime of a session and are therefore		messages at any point in the lifetime of a session and are therefore
	considered to be the initiator with respect to that message. The		considered to be the initiator with respect to that message. The
	initiator MUST set the value of the QR bit in the DNS header to zero		initiator MUST set the value of the QR bit in the DNS header to zero
	(0), and the responder MUST set it to one (1).		(0), and the responder MUST set it to one (1).
	Every Session Signaling request message MUST elicit a response (which		Every Session Signaling request message MUST elicit a response (which
	MUST have the same ID in the DNS message header as in the request)		MUST have the same ID in the DNS message header as in the request).
	and every TLV contained within the request requires a corresponding
	TLV in the response.
	In order to preserve the correct sequence of state, Session Signaling		In order to preserve the correct sequence of state, Session Signaling
	requests MUST NOT be processed out of order. Similarly the TLVs in a		requests MUST NOT be processed out of order.
	message MUST be processed in the order in which they are contained in
	the message, and the order of the TLVs in the response MUST
	correspond with the order of the TLVs in the request.
	<< RB: should the presence of a SS message create a "sequencing		<< RB: should the presence of a SS message create a "sequencing
	point", such that all pending responses must be answered? >>		point", such that all pending responses must be answered? >>
			The RCODE value in a response uses a subset of the standard (non-
			extended) RCODE values from the IANA DNS RCODEs registry, interpreted
			as follows:
			+------+----------+---------------------------------+
			| Code | Mnemonic | Description |
			+------+----------+---------------------------------+
			| 0 | NOERROR | TLV processed successfully |
			| | | |
			| 1 | FORMERR | TLV format error |
			| | | |
			| 4 | NOTIMP | Session Signaling not supported |
			| | | |
			| 5 | REFUSED | TLV declined for policy reasons |
			+------+----------+---------------------------------+
	3.3. TLV Format		3.3. TLV Format
	1 1 1 1 1 1		1 1 1 1 1 1
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
	+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+		+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
	|SESSION-STATUS | SESSION-TYPE |		| SESSION-TYPE |
	+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+		+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
	| SESSION-LENGTH |		| SESSION-LENGTH |
	+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+		+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
	| |		| |
	/ SESSION-DATA /		/ SESSION-DATA /
	/ /		/ /
	+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+		+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
	SESSION-STATUS: A 4 bit field used in a response to indicate the		SESSION-TYPE: A 16 bit field in network order giving the type of the
	success (or otherwise) of an operation, as defined in the DNS
	Session Signaling Status Codes Registry. It SHOULD contain
	"NOERROR" (0) in a request message but the responder MUST NOT
	reject the request if it does not.
	SESSION-TYPE: A 12 bit field in network order giving the type of the
	current Session Signaling TLV per the IANA DNS Session Signaling		current Session Signaling TLV per the IANA DNS Session Signaling
	Type Codes Registry.		Type Codes Registry.
	SESSION-LENGTH: A 16 bit field in network order giving the size in		SESSION-LENGTH: A 16 bit field in network order giving the size in
	octets of SESSION-DATA.		octets of SESSION-DATA.
	SESSION-DATA: Type-code specific. The SESSION-DATA field MUST be		SESSION-DATA: Type-code specific.
	NUL padded to an even number of octets such that each Session
	Signaling TLV is aligned on a two octet boundary relative to the
	start of the first Session Signaling TLV. Padding octets MUST NOT
	be included in the calculation of SESSION-LENGTH but MUST be
	included in the calculation of the overall message length.
	<< RB: the padding is specified such that client code can read the
	type and length fields directly from an aligned uint16_t array (with
	byte swapping) >>
	4. Mandatory TLVs		4. Mandatory TLVs
	4.1. Feature Negotiation		4.1. Session Management Support TLVs
	4.1.1. TypeCode Support		4.1.1. "Not Implemented"
	The TypeCode Support TLV (1) is used to allow a client and server to		Since the "NOTIMP" RCODE is required to indicate lack of support for
	exchange information about which Session Signaling Type Codes they		the Session Signaling OpCode itself, the "Not Implemented" TLV (0)
	support.		MUST be returned in response to a TLV that is not implemented by the
			responder.
	The SESSION-DATA contains a list of the Session Signaling Type Codes		This TLV has no SESSION-DATA.
	supported by the sender.
	1 1 1 1 1 1		4.2. Session Management TLVs
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
	+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
	| TYPE CODEs |
	/ ... /
	/ /
	+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
	TYPE CODEs: A list of 16 bit words in network order comprising the		4.2.1. Start Session
	complete list of Session Signaling Type Codes supported by the
	sender. Since a Session Signaling Type Code is in reality only a
	12 bit value, the four most significant bits of each word MUST be
	zero. The number of TYPE CODEs can be calculated from the total
	length of the TLV.
	An initiator MAY send its own list of supported Session Signaling		The Start Session TLV (1) SHOULD be used by a client to indicate
	Type Codes in a TypeCode Support TLV, and if sent they MUST be		support for Session Signaling. It MUST NOT be initiated by a server.
	complete. Otherwise the SESSION-DATA MUST be empty. In either case
	the responder MUST respond with its complete list of supported Type
	Codes.
	4.2. Layer 4 Connection Management TLVs		It is not required that this TLV be used in every session - any valid
			client-initiated TLV will suffice to initiate Session Signaling
			support. The intention of this TLV is to provide a suitable "No-Op"
			TLV to permit Session Signaling support to be negotiated without
			carrying any other information.
	4.2.1. Terminate		This TLV has no SESSION-DATA.
	The Terminate TLV (64) MAY be sent by a server to request that the		<< RB: this could perhaps also be used as a real "no-op" message to
	client terminate the session, and when sent MUST be the only TLV		provide application-level keep-alive pings >>
	present. It MUST NOT be requested by a client.
			4.2.2. Terminate Session
			The Terminate Session TLV (2) MAY be sent by a server to request that
			the client terminate the session. It MUST NOT be initiated by a
			client.
	The client SHOULD terminate the session as soon as possible, but MAY		The client SHOULD terminate the session as soon as possible, but MAY
	wait for any inflight queries to be answered. It MUST NOT initiate		wait for any inflight queries to be answered. It MUST NOT initiate
	any new queries over the existing session, nor send any further TLVs		any new requests over the existing session.
	other than its response to the Terminate request.
	<< RB: dns-sd push has a "reconnect delay" option but I think it's of		The SESSION-DATA is as follows:
	questionable value since in an anycast or load-balancing architecture
	there's no way for the client to know which instance sent the option
	nor control which server instance the next connection will go to.
	This would IMHO be better controlled directly at the TCP layer. >>
	4.2.2. Idle Timeout		1 1 1 1 1 1
			0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
			+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
			| RECONNECT DELAY |
			+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
	The Idle Timeout TLV (65) has similar semantics to the EDNS TCP		RECONNECT DELAY: a time value, specified as a 16 bit word in network
	Keepalive Option [RFC7828]. It is used by a server to tell the		order in units of 100 milliseconds, within which the client MUST
	client how long it may leave the current session idle for.		NOT establish a new session to the current server.
	The SESSION-DATA is as follows:		The RECOMMENDED value is 10 seconds. << RB: text required here about
			default values for load balancers, etc >>
			4.2.3. Idle Timeout
			The Idle Timeout TLV (3) has similar intent to the EDNS TCP Keepalive
			Option [RFC7828]. It is used by a server to tell the client how long
			it may leave the current session idle for. a client. The definition
			of an idle session is as specified in [RFC7766].
			Messages generate by the client have no SESSION-DATA (whether in
			requests or responses). A client-initiated Idle Timeout TLV allows
			the client to request the current timeout value, whereas a server-
			initiated request allows the server to unilaterally update the
			current timeout value.
			Messages generated by the server contain SESSION-DATA as follows:
	1 1 1 1 1 1		1 1 1 1 1 1
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
	+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+		+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
	| IDLE TIMEOUT |		| IDLE TIMEOUT |
	+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+		+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
	IDLE TIMEOUT: the idle timeout for the current session, specified as		IDLE TIMEOUT: the idle timeout for the current session, specified as
	a 16 bit word in network order in units of 100 milliseconds.		a 16 bit word in network order in units of 100 milliseconds.
	It is NOT an error for this TLV and the similar EDNS option to appear
	within the same session. The client SHOULD pay attention to the most
	recently received value, regardless of which method was used to send
	it.
	The client SHOULD terminate the current session if it remains idle		The client SHOULD terminate the current session if it remains idle
	for longer than the specified timeout (and MAY of course terminate		for longer than the specified timeout (and MAY of course terminate
	the session earlier). The server MAY unilaterally terminate the		the session earlier). The server MAY unilaterally terminate the
	connection at any time, but SHOULD allow the client to keep the		connection at any time, but SHOULD allow the client to keep the
	connection open if further messages are received before the idle		connection open if further messages are received before the idle
	timeout expires.		timeout expires.
	<< RB: this assumes that the EDNS OPT RR is added at the final stage		A client / server pair that supports Session Signaling MUST NOT use
	of message processing, and therefore not affected by out-of-order		the EDNS TCP KeepAlive option within any message once bi-directional
	processing - c.f. comment above about sequencing points >>		Session Signaling support has been confirmed.
	5. IANA Considerations		5. IANA Considerations
			5.1. DNS Session Signaling Opcode Registration
	5.1. DNS Session Signaling OpCode Registration
	IANA are directed to assign the value TBD for the Session Signaling		IANA are directed to assign the value TBD for the Session Signaling
	OpCode in the DNS OpCodes Registry.		OpCode in the DNS OpCodes Registry.
	5.2. DNS Session Signaling Status Codes Registry		5.2. DNS Session Signaling Type Codes Registry
	IANA are directed to create the DNS Session Signaling Status Codes
	Registry, with initial values as follows:
	+------+----------+---------------------------------+-----------+
	| Code | Mnemonic | Description | Reference |
	+------+----------+---------------------------------+-----------+
	| 0 | NOERROR | TLV processed successfully | RFC-TBD1 |
	| | | | |
	| 4 | NOTIMP | TLV not implemented | RFC-TBD1 |
	| | | | |
	| 5 | REFUSED | TLV declined for policy reasons | RFC-TBD1 |
	+------+----------+---------------------------------+-----------+
	Registration of additional Session Signaling Status Codes requires
	Standards Action.
	5.3. DNS Session Signaling Type Codes Registry
	IANA are directed to create the DNS Session Signaling Type Codes		IANA are directed to create the DNS Session Signaling Type Codes
	Registry, with initial values as follows:		Registry, with initial values as follows:
	+----------+---------------------------------+----------+-----------+		+-----------+--------------------------------+----------+-----------+
	| Type | Name | Status | Reference |		| Type | Name | Status | Reference |
	+----------+---------------------------------+----------+-----------+		+-----------+--------------------------------+----------+-----------+
	| 0 | Reserved | | RFC-TBD1 |		| 0 | Not implemented | | RFC-TBD1 |
	| | | | |		| | | | |
	| 1 | TypeCode Support | Standard | RFC-TBD1 |		| 1 | Start Session | Standard | RFC-TBD1 |
	| | | | |		| | | | |
	| 2 - 63 | Unassigned, reserved for | | |		| 2 | Terminate Session | Standard | RFC-TBD1 |
	| | feature negotiation TLVs | | |		| | | | |
	| | | | |		| 3 | Idle Timeout | Standard | RFC-TBD1 |
	| 64 | Terminate | Standard | RFC-TBD1 |		| | | | |
	| | | | |		| 4 - 63 | Unassigned, reserved for | | |
	| 65 | Idle Timeout | Standard | RFC-TBD1 |		| | session management TLVs | | |
	| | | | |		| | | | |
	| 66 - 127 | Unassigned, reserved for | | |		| 64 - | Unassigned | | |
	| | session management TLVs | | |		| 63487 | | | |
	| | | | |		| | | | |
	| 127 - | Unassigned | | |		| 63488 - | Reserved for local / | | |
	| 3965 | | | |		| 64511 | experimental use | | |
	| | | | |		| | | | |
	| 3968 - | Reserved for local / | | |		| 64512 - | Reserved for future expansion | | |
	| 4031 | experimental use | | |		| 65535 | | | |
	| | | | |		+-----------+--------------------------------+----------+-----------+
	| 4032 - | Reserved for future expansion | | |
	| 4095 | | | |
	+----------+---------------------------------+----------+-----------+
	Registration of additional Session Signaling Type Codes requires		Registration of additional Session Signaling Type Codes requires
	Expert Review. << RB: definition of process required? >>		Expert Review. << RB: definition of process required? >>
	6. Security Considerations		6. Security Considerations
	The authors are not aware of any specific security considerations		If this mechanism is to be used with DNS over TLS, then these
	introduced by this specification at this time.		messages are subject to the same constraints as any other DNS over
			TLS messages and MUST NOT be sent in the clear before the TLS session
			is established.
	7. Acknowledgements		7. Acknowledgements
	TBW		TBW
	8. Normative References		8. References
			8.1. Normative References
	[RFC1035] Mockapetris, P., "Domain names - implementation and		[RFC1035] Mockapetris, P., "Domain names - implementation and
	specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,		specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
	November 1987, <http://www.rfc-editor.org/info/rfc1035>.		November 1987, <http://www.rfc-editor.org/info/rfc1035>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/		Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
	RFC2119, March 1997,		RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms		[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
	for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/		for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/
	RFC6891, April 2013,		RFC6891, April 2013,
	<http://www.rfc-editor.org/info/rfc6891>.		<http://www.rfc-editor.org/info/rfc6891>.
			[RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and
			D. Wessels, "DNS Transport over TCP - Implementation
			Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016,
			<http://www.rfc-editor.org/info/rfc7766>.
	[RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The		[RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The
	edns-tcp-keepalive EDNS0 Option", RFC 7828, DOI 10.17487/		edns-tcp-keepalive EDNS0 Option", RFC 7828, DOI 10.17487/
	RFC7828, April 2016,		RFC7828, April 2016,
	<http://www.rfc-editor.org/info/rfc7828>.		<http://www.rfc-editor.org/info/rfc7828>.
	Authors' Addresses		8.2. Informative References
			[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
			and P. Hoffman, "Specification for DNS over Transport
			Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
			2016, <http://www.rfc-editor.org/info/rfc7858>.
			Authors' Addresses
	Ray Bellis		Ray Bellis
	Internet Systems Consortium, Inc.		Internet Systems Consortium, Inc.
	950 Charter Street		950 Charter Street
	Redwood City CA 94063		Redwood City CA 94063
	USA		USA
	Phone: +1 650 423 1200		Phone: +1 650 423 1200
	Email: ray@isc.org		Email: ray@isc.org
	Stuart Cheshire		Stuart Cheshire
	skipping to change at page 10, line 4 ¶		skipping to change at page 10, line 28 ¶
	Phone: +1 408 974 3207		Phone: +1 408 974 3207
	Email: cheshire@apple.com		Email: cheshire@apple.com
	John Dickinson		John Dickinson
	Sinodun Internet Technologies		Sinodun Internet Technologies
	Magadalen Centre		Magadalen Centre
	Oxford Science Park		Oxford Science Park
	Oxford OX4 4GA		Oxford OX4 4GA
	United Kingdom		United Kingdom
			Email: jad@sinodun.com
			Sara Dickinson
			Sinodun Internet Technologies
			Magadalen Centre
			Oxford Science Park
			Oxford OX4 4GA
			United Kingdom
			Email: sara@sinodun.com
	Allison Mankin		Allison Mankin
	Unaffiliated		Salesforce
	Email: allison.mankin@gmail.com		Email: allison.mankin@gmail.com
	Tom Pusateri		Tom Pusateri
	Unaffiliated		Unaffiliated
	Phone: +1 843 473 7394		Phone: +1 843 473 7394
	Email: pusateri@bangj.com		Email: pusateri@bangj.com
End of changes. 53 change blocks.
	171 lines changed or deleted		214 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/