< draft-ietf-ips-iscsi-nodearch-key-02.txt		draft-ietf-ips-iscsi-nodearch-key-03.txt >
	IP Storage Working Group D. Wysochanski		IP Storage Working Group D. Wysochanski
	Internet-Draft September 2006		Internet-Draft November 21, 2006
	Intended status: Informational		Updates: 3720 (if approved)
	Expires: March 5, 2007		Intended status: Standards Track
			Expires: May 25, 2007
	Declarative Public Extension Key for iSCSI Node Architecture		Declarative Public Extension Key for iSCSI Node Architecture
	draft-ietf-ips-iscsi-nodearch-key-02.txt		draft-ietf-ips-iscsi-nodearch-key-03.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of 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), its areas, and its working groups. Note that
	skipping to change at page 1, line 34 ¶		skipping to change at page 1, line 35 ¶
	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		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on March 5, 2007.		This Internet-Draft will expire on May 25, 2007.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2006).		Copyright (C) The Internet Society (2006).
	Abstract		Abstract
	The iSCSI protocol, described in RFC 3720 [2], allows for extension		The iSCSI protocol, described in RFC 3720 [2], allows for extension
	items to the protocol in the form of Private or Public Extension		items to the protocol in the form of Private or Public Extension
	Keys. This Internet-Draft describes a Public Extension Key for the		Keys. This Internet-Draft describes a Public Extension Key for the
	purpose of enhancing iSCSI supportability. The key accomplishes this		purpose of enhancing iSCSI supportability. The key accomplishes this
	objective by allowing iSCSI nodes to communicate architecture details		objective by allowing iSCSI nodes to communicate architecture details
	during the iSCSI login sequence. The receiving node can then use		during the iSCSI login sequence. The receiving node can then use
	this information for enhanced logging and support.		this information for enhanced logging and support. This document
			updates RFC 3720 to allow iSCSI extension items to be defined by
			standards track RFCs and experimental RFCs in addition to
			informational RFCs.
	1. Introduction		1. Introduction
	1.1. Terminology		1.1. Terminology
	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 [1].		document are to be interpreted as described in RFC 2119 [1].
	1.2. Overview		1.2. Overview
	skipping to change at page 3, line 33 ¶		skipping to change at page 3, line 33 ¶
	The key has been modeled after the HTTP "Server" and "User-Agent"		The key has been modeled after the HTTP "Server" and "User-Agent"
	header fields as specified in sections 14.38 and 14.43 of RFC 2616		header fields as specified in sections 14.38 and 14.43 of RFC 2616
	[3], with the text-value(s) of the key roughly equivalent to Product		[3], with the text-value(s) of the key roughly equivalent to Product
	Tokens in section 3.8 of RFC 2616 [3]. Note however that the text-		Tokens in section 3.8 of RFC 2616 [3]. Note however that the text-
	value(s) in the key's list-of-values MUST conform to the Text Format		value(s) in the key's list-of-values MUST conform to the Text Format
	as specified in section 5.1 of RFC 3720 [2].		as specified in section 5.1 of RFC 3720 [2].
	The key is sent during operational parameter negotiation of an iSCSI		The key is sent during operational parameter negotiation of an iSCSI
	session's login phase. The intended use of this key is to provide		session's login phase. The intended use of this key is to provide
	enhanced logging and support capabilities, and to enable collection		enhanced logging and support capabilities, and to enable collection
	of iSCSI implementation and usage information. Functional behavior		of iSCSI implementation and usage information.
	of the iSCSI node (this includes the iSCSI protocol logic -- the
	SCSI, iSCSI, and TCP/IP protocols) MUST NOT depend on the presence,
	absence, or content of the key. The key MUST NOT be used by iSCSI
	nodes for interoperability, or exclusion of other nodes. To ensure
	proper use, key values SHOULD be set by the node itself, and there
	SHOULD NOT be provisions for the key values to contain user-defined
	text.
	2. Definition		2. Definition
	The definition of the key is as follows, conforming to sections 11		The definition of the key is as follows, conforming to sections 11
	and 12 of RFC 3720 [2], with example list-of-values conforming to		and 12 of RFC 3720 [2], with example list-of-values conforming to
	section 5.1 of RFC 3720 [2].		section 5.1 of RFC 3720 [2].
	The key is defined with a Use of "LO", making it a Leading Only key,		The key is defined with a Use of "LO", making it a Leading Only key,
	and does not modify sections 11 or 12 of RFC 3720 [2]. Thus, the key		and does not modify sections 11 or 12 of RFC 3720 [2]. Thus, the key
	MUST only be sent on the leading connection, MUST NOT be changed		MUST only be sent on the leading connection, MUST NOT be changed
	skipping to change at page 5, line 7 ¶		skipping to change at page 5, line 7 ¶
	are not limited to, iSCSI vendor software, firmware, or hardware		are not limited to, iSCSI vendor software, firmware, or hardware
	versions, the OS version, or hardware architecture.		versions, the OS version, or hardware architecture.
	The length of the key value (total length of the list-of-values) MUST		The length of the key value (total length of the list-of-values) MUST
	NOT be greater than 255 bytes.		NOT be greater than 255 bytes.
	X#NodeArchitecture MUST NOT be redeclared.		X#NodeArchitecture MUST NOT be redeclared.
	3. Implementation		3. Implementation
			Functional behavior of the iSCSI node (this includes the iSCSI
			protocol logic -- the SCSI, iSCSI, and TCP/IP protocols) MUST NOT
			depend on the presence, absence, or content of the key. The key MUST
			NOT be used by iSCSI nodes for interoperability, or exclusion of
			other nodes. To ensure proper use, key values SHOULD be set by the
			node itself, and there SHOULD NOT be provisions for the key values to
			contain user-defined text.
	Nodes implementing this key MAY choose to only transmit the key, only		Nodes implementing this key MAY choose to only transmit the key, only
	log the key values received from other nodes, or both transmit and		log the key values received from other nodes, or both transmit and
	log the key values. Each node choosing to implement transmission of		log the key values. Each node choosing to implement transmission of
	the key values MUST be prepared to handle the response of RFC 3720		the key values MUST be prepared to handle the response of RFC 3720
	[2] compliant nodes that do not understand the key (RFC 3720 [2]		[2] compliant nodes that do not understand the key (RFC 3720 [2]
	states that compliant nodes MUST respond with		states that compliant nodes MUST respond with
	X#NodeArchitecture=NotUnderstood).		X#NodeArchitecture=NotUnderstood).
	Nodes that implement transmission and/or logging of the key values		Nodes that implement transmission and/or logging of the key values
	may also implement administrative mechanisms that disable and/or		may also implement administrative mechanisms that disable and/or
	skipping to change at page 8, line 7 ¶		skipping to change at page 8, line 7 ¶
	vulnerability level is viewed as high, since there are many well-		vulnerability level is viewed as high, since there are many well-
	known vulnerabilities to the general-purpose operating system.		known vulnerabilities to the general-purpose operating system.
	For the above target, an appropriate implementation might be logging		For the above target, an appropriate implementation might be logging
	of received key values, but no transmission of the key. For the		of received key values, but no transmission of the key. For the
	initiators, an appropriate implementation might be transmission of		initiators, an appropriate implementation might be transmission of
	the key, but no logging of received key values.		the key, but no logging of received key values.
	5. IANA Considerations		5. IANA Considerations
	This document defines the iSCSI Extension Key NodeArchitecture to be		The standards action of this document updates RFC 3720 to allow any
	registered in the IANA iSCSI extended key registry.		iSCSI extension item, specifically X# extension text keys, Y# digest
			algorithms, and Z# authentication methods, to be defined by a
			standards track RFC or experimental RFC in addition to an
			informational RFC. This document is a standards track RFC that
			defines an X# extension text key.
	The IANA iSCSI Extended Key registry does not correspond to RFC 3720		The IANA iSCSI Extended Key registry does not correspond to RFC 3720
	that defined it. The registry should contain three fields for each		that defined it. The registry should contain three fields for each
	extended key:		extended key:
	o Key Name		o Key Name
	o Description		o Description
	o Reference		o Reference
	IANA should modify the registry accordingly, and then register this		IANA should modify the registry accordingly.
	key as follows:
			IANA should register this key as follows:
	o Key Name: X#NodeArchitecture		o Key Name: X#NodeArchitecture
	o Description: Node architecture details		o Description: Node architecture details
	o Reference: [this RFC-to-be]		o Reference: [this RFC-to-be]
	-- RFC Editor: The paragraph starting from "The IANA iSCSI Extended		-- RFC Editor: The text from "The IANA iSCSI Extended Key" through
	Key" should be removed prior to RFC publication.		"modify the registry accordingly." should be removed after the IANA
			actions for this document are performed prior to RFC publication.
	6. References		6. References
	6.1. Normative References		6.1. Normative References
	[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Levels", BCP 14, RFC 2119, March 1997.		Levels", BCP 14, RFC 2119, March 1997.
	[2] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M., and E.		[2] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M., and E.
	Zeidner, "Internet Small Computer Systems Interface (iSCSI)",		Zeidner, "Internet Small Computer Systems Interface (iSCSI)",
	skipping to change at page 10, line 5 ¶		skipping to change at page 10, line 5 ¶
	6.2. Informative References		6.2. Informative References
	[3] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,		[3] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
	Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --		Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
	HTTP/1.1", RFC 2616, June 1999.		HTTP/1.1", RFC 2616, June 1999.
	[4] Aboba, B., Tseng, J., Walker, J., Rangan, V., and F. Travostino,		[4] Aboba, B., Tseng, J., Walker, J., Rangan, V., and F. Travostino,
	"Securing Block Storage Protocols over IP", RFC 3723,		"Securing Block Storage Protocols over IP", RFC 3723,
	April 2004.		April 2004.
	Appendix A. Acknowledgements		Appendix A. Acknowledgments
	The IP Storage (ips) Working Group in the Transport Area of IETF has		The IP Storage (ips) Working Group in the Transport Area of IETF has
	been responsible for defining the iSCSI protocol (apart from a host		been responsible for defining the iSCSI protocol (apart from a host
	of other relevant IP Storage protocols). The editor acknowledges the		of other relevant IP Storage protocols). The editor acknowledges the
	contributions of the entire working group.		contributions of the entire working group.
	The following individuals directly contributed to identifying issues		The following individuals directly contributed to identifying issues
	and/or suggesting resolutions to the issues found in this document:		and/or suggesting resolutions to the issues found in this document:
	David Black, Mallikarjun Chadalapaka, Paul Koning, Julian Satran,		David Black, Mallikarjun Chadalapaka, Paul Koning, Julian Satran,
	John Hufferd, Claire Kraft, Ranga Sankar, Joseph Pittman, Greg Berg,		John Hufferd, Claire Kraft, Ranga Sankar, Joseph Pittman, Greg Berg,
End of changes. 10 change blocks.
	21 lines changed or deleted		32 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/