draft-ietf-dhc-isnsoption-01.txt   draft-ietf-dhc-isnsoption-02.txt 
DHC Josh Tseng DHC Working Group Josh Tseng
Internet Draft Kevin Gibbons INTERNET DRAFT Kevin Gibbons
<draft-ietf-dhc-isnsoption-01.txt> Nishan Systems Expires: February 2003 Charles Monia
Expires January 2003 July 2002 Internet Draft
Document: <draft-ietf-dhc-isnsoption-02.txt> Nishan Systems
Category: Standards Track August 2002
DHCP Options for Internet Storage Name Service DHCP Options for Internet Storage Name Service
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of [RFC2026]. all provisions of Section 10 of [RFC2026].
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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Internet-Drafts are draft documents valid for a maximum of Drafts. Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by other six months and may be updated, replaced, or made obsolete by other
documents at any time. It is inappropriate to use Internet- Drafts documents at any time. It is inappropriate to use Internet- Drafts
as reference material or to cite them other than as "work in as reference material or to cite them other than as "work in
progress." 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.
skipping to change at page 1, line 41 skipping to change at page 1, line 43
Comments should be sent to the IPS mailing list (ips@ece.cmu.edu) or Comments should be sent to the IPS mailing list (ips@ece.cmu.edu) or
to the authors. to the authors.
Table of Contents Table of Contents
Status of this Memo...................................................1 Status of this Memo...................................................1
Comments..............................................................1 Comments..............................................................1
Abstract..............................................................2 Abstract..............................................................2
Conventions used in this document.....................................2 Conventions used in this document.....................................2
1. Introduction......................................................2 1.Introduction.......................................................2
2. iSNS Option for DHCP..............................................3 2.iSNS Option for DHCP...............................................3
3. Security Considerations...........................................6 2.1 iSNS Functions Field.............................................4
4. References........................................................6 2.2 Discovery Domain Access Field....................................5
5. Author's Addresses................................................7 2.3 Administrative Flags Field.......................................6
Full Copyright Statement..............................................8 3.Security Considerations............................................8
DHCP Option Number for iSNS February 2002 4.Normative References...............................................8
5.Non-Normative References...........................................8
6.Author's Addresses.................................................9
Full Copyright Statement.............................................10
DHCP Option Number for iSNS Revision 2 August 2002
Abstract Abstract
This document describes the DHCP option to allow iSNS clients This document describes the DHCP option to allow iSNS clients
devices using DHCP to automatically discover the location of the devices using DHCP to automatically discover the location of the
iSNS server. iSNS provides discovery and management capabilities for iSNS server. iSNS provides discovery and management capabilities for
iSCSI and Fibre Channel (FCP) storage devices in an enterprise-scale iSCSI and Fibre Channel (FCP) storage devices in an enterprise-scale
IP storage network. iSNS provides intelligent storage management IP storage network. iSNS provides intelligent storage management
services comparable to those found in Fibre Channel networks, services comparable to those found in Fibre Channel networks,
allowing a commodity IP network to function in a similar capacity as allowing a commodity IP network to function in a similar capacity as
skipping to change at page 2, line 44 skipping to change at page 2, line 44
"iSNS Server" - The iSNS server responds to iSNS protocol query and "iSNS Server" - The iSNS server responds to iSNS protocol query and
registration messages, and initiates asynchronous notification registration messages, and initiates asynchronous notification
messages. The iSNS server stores information registered by iSNS messages. The iSNS server stores information registered by iSNS
clients. clients.
"iSCSI (Internet SCSI)" - iSCSI is an encapsulation of SCSI for a "iSCSI (Internet SCSI)" - iSCSI is an encapsulation of SCSI for a
new generation of storage devices interconnected with TCP/IP. new generation of storage devices interconnected with TCP/IP.
"iFCP (Internet Fibre Channel Protocol)" - iFCP is a gateway-to- "iFCP (Internet Fibre Channel Protocol)" - iFCP is a gateway-to-
gateway protocol designed to interconnect existing Fibre Channel and gateway protocol designed to interconnect existing Fibre Channel
SCSI devices using TCP/IP. iFCP maps the existing FCP standard and devices using TCP/IP. iFCP maps the Fibre Channel transport and
associated Fibre Channel services to TCP/IP. fabric services to TCP/IP.
1. Introduction 1. Introduction
The Dynamic Host Configuration Protocol provides a framework for The Dynamic Host Configuration Protocol provides a framework for
passing configuration information to hosts. Its usefulness extends passing configuration information to hosts. Its usefulness extends
to hosts and devices using the iSCSI and iFCP protocols to connect to hosts and devices using the iSCSI and iFCP protocols to connect
to block level storage assets over a TCP/IP network. to block level storage assets over a TCP/IP network.
The iSNS Protocol provides a framework for automated discovery, The iSNS Protocol provides a framework for automated discovery,
management, and configuration of iSCSI and iFCP devices on a TCP/IP management, and configuration of iSCSI and iFCP devices on a TCP/IP
network. It provides functionality similar to that found on Fibre network. It provides functionality similar to that found on Fibre
Channel networks, except that iSNS works within the context of an IP Channel networks, except that iSNS works within the context of an IP
DHCP Option Number for iSNS February 2002 DHCP Option Number for iSNS Revision 2 August 2002
network. iSNS thereby provides the requisite storage intelligence network. iSNS thereby provides the requisite storage intelligence
to IP networks that are standard on existing Fibre Channel networks. to IP networks that are standard on existing Fibre Channel networks.
Existing DHCP option numbers are not plausible due to the following Existing DHCP option numbers are not plausible due to the following
reasons: reasons:
1) iSNS functionality is distinctly different from other protocols a) iSNS functionality is distinctly different from other protocols
using existing DHCP option numbers. Specifically, iSNS provides a using existing DHCP option numbers. Specifically, iSNS provides
significant superset of capabilities compared to typical name a significant superset of capabilities compared to typical name
resolution protocols such as DNS. It is designed to support client resolution protocols such as DNS. It is designed to support
devices that allow themselves to be configured and managed from a client devices that allow themselves to be configured and
central iSNS server. managed from a central iSNS server
2) iSNS requires a DHCP option format that provides more than the b) iSNS requires a DHCP option format that provides more than the
location of the iSNS server. The DHCP option number needs to location of the iSNS server. The DHCP option number needs to
specify the subset of iSNS services that will be actively used by specify the subset of iSNS services that will be actively used
the iSNS client. by the iSNS client.
The DHCP option number for iSNS is used by iSCSI and iFCP devices to The DHCP option number for iSNS is used by iSCSI and iFCP devices to
discover the location and role of the iSNS server. The DHCP option discover the location and role of the iSNS server. The DHCP option
number assigned for iSNS by IANA is <<TBD>>. number assigned for iSNS by IANA is <<TBD>>.
2. iSNS Option for DHCP 2. iSNS Option for DHCP
This option specifies the location of the primary and backup iSNS This option specifies the location of the primary and backup iSNS
servers and the subset of iSNS services that will be used by the servers and the iSNS services available to an iSNS client.
iSNS client.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code = TBD | Length | iSNS Function | | Code = TBD | Length | iSNS Functions |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DD Access | Administrative FLAGS | | DD Access | Administrative FLAGS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| a1 | a2 | a3 | a4 | | a1 | a2 | a3 | a4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| b1 | b2 | b3 | b4 | | b1 | b2 | b3 | b4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . . | | . . . . |
| Additional Secondary iSNS Servers |
| . . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 -- iSNS Server Option
The iSNS Option specifies a list of IP addresses used by iSNS The iSNS Option specifies a list of IP addresses used by iSNS
servers. servers. The option contains the following parameters:
Length indicates the number of bytes that follow the Length field. Length: the number of bytes that follow the Length field. The
The minimum value for the Length field is 6 in order to account for minimum value for the Length field is 6 in order to account
the iSNS Function, Discovery Domain Access, and Administrative Flags for the iSNS Functions, Discovery Domain Access, and
field. Administrative Flags fields.
iSNS Function is a bitmap field defining the iSNS server's DHCP Option Number for iSNS Revision 2 August 2002
operational role (i.e., how the iSNS server is to be used). The
iSNS server's role can be as basic as to provide simple discovery
information, or as significant as to provide IKE/IPSec security
DHCP Option Number for iSNS February 2002
policies and certificates for the use of iSCSI and iFCP devices. The iSNS Functions: A bitmapped field defining the functions supported
format of the iSNS Role bit field is shown below: by the iSNS servers. The format of this field is described
in section 2.1.
Discovery Domain Access: A bit field indicating the types of iSNS
clients that are allowed to modify Discovery Domains. The
field contents are described in section 2.2.
Administrative Flags field: Contains the administrative settings for
the iSNS servers discovered through the DHCP query. The
contents of this field are described in section 2.3.
a1...a4: Depending on the setting of the Heartbeat bit in the
Administrative Flags field (see section 2.3), this field
contains either the IP address from which the iSNS heartbeat
originates (see [ISNS]) or the IP address of the primary
iSNS server.
b1...b4: Depending on the setting of Heartbeat bit in the
Administrative Flags field (see section 2.3), this field
contains either the IP address of the primary iSNS server or
a secondary iSNS server.
Additional Secondary iSNS Servers: Each set of four octets specifies
the IP address of a secondary iSNS server.
2.1 iSNS Functions Field
The iSNS Functions Field defines the iSNS server's operational role
(i.e., how the iSNS server is to be used). The iSNS server's role
can be as basic as providing simple discovery information, or as
significant as providing IKE/IPSec security policies and
certificates for the use of iSCSI and iFCP devices. The format of
the iSNS Role bit field is shown in Figure 2:
1 2 3 1 2 3
6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Site-Specific |RESERVED |S|A|E| |Vendor-Specific |RESERVED |S|A|E|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 -- iSNS Functions
Bit field Significance Bit field Significance
--------- ------------ --------- ------------
31 Enabled/Disabled 31 Function Fields Enabled
30 Authorization/Discovery Domains 30 DD-Based Authorization
29 Security 29 Security policy distribution
28-24 RESERVED 28 - 24 Reserved
23-16 Site-specific or Vendor-specific use only 23 - 16 Vendor-specific
Enabled/Disabled: This bit determines the validity of the iSNS Role Enabled: This bit specifies the validity of the
field. If this bit is enabled, then the contents of the remainder remaining iSNS Function fields. If set to
of the iSNS Role field are valid. If this bit is disabled, then the one, then the contents of all other iSNS
contents of the iSNS Role field are invalid. Function fields are valid. If set to zero,
DHCP Option Number for iSNS Revision 2 August 2002
Authorization: Indicates the role of the iSNS server in determining then the contents of all other iSNS
device access authorizations. If disabled, then the function of the Function fields MUST be ignored.
iSNS server is for target discovery purposes only. Discovery
Domains MAY be used to manage the discovery process, but they do not
necessarily indicate authorization to access discovered devices. If
enabled, then Discovery Domain/Zoning features of the iSNS indicate
device access authorizations. Devices in a common DD SHALL be
allowed access to each other if they are successfully authenticated.
Devices not in a common DD shall not be allowed to access each
other.
Security: Indicates whether the iSNS client is to download and use DD-based Indicates whether or not devices in a
the security policy configuration stored in the iSNS server. If Authorization: common Discovery Domain (DD) are implicitly
enabled, then the AuthMethod and IKE/IPSec policy stored in the iSNS authorized to access one another. Although
server SHALL be used by the iSNS client for its own security policy. Discovery Domains control the scope of
If disabled, then the iSNS client SHALL NOT query for its own device discovery, they do not necessarily
security policy attributes in the iSNS server. indicate whether or not a domain member is
authorized to access discovered devices.
If this bit is set to one, then devices in
a common Discovery Domain are automatically
allowed access to each other (if
successfully authenticated). If this bit
is set to zero, then access authorization
is not implied by domain membership and
must be explicitly performed by each
device. In either case, devices not in a
common discovery domain are not allowed to
access each other.
Site-Specific: These bits are used to indicate site-specific or Security: Indicates whether the iSNS client is to
vendor-specific capabilities in the indicated iSNS server. download and use the security policy
configuration stored in the iSNS server.
If set to one, then the policy is stored in
the iSNS server and must be used by the
iSNS client for its own security policy.
If set to zero, then the iSNS client must
obtain its security policy configuration by
other means.
Discovery Domain Access is a bit field that indicates the types of Vendor- These bits are used to indicate the vendor-
iSNS clients that are allowed to modify Discovery Domains. The Specific: specific capabilities supported by the
format of the DD Access bit field is shown below: indicated iSNS server.
DHCP Option Number for iSNS February 2002 2.2 Discovery Domain Access Field
The format of the DD Access bit field is shown in Figure 3:
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| R | R | if| tf| is| ts| C | E | | R | R | if| tf| is| ts| C | E |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
Figure 3 -- Discovery Domain Access
DHCP Option Number for iSNS Revision 2 August 2002
Bit field Significance Bit field Significance
--------- ------------ --------- ------------
7 Enabled/Disabled 7 Enabled
6 Control Node 6 Control Node
5 iSCSI Target 5 iSCSI Target
4 iSCSI Initiator 4 iSCSI Initiator
3 iFCP Target Port 3 iFCP Target Port
2 iFCP Initiator Port 2 iFCP Initiator Port
1 RESERVED 1 RESERVED
0 RESERVED 0 RESERVED
Enabled/Disabled: This bit determines the validity of the DD Access Enabled: This bit specifies the validity of the
bit field. If this bit is enabled, then the contents of the remaining DD Access bit fields. If this
remainder of the DD Access field are valid. If this bit is bit is set to one, then the contents of
disabled, then the contents of this field are invalid. the remainder of the DD Access field are
valid. If this bit is set to zero, then
the contents of the remainder of this
field MUST be ignored.
Control Node: Determines whether Control Nodes are allowed to add, Control Node: Specifies whether the iSNS server allows
delete, or modify Discovery Domains. If enabled, then Control Nodes Discovery Domains to be added, modified
are allowed. If disabled, then Control Nodes are not allowed to or deleted by means of Control Nodes. If
modify Discovery Domains. set to one, then Control Nodes are
allowed to modify the Discovery Domain
configuration. If set to zero, then
Control Nodes are not allowed to modify
Discovery Domain configurations.
iSCSI Target, iSCSI Initiator, iFCP Target Port, and iFCP Initiator iSCSI Target, These bits determine whether the
Port: These bits determine whether the respective registered iSNS iSCSI Initiator, respective registered iSNS client
client (determined by iSCSI Node Type or iFCP Port Role) is allowed iFCP Target Port, (determined by iSCSI Node Type or iFCP
to add, delete, or modify Discovery Domains. If enabled, then the iFCP Initiator Port Role) is allowed to add, delete, or
respective types of iSNS clients are allowed. If disabled, then Port: modify Discovery Domains. If set to
they are not allowed to modify Discovery Domains. one, then modification by the specified
client type is allowed. If set to zero,
then modification by the specified
client type is not allowed.
The Administrative Flags field configures the administrative (A node may implement multiple node
settings for the iSNS server discovered through the DHCP option. types.)
The format of the Administrative Flags bit field is as follows:
0 1 2 3 2.3 Administrative Flags Field
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Site-Specific | RESERVED |D|M|H|E|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Bit field Significance The format of the Administrative Flags bit field is shown in Figure
4:
DHCP Option Number for iSNS Revision 2 August 2002
1 2 3
8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESERVED |D|M|H|E|
+---+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4 -- Administrative Flags
Bit Field Significance
--------- ------------ --------- ------------
31 Enabled/Disabled 31 Enabled
30 Heartbeat 30 Heartbeat
29 Management SCN's 29 Management SCNs
28 Default Discovery Domain 28 Default Discovrery Domain
26-8 RESERVED 27 - 8 RESERVED
7-0 Site-specific or Vendor-specific use only
Enabled/Disabled: This bit determines the validity of the
Administrative Flags field. If this bit is enabled, then the
DHCP Option Number for iSNS February 2002
contents of the remainder of the Administrative Flags field are Enabled: Specifies the validity of the remainder
valid. If this bit is disabled, then the contents of this field are of the Administrative Flags field. If
invalid, indicating that iSNS administrative settings are configured set to one, then the contents of the
through alternative means other than DHCP. remaining Administrative Flags are
valid. If set to zero, then the
remaining contents MUST be ignored,
indicating that iSNS administrative
settings are obtained through means
other than DHCP.
Heartbeat: Indicates whether the first IP address is the multicast Heartbeat: Indicates whether the first IP address
address for the iSNS heartbeat message. If enabled, then a1-a4 is the multicast address from which the
contains the heartbeat multicast address and b1-b4 contains the IP iSNS heartbeat message originates. If
address of the primary iSNS server, followed by the IP address(es) set to one, then a1-a4 contains the
of any backup servers. If disabled, then a1-a4 contains the IP heartbeat multicast address and b1-b4
address of the primary iSNS server, followed by the IP address(es) contains the IP address of the primary
of any backup servers. iSNS server, followed by the IP
address(es) of any backup servers. If
set to zero, then a1-a4 contains the IP
address of the primary iSNS server,
followed by the IP address(es) of any
backup servers.
Management SCNs: Indicates whether control nodes are authorized to Management SCNs: Indicates whether control nodes are
register to receive Management SCN's. Management SCN's are a authorized to register to receive
special class of State Change Notification whose scope is the entire Management State Change Notifications
iSNS database. If enabled, then control nodes are authorized to (SCN's). Management SCN's are a special
register to receive Management SCN's. If disabled, then control class of State Change Notification whose
nodes are not authorized to receive Management SCN's (although they scope is the entire iSNS database. If
set to one, then control nodes are
authorized to register to receive
Management SCN's. If set to zero, then
control nodes are not authorized to
receive Management SCN's (although they
may receive normal SCN's). may receive normal SCN's).
Default Discovery Domain: Indicates whether a newly registered Default Discovery Indicates whether a newly registered
device that is not explicitly placed into a Discovery Domain (DD) device that is not explicitly placed
and Discovery Domain Set (DDS) should be automatically placed into a DHCP Option Number for iSNS Revision 2 August 2002
default DD and DDS. If enabled, then a default DD shall contain all
devices in the iSNS database that have not been explicitly placed Domain: into a Discovery Domain (DD) and
into a DD by an iSNS client. If disabled, then devices not Discovery Domain Set (DDS) should be
explicitly placed into a DD are not members of any DD. automatically placed into a default DD
and DDS. If set to one, then a default
DD shall contain all devices in the iSNS
database that have not been explicitly
placed into a DD by an iSNS client. If
set to zero, then devices not explicitly
placed into a DD are not members of any
DD.
3. Security Considerations 3. Security Considerations
DHCP currently provides no authentication or security mechanisms. DHCP currently provides no authentication or security mechanisms.
Potential exposures to attack are discussed in section 7 of the DHCP Potential exposures to attack are discussed in section 7 of the DHCP
protocol specification [DHCP]. protocol specification [DHCP].
iSNS security considerations are discussed in [iSNS] and [SEC-IPS]. iSNS security considerations are discussed in [iSNS] and [SEC-IPS].
4. References 4. Normative References
[DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC [DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, Bucknell University, March 1997. 2131, Bucknell University, March 1997.
[iSCSI] Satran, J., et al., "iSCSI", Internet draft (work in [RFC2026] Bradner, S., "The Internet Standards Process --
progress), draft-ietf-ips-iSCSI-13.txt, June 2002 Revision 3", BCP 9, RFC 2026, October 1996
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997
5. Non-Normative References
[iFCP] Monia, C., et al., "iFCP - A Protocol for Internet Fibre [iFCP] Monia, C., et al., "iFCP - A Protocol for Internet Fibre
Channel Storage Networking", Internet draft (work in Channel Storage Networking", Internet draft (work in
progress), draft-ietf-ips-ifcp-11.txt, May 2002 progress), draft-ietf-ips-ifcp-13.txt, May 2002
[iSCSI] Satran, J., et al., "iSCSI", Internet draft (work in
progress), draft-ietf-ips-iSCSI-15.txt, August 2002
[iSNS] Tseng, J. et al., "iSNS - Internet Storage Name [iSNS] Tseng, J. et al., "iSNS - Internet Storage Name
Service", Internet draft (work in progress), draft-ietf- Service", Internet draft (work in progress), draft-ietf-
ips-isns-10.txt, May 2002 ips-isns-12.txt, August 2002
DHCP Option Number for iSNS February 2002
[SEC-IPS] Aboba, B., et al., "Securing IP Block Storage [SEC-IPS] Aboba, B., et al., "Securing IP Block Storage
Protocols", draft-ietf-ips-security-13.txt, June 2002 Protocols", draft-ietf-ips-security-14.txt, June 2002
Internet Storage Name Service (iSNS) November 2001
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997
5. Author's Addresses 6. Author's Addresses
Kevin Gibbons,
Charles Monia,
Josh Tseng Josh Tseng
Nishan Systems Nishan Systems
3850 North First Street 3850 North First Street
San Jose, CA 95134-1702 San Jose, CA 95134-1702
Phone: (408) 519-3749 Phone: (408) 519-3700
Email: jtseng@nishansystems.com Email: cmonia@nishansystems.com
Internet Storage Name Service (iSNS) November 2001 jtseng@nishansystems.com
kgibbons@nishansystems.com
Full Copyright Statement Full Copyright Statement
"Copyright (C) The Internet Society (date). All Rights Reserved. "Copyright (C) The Internet Society August 2002. All Rights
This document and translations of it may be copied and furnished to Reserved. This document and translations of it may be copied and
others, and derivative works that comment on or otherwise explain it furnished to others, and derivative works that comment on or
or assist in its implementation may be prepared, copied, published otherwise explain it or assist in its implementation may be
and distributed, in whole or in part, without restriction of any prepared, copied, published and distributed, in whole or in part,
kind, provided that the above copyright notice and this paragraph without restriction of any kind, provided that the above copyright
are included on all such copies and derivative works. However, this notice and this paragraph are included on all such copies and
document itself may not be modified in any way, such as by removing derivative works. However, this document itself may not be modified
the copyright notice or references to the Internet Society or other in any way, such as by removing the copyright notice or references
Internet organizations, except as needed for the purpose of to the Internet Society or other Internet organizations, except as
developing Internet standards in which case the procedures for needed for the purpose of developing Internet standards in which
copyrights defined in the Internet Standards process must be case the procedures for copyrights defined in the Internet Standards
followed, or as required to translate it into languages other than process must be followed, or as required to translate it into
English. languages other than English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
Internet Storage Name Service (iSNS) November 2001
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/