< draft-schoenw-opsawg-nm-srv-02.txt		draft-schoenw-opsawg-nm-srv-03.txt >
	Internet Engineering Task Force J. Schoenwaelder		Internet Engineering Task Force J. Schoenwaelder
	Internet-Draft Jacobs University Bremen		Internet-Draft Jacobs University Bremen
	Intended status: Standards Track T. Tsou		Intended status: Informational T. Tsou
	Expires: December 7, 2011 C. Zhou		Expires: September 13, 2012 C. Zhou
	Huawei Technologies		Huawei Technologies
	June 5, 2011		March 12, 2012
	DNS SRV Resource Records for Network Management Protocols		DNS SRV Resource Records for Network Management Protocols
	draft-schoenw-opsawg-nm-srv-02		draft-schoenw-opsawg-nm-srv-03
	Abstract		Abstract
	This document specifies how to use Domain Name Service (DNS) SRV		This document specifies how to use Domain Name Service (DNS) SRV
	Resource Records (RRs) to locate network management services.		Resource Records (RRs) to locate network management services.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that		Task Force (IETF). Note that other groups may also distribute
	other groups may also distribute working documents as Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts.		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."
	The list of current Internet-Drafts can be accessed at		This Internet-Draft will expire on September 13, 2012.
	http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on December 7, 2011.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2012 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	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 BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. SRV Service Labels . . . . . . . . . . . . . . . . . . . . . . 3		2. Service Names . . . . . . . . . . . . . . . . . . . . . . . . 3
	2.1. SYSLOG . . . . . . . . . . . . . . . . . . . . . . . . . . 3		2.1. SYSLOG . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2.2. SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . 4		2.2. SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	2.3. NETCONF . . . . . . . . . . . . . . . . . . . . . . . . . . 4		2.3. NETCONF . . . . . . . . . . . . . . . . . . . . . . . . . 6
	3. Security Considerations . . . . . . . . . . . . . . . . . . . . 5		3. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5		5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	5.1. Normative References . . . . . . . . . . . . . . . . . . . 5		5.1. Normative References . . . . . . . . . . . . . . . . . . . 8
	5.2. Informative References . . . . . . . . . . . . . . . . . . 6		5.2. Informative References . . . . . . . . . . . . . . . . . . 9
	Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . . 6		Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . . 10
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
	1. Introduction		1. Introduction
	This document specifies how to use Domain Name Service (DNS) SRV		This document specifies how to use Domain Name Service (DNS) SRV
	Resource Records (RRs) [RFC2782] to locate network management		Resource Records (RRs) [RFC2782] to locate network management
	services. The use of SRV RRs can be useful in network bootstrapping		services. The use of SRV RRs can be useful in network bootstrapping
	scenarios or in zero-configuration network scenarios (e.g., home		scenarios or in zero-configuration network scenarios (e.g., home
	networks).		networks).
	The network management DNS SRV RRs defined in this memo may be used		The network management DNS SRV RRs defined in this memo may be used
	for different purposes:		for different purposes:
	o Manageable devices announce their management interfaces using a		o Manageable devices announce their management interfaces using a
	multicast DNS service. A management system discovers the devices		multicast DNS service [I-D.cheshire-dnsext-multicastdns]. A
	and initiates management interactions with them.		management system discovers the devices and initiates management
			interactions with them.
	o Devices discover destinations for event notifications or logging		o Devices discover destinations for event notifications or logging
	services by looking up (statically) configured SRV RRs in the DNS.		services by looking up (statically) configured SRV RRs in the DNS.
	The DNS SRV RRs defined in this memo address some gaps identified for		The DNS SRV RRs defined in this memo address some gaps identified for
	the automated configuration of large IP networks		the automated configuration of large IP networks
	[I-D.ietf-opsawg-automated-network-configuration].		[I-D.ietf-opsawg-automated-network-configuration].
	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 RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	2. SRV Service Labels		2. Service Names
			IANA maintains the registry for service names and port numbers
			[RFC6335]. The service names maintained in this registry can be used
			with DNS SRV records. In addition, these service names can be used
			for dynamic service discovery as defined in
			[I-D.cheshire-dnsext-dns-sd].
	2.1. SYSLOG		2.1. SYSLOG
	The Reliable Delivery of syslog specification [RFC3195] mentions the		The Reliable Delivery of syslog specification [RFC3195] already
	usage of DNS SRV RRs to locate SYSLOG collectors. The more recent		mentions the usage of DNS SRV RRs to locate SYSLOG collectors. The
	SYSLOG protocol specification [RFC5424] and the associated transport		more recent SYSLOG protocol specification [RFC5424] and the
	mappings ([RFC5425], [RFC5426], [RFC6012]) do not discuss the usage		associated transport mappings ([RFC5425], [RFC5426], [RFC6012]) do
	of SRV RRs to locate SYSLOG collectors. This specification takes the		not discuss the usage of SRV RRs to locate SYSLOG collectors. This
	service label definition from [RFC3195] and makes it applicable to		specification takes the service label definition from [RFC3195] and
	structured SYSLOG as defined in [RFC5424]:		makes it applicable to structured SYSLOG as defined in [RFC5424]:
	_syslog Identifies a SYSLOG collector. This SRV RR is primarily		_syslog Identifies a SYSLOG collector. This SRV RR is primarily
	for discovery of SYSLOG collectors by SYSLOG originators		for discovery of SYSLOG collectors by SYSLOG originators
	or relays.		or relays.
	Example: service records		Example: service records
	_syslog._tcp SRV 0 1 6514 syslog.example.com.		_syslog._tcp SRV 0 1 6514 syslog.example.com.
	_syslog._udp SRV 0 1 514 syslog.example.com.		_syslog._udp SRV 0 1 514 syslog.example.com.
	A SYSLOG originator may need additional information to send SYSLOG		A SYSLOG originator may need additional information to send SYSLOG
	messages to a SYSLOG collector. How this information is derived is		messages to a SYSLOG collector. How this information is derived is
	not specified and implementation dependent.		not specified and implementation dependent.
			Note that the IANA service names and port number registry defines the
			following service names and default port numbers:
			+-------------+------+-------+-------------------------+-----------+
			| Name | Port | Proto | Description | Reference |
			+-------------+------+-------+-------------------------+-----------+
			| syslog | 514 | udp | Syslog over UDP | [RFC5426] |
			| syslog-conn | 601 | tcp | Reliable Syslog Service | [RFC3195] |
			| syslog-conn | 601 | udp | Reliable Syslog Service | [RFC3195] |
			| syslog-tls | 6514 | tcp | Syslog over TLS | [RFC5425] |
			| syslog-tls | 6514 | udp | Syslog over DTLS | [RFC5425] |
			| syslog-tls | 6514 | dccp | Syslog over DTLS | [RFC5425] |
			+-------------+------+-------+-------------------------+-----------+
			Table 1: SYSLOG Service Names and Port Numbers
			[[SYSLOG-Q1: Shall we suggest that implementations MUST or SHOULD use
			only the syslog service name for discovery? This way, it is not
			necessary to start a discovery for multiple service names. Of
			course, we also loose some context information (e.g., that TLS is to
			be used, which might matter if non-default port numbers are used).
			--JS]]
			[[SYSLOG-Q2: What is the future of Reliable Syslog? Can we expect
			this to be retired so that we can choose to ignore it? --JS]]
			[[SYSLOG-Q3: What to do with SYSLOG over DTLS/DCCP? Section 7 of the
			multicast service discovery document suggests that applications using
			transport protocols different from UDP and TCP should all use the
			_udp protocol label. Its unclear whether this is generally accepted
			common practice for SRV records or only a specific recommendation for
			service discovery. --JS]]
			[[SYSLOG-Q4: SYSLOG over plain TCP is forthcoming. At the time of
			this writing, the specification is with the IESG. --JS]]
	2.2. SNMP		2.2. SNMP
	The Simple Network Management Protocol (SNMP) [RFC3410] distinguishes		The Simple Network Management Protocol (SNMP) [RFC3410] distinguishes
	between SNMP entities containing command responder and notification		between SNMP entities containing command responder and notification
	originator applications (traditionally called agents) and SNMP		originator applications (traditionally called agents) and SNMP
	entities containing command generator and/or notification receiver		entities containing command generator and/or notification receiver
	applications (traditionally called managers) [RFC3411]. This		applications (traditionally called managers) [RFC3411]. This
	specification defines two new SRV service labels for SNMP:		specification defines two new SRV service labels for SNMP:
	_snmp Identifies an SNMP entity containing a command responder		_snmp Identifies an SNMP entity containing a command responder
	skipping to change at page 4, line 42 ¶		skipping to change at page 5, line 38 ¶
	An SNMP engine containing a command generator application needs		An SNMP engine containing a command generator application needs
	additional information to send SNMP messages to a SNMP engine		additional information to send SNMP messages to a SNMP engine
	containing a command responder application. How this information is		containing a command responder application. How this information is
	derived is not specified and implementation dependent. Similarily,		derived is not specified and implementation dependent. Similarily,
	an SNMP engine containing a notification originator application needs		an SNMP engine containing a notification originator application needs
	additional information to send SNMP messages to a SNMP engine		additional information to send SNMP messages to a SNMP engine
	containing a notification receiver application. How this information		containing a notification receiver application. How this information
	is derived is not specified and implementation dependent.		is derived is not specified and implementation dependent.
			Note that the IANA service names and port number registry defines the
			following service names and default port numbers:
			+--------------+-------+-------+----------------------+-----------+
			| Name | Port | Proto | Description | Reference |
			+--------------+-------+-------+----------------------+-----------+
			| snmp | 161 | udp | SNMP over UDP | [RFC3430] |
			| snmp | 161 | tcp | SNMP over TCP | [RFC3417] |
			| snmp-trap | 162 | udp | SNMP traps over UDP | [RFC3430] |
			| snmp-trap | 162 | tcp | SNMP traps over TCP | [RFC3417] |
			| snmpssh | 5161 | tcp | SNMP over SSH | [RFC5592] |
			| snmpssh-trap | 5162 | tcp | SNMP traps over SSH | [RFC5592] |
			| snmptls | 10161 | tcp | SNMP over TLS | [RFC6353] |
			| snmpdtls | 10161 | udp | SNMP over DTLS | [RFC6353] |
			| snmptls-trap | 10162 | tcp | SNMP traps over TLS | [RFC6353] |
			| snmptls-trap | 10162 | udp | SNMP traps over DTLS | [RFC6353] |
			+--------------+-------+-------+----------------------+-----------+
			Table 2: SNMP Service Names and Port Numbers
			[[SNMP-Q1: Shall we suggest that implementations MUST or SHOULD use
			only the snmp and snmp-trap service names for discovery? This way,
			it is not necessary to start a discovery for multiple service names.
			Of course, we also loose some context information (e.g., that TLS is
			to be used, which might matter if non-default port numbers are used).
			--JS]]
	2.3. NETCONF		2.3. NETCONF
	The NECONF protocol [RFC4741] provides mechanisms to install,		The NECONF protocol [RFC6241] provides mechanisms to install,
	manipulate, and delete the configuration of network devices. The		manipulate, and delete the configuration of network devices. The
	mandatory to implement transport uses the Secure Shell (SSH) protocol		mandatory to implement transport uses the Secure Shell (SSH) protocol
	[RFC4742]. SSH sessions are initiated by the NETCONF client. This		[RFC6242]. SSH sessions are initiated by the NETCONF client. This
	specification adds a new SRV service label for NETCONF:		specification adds a new SRV service label for NETCONF:
	_netconf Identifies a NETCONF server. This record is primarily		_netconf Identifies a NETCONF server. This record is primarily
	for discovery of NETCONF servers that announce their		for discovery of NETCONF servers that announce their
	presence using multicast DNS protocols.		presence using multicast DNS protocols.
	Example: service records		Example: service records
	_netconf._tcp SRV 0 1 830 device.example.com.		_netconf._tcp SRV 0 1 830 device.example.com.
	A NETCONF client needs additional information in order to establish a		A NETCONF client needs additional information in order to establish a
	session with a NETCONF server. How this information is derived is		session with a NETCONF server. How this information is derived is
	not specified and implementation dependent.		not specified and implementation dependent.
			Note that the IANA service names and port number registry defines the
			following service names and default port numbers:
			+-----------------+------+-------+----------------------+-----------+
			| Name | Port | Proto | Description | Reference |
			+-----------------+------+-------+----------------------+-----------+
			| netconf-ssh | 830 | tcp | NETCONF over SSH | [RFC6242] |
			| netconf-beep | 831 | tcp | NETCONF over BEEP | [RFC4744] |
			| netconfsoaphttp | 832 | tcp | NETCONF over | [RFC4743] |
			| | | | SOAP/HTTP | |
			| netconfsoapbeep | 833 | tcp | NETCONF over | [RFC4743] |
			| | | | SOAP/BEEP | |
			| netconf-tls | 6513 | tcp | NETCONF over TLS | [RFC5539] |
			+-----------------+------+-------+----------------------+-----------+
			Table 3: NETCONF Service Names and Port Numbers
			[[NETCONF-Q1: Shall we suggest that implementations MUST or SHOULD
			use only the netconf service name for discovery? This way, it is not
			necessary to start a discovery for multiple service names. Of
			course, we also loose some context information (e.g., that TLS or SSH
			is to be used, which might matter if non-default port numbers are
			used). --JS]]
			[[NETCONF-Q2: There is discussion to retire NETCONF over SOAP and
			NETCONF over BEEP which may simplify this a bit. --JS]]
	3. Security Considerations		3. Security Considerations
	The security considerations spelled out in the DNS SRV specification		The security considerations spelled out in the DNS SRV specification
	[RFC2782] apply. In general, the usage of DNSSEC [RFC4033] is		[RFC2782] apply. In general, the usage of DNSSEC [RFC4033] is
	recommended in environments where DNS cannot be trusted.		recommended in environments where DNS cannot be trusted.
	The usage of multicast DNS protocols to discover network management		The usage of multicast DNS protocols to discover network management
	services potentially introduces new security risks since such		services potentially introduces new security risks since such
	protocols usually assume cooperating participants. In an environment		protocols usually assume cooperating participants. In an environment
	where antagonistic participants exists, it is necessary to deploy		where antagonistic participants exists, it is necessary to deploy
	skipping to change at page 5, line 35 ¶		skipping to change at page 8, line 4 ¶
	protocols usually assume cooperating participants. In an environment		protocols usually assume cooperating participants. In an environment
	where antagonistic participants exists, it is necessary to deploy		where antagonistic participants exists, it is necessary to deploy
	additional security mechanism such as DNSSEC to securely discover		additional security mechanism such as DNSSEC to securely discover
	network management services.		network management services.
	4. IANA Considerations		4. IANA Considerations
	TBD		TBD
	5. References		5. References
	5.1. Normative References		5.1. Normative References
			[I-D.cheshire-dnsext-dns-sd]
			Cheshire, S. and M. Krochmal, "DNS-Based Service
			Discovery", draft-cheshire-dnsext-dns-sd-11 (work in
			progress), December 2011.
			[I-D.cheshire-dnsext-multicastdns]
			Cheshire, S. and M. Krochmal, "Multicast DNS",
			draft-cheshire-dnsext-multicastdns-15 (work in progress),
			December 2011.
	[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, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for		[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
	specifying the location of services (DNS SRV)", RFC 2782,		specifying the location of services (DNS SRV)", RFC 2782,
	February 2000.		February 2000.
			[RFC3195] New, D. and M. Rose, "Reliable Delivery for syslog",
			RFC 3195, November 2001.
			[RFC3417] Presuhn, R., "Transport Mappings for the Simple Network
			Management Protocol (SNMP)", STD 62, RFC 3417,
			December 2002.
			[RFC3430] Schoenwaelder, J., "Simple Network Management Protocol
			Over Transmission Control Protocol Transport Mapping",
			RFC 3430, December 2002.
	[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.		[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
	Rose, "DNS Security Introduction and Requirements",		Rose, "DNS Security Introduction and Requirements",
	RFC 4033, March 2005.		RFC 4033, March 2005.
	[RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741,		[RFC4743] Goddard, T., "Using NETCONF over the Simple Object Access
	December 2006.		Protocol (SOAP)", RFC 4743, December 2006.
	[RFC4742] Wasserman, M. and T. Goddard, "Using the NETCONF		[RFC4744] Lear, E. and K. Crozier, "Using the NETCONF Protocol over
	Configuration Protocol over Secure SHell (SSH)", RFC 4742,		the Blocks Extensible Exchange Protocol (BEEP)", RFC 4744,
	December 2006.		December 2006.
	[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.		[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
	[RFC5425] Miao, F., Ma, Y., and J. Salowey, "Transport Layer		[RFC5425] Miao, F., Ma, Y., and J. Salowey, "Transport Layer
	Security (TLS) Transport Mapping for Syslog", RFC 5425,		Security (TLS) Transport Mapping for Syslog", RFC 5425,
	March 2009.		March 2009.
	[RFC5426] Okmianski, A., "Transmission of Syslog Messages over UDP",		[RFC5426] Okmianski, A., "Transmission of Syslog Messages over UDP",
	RFC 5426, March 2009.		RFC 5426, March 2009.
			[RFC5539] Badra, M., "NETCONF over Transport Layer Security (TLS)",
			RFC 5539, May 2009.
			[RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure
			Shell Transport Model for the Simple Network Management
			Protocol (SNMP)", RFC 5592, June 2009.
	[RFC6012] Salowey, J., Petch, T., Gerhards, R., and H. Feng,		[RFC6012] Salowey, J., Petch, T., Gerhards, R., and H. Feng,
	"Datagram Transport Layer Security (DTLS) Transport		"Datagram Transport Layer Security (DTLS) Transport
	Mapping for Syslog", RFC 6012, October 2010.		Mapping for Syslog", RFC 6012, October 2010.
			[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
			Bierman, "Network Configuration Protocol (NETCONF)",
			RFC 6241, June 2011.
			[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
			Shell (SSH)", RFC 6242, June 2011.
			[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
			Cheshire, "Internet Assigned Numbers Authority (IANA)
			Procedures for the Management of the Service Name and
			Transport Protocol Port Number Registry", BCP 165,
			RFC 6335, August 2011.
			[RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport
			Model for the Simple Network Management Protocol (SNMP)",
			RFC 6353, July 2011.
	5.2. Informative References		5.2. Informative References
	[I-D.ietf-opsawg-automated-network-configuration]		[I-D.ietf-opsawg-automated-network-configuration]
	ZOU), T., Schoenwaelder, J., Shi, Y., Taylor, T., and G.		Tsou, T., Schoenwaelder, J., Shi, Y., Taylor, T., and G.
	Yang, "Problem Statement for the Automated Configuration		Yang, "Problem Statement for the Automated Configuration
	of Large IP Networks",		of Large IP Networks",
	draft-ietf-opsawg-automated-network-configuration-01 (work		draft-ietf-opsawg-automated-network-configuration-03 (work
	in progress), May 2011.		in progress), March 2012.
	[RFC3195] New, D. and M. Rose, "Reliable Delivery for syslog",
	RFC 3195, November 2001.
	[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,		[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
	"Introduction and Applicability Statements for Internet-		"Introduction and Applicability Statements for Internet-
	Standard Management Framework", RFC 3410, December 2002.		Standard Management Framework", RFC 3410, December 2002.
	[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An		[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
	Architecture for Describing Simple Network Management		Architecture for Describing Simple Network Management
	Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,		Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
	December 2002.		December 2002.
	Appendix A. Open Issues		Appendix A. Open Issues
	1. draft-gudmundsson-dns-srv-iana-registry-04 proposes a template		1. draft-hallambaker-esrv-01 proposes a RRs to store additional
	for registering SRV names. We may have to use this format in
	case this I-D moves forward.
	2. draft-hallambaker-esrv-01 proposes a RRs to store additional
	information in so called General Service Description (GSRV) and		information in so called General Service Description (GSRV) and
	Extended Service Description (ESRV) records (e.g., which security		Extended Service Description (ESRV) records (e.g., which security
	protocol to use). This is traditionally done using TXT records.		protocol to use). This is traditionally done using TXT records.
	3. draft-gudmundsson-dnsext-srv-clarify-02 clarifies service names		2. draft-kwatsen-reverse-ssh-00 proposes a mechanism which allows an
	and their usage.
	4. draft-kwatsen-reverse-ssh-00 proposes a mechanism which allows an
	SSH server to establish the TCP connection to an SSH client; if		SSH server to establish the TCP connection to an SSH client; if
	this moves forward NETCONF servers may want to discover NETCONF		this moves forward NETCONF servers may want to discover NETCONF
	clients.		clients.
	5. Add support for NTP? (DHC has an option to configure IP address
	of NTP servers.)
	Authors' Addresses		Authors' Addresses
	Juergen Schoenwaelder		Juergen Schoenwaelder
	Jacobs University Bremen		Jacobs University Bremen
	Campus Ring 1		Campus Ring 1
	Bremen 28759		Bremen 28759
	Germany		Germany
	Email: j.schoenwaelder@jacobs-university.de		Email: j.schoenwaelder@jacobs-university.de
End of changes. 29 change blocks.
	64 lines changed or deleted		186 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/