draft-ietf-ips-iscsi-slp-03.txt   draft-ietf-ips-iscsi-slp-04.txt 
Internet Draft Mark Bakke Internet Draft Mark Bakke
<draft-ietf-ips-iscsi-slp-03.txt> Cisco <draft-ietf-ips-iscsi-slp-04.txt> Cisco
Expires September 2002 Expires April 2003
Joe Czap Joe Czap
Jim Hafner Jim Hafner
John Hufferd John Hufferd
Kaladhar Voruganti Kaladhar Voruganti
IBM IBM
Howard Hall Howard Hall
Pirus Pirus
Jack Harwood Jack Harwood
EMC EMC
Yaron Klein Yaron Klein
Sanrad Sanrad
Marjorie Krueger Marjorie Krueger
HP HP
Lawrence Lamers Lawrence Lamers
San Valley Systems San Valley Systems
Todd Sperry Todd Sperry
Adaptec Adaptec
Joshua Tseng Joshua Tseng
Nishan Nishan
March 2002 October 2002
Finding iSCSI Targets and Name Servers Using SLP Finding iSCSI Targets and Name Servers Using SLP
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
skipping to change at page 3, line 17 skipping to change at page 3, line 17
Each of the above methods requires a small amount of configuration to Each of the above methods requires a small amount of configuration to
be done on each initiator. The ability to discover targets and name be done on each initiator. The ability to discover targets and name
services without having to configure initiators is a desirable services without having to configure initiators is a desirable
feature. The Service Location Protocol (SLP) [SLP] is an IETF feature. The Service Location Protocol (SLP) [SLP] is an IETF
standards track protocol that provides several features that will standards track protocol that provides several features that will
simplify locating iSCSI services. This document describes how SLP simplify locating iSCSI services. This document describes how SLP
can be used in iSCSI environments to discover targets, addresses can be used in iSCSI environments to discover targets, addresses
providing targets, and storage management servers. providing targets, and storage management servers.
This draft is a work in progress. Searching for the string "WORK" in
this document should find anything that is not considered to be
complete. The following items are still open:
- Should look into Erik Guttman's serviceid scheme [SVCID] as a
slight variation to our SLP template, and see what it would take to
implement it, and whether it would change APIs.
- Need to add RFC 3082 interaction. An initiator that is already up
and running must be notified within a reasonable amount of time
when a new target becomes available to it. This may be due to a
storage device booting, a network interface being added to the
device, a new target being created on the device, or the initiator
being added to the access-list of an existing device. Work is
under way to determine the best way to do this, either using the
experimental RFC 3082 or some modification thereof. Note that it
is a non-goal for SLP to notify an initiator when a target or one
of its service URLs is no longer accessible; the initiator will
find this out soon enough if it cares to attempt access to the
target. Note that RFC 3082 takes care of a device booting, adding
a new interface or target (and hence, a service URL), but not the
access-list change.
- Add comments about lifetime of URLs and how it is used. URLs are
registered with a finite lifetime. If the lifetime is too long, a
lot of stale URLs may hang around; if it is too short, SLP
participants will spend too much time re-registering the same old
URLs. There is a definite recommendation by the SLP folks to stick
with the default; I have to go look it up to see what it is.
- SLP can be set up to use either Unicast or Multicast. Add a
discussion on when to use each.
The following modifications have been made in draft-02: The following modifications have been made in draft-02:
- Removed the mgmt-ipaddress attribute from the template; if FQDN is - Removed the mgmt-ipaddress attribute from the template; if FQDN is
not available, the IP address may be returned in its place as a not available, the IP address may be returned in its place as a
dotted-decimal string. dotted-decimal string.
- Added example for finding targets that will allow access to any - Added example for finding targets that will allow access to any
initiator. initiator.
- Updated Security Considerations to reference the IP storage - Updated Security Considerations to reference the IP storage
skipping to change at page 9, line 26 skipping to change at page 8, line 26
target(s) it requires. target(s) it requires.
3. Once the UA has the host name or address of the iSCSI server 3. Once the UA has the host name or address of the iSCSI server
as well as the port number and iSCSI Target Name, it can begin the as well as the port number and iSCSI Target Name, it can begin the
normal iSCSI login to the target. normal iSCSI login to the target.
As information contained in the iSCSI target template may exceed As information contained in the iSCSI target template may exceed
common network datagram sizes, the SLP implementation for both UAs common network datagram sizes, the SLP implementation for both UAs
and SAs supporting this template MUST implement SLP over TCP. and SAs supporting this template MUST implement SLP over TCP.
5.1.1. Using SLP in a Non-Multicast Environment 5.1.1. Finding Targets Based on Initiator Credentials
To be allowed access to an iSCSI target, an initiator must be
authenticated. The initiator may be required by the target to
produce one or more of the following credentials:
- - An iSCSI Initiator Name
- - An IP address
- - A CHAP, SRP, or Kerberos credential
- - Any combination of the above
Most iSCSI targets allow access to only one or two initiators. In
the ideal discovery scenario, an initiator would send an SLP request,
and receive responses ONLY for those targets to which the initiator
is guaranteed a successful login. To achieve this goal, the iSCSI
target template contains the following attributes, each of which
allows a list of values:
1. auth-name - This attribute contains the list of initiator names
allowed to access this target, or the value "any", indicating
that no specific initiator name is required.
2. auth-addr - This attribute contains the list of host names
and/or IP addresses which will be allowed access to this target,
or the value "any", indicating that no specific address or
host name is required. If a large number of addresses is to
be allowed (perhaps a subnet), this attribute may contain the
value "any".
3. auth-cred - This attribute contains a list of "method/identifier"
credentials that will be allowed access to the target, provided
they can produce the correct password or other verifier during
the login process. If no specific credentials are required, the
value "any" is used.
The above identifiers follow the semantics described in the IP
Storage Authentication MIB [AUTH-MIB]. Examples showing initiator
searches based on auth-xxxx attributes are shown in the target-
specific template section below.
5.1.2. Supporting Access by Multiple Identities to the Same Target
If a target is to allow access to multiple host identities, more than
one combination of auth-xxxx attributes will need to be present.
Since service URLs must be unique, each of these must be registered
under its own service URL.
For systems that support the configuration of multiple identities to
access a target, the service URL must contain an additional, opaque
string defining the identity. This appears after the iSCSI name in
the URL string, and is separated by a "/". Each registered (target-
address, target-name, initiator-identity) tuple can then register its
own set of auth-xxxx attributes.
An initiator-identity is equivalent to the authentication identity
defined in [AUTH-MIB].
5.1.3. Using SLP in a Non-Multicast Environment
In some networks, the use of multicast for discovery purposes is In some networks, the use of multicast for discovery purposes is
either unavailable or not allowed. Such networks include public or either unavailable or not allowed. Such networks include public or
service-provider networks that are placed in between an iSCSI client service-provider networks that are placed in between an iSCSI client
and server; these are probably most common between two iSCSI and server; these are probably most common between two iSCSI
gateways, one at a storage service provider site, and one at a gateways, one at a storage service provider site, and one at a
customer site. customer site.
In these networks, an initiator may, instead or in addition to its DA In these networks, an initiator may, instead or in addition to its DA
configuration, allow the addresses of one or more SAs to be configuration, allow the addresses of one or more SAs to be
skipping to change at page 13, line 32 skipping to change at page 13, line 32
5.3. NAT and NAPT Considerations 5.3. NAT and NAPT Considerations
Since SLP provides IP address and TCP port information within its Since SLP provides IP address and TCP port information within its
payload, the addresses an SA or DA advertise may not be the same as payload, the addresses an SA or DA advertise may not be the same as
those a UA must use if a Network Address(/Port) Translation those a UA must use if a Network Address(/Port) Translation
(NAT/NAPT) device is present between the UA and the SA. This may (NAT/NAPT) device is present between the UA and the SA. This may
result in the UA discovering address information that is unusable. result in the UA discovering address information that is unusable.
Here are a few recommendations to handle this: Here are a few recommendations to handle this:
- Use a fully-qualified domain name instead of IP address in service - Use a fully-qualified domain name instead of IP address in service
URLs and in the mgmt-entity attribute. URLs, the mgmt-entity attribute, and the auth-addr attribute.
- Stick with the default, IANA-assigned iSCSI TCP port number in - Stick with the default, IANA-assigned iSCSI TCP port number in
service URLs, wherever possible. service URLs, wherever possible.
- If advertising service URLs through a NAT/NAPT device, and the - If advertising service URLs through a NAT/NAPT device, and the
FQDN, IP address, or TCP port will be translated, the NAT/NAPT FQDN, IP address, or TCP port will be translated, the NAT/NAPT
device can provide an SLP proxy capability to do the translation. device can provide an SLP proxy capability to do the translation.
5.4. Implementation Considerations
This section will answer common questions for those who are not too
familiar with SLP.
Where are the templates used? By the implementor; don't need to be
installed in a DA (not like a MIB).
Who makes use of the templates?
- Implementor of iSCSI host drivers / adapters / devices
- Network Administrator (DHCP and DA)
- Storage Administrator (DA and SA)
WORK - Integrating SLP DA or SA within a storage management server
WORK - When to use multicast and/or unicast
WORK - Using DHCP to bootstrap SLP discovery
6. iSCSI SLP Templates 6. iSCSI SLP Templates
Three templates are provided: an iSCSI target template, a management Three templates are provided: an iSCSI target template, a management
service template, and an abstract template to encapsulate the two. service template, and an abstract template to encapsulate the two.
6.1. The iSCSI Abstract Service Type Template 6.1. The iSCSI Abstract Service Type Template
This template defines the abstract service "service:iscsi". It is This template defines the abstract service "service:iscsi". It is
used as a top-level service to encapsulate all other iSCSI-related used as a top-level service to encapsulate all other iSCSI-related
services. services.
skipping to change at page 15, line 26 skipping to change at page 15, line 5
Service: service:iscsi:target Service: service:iscsi:target
Scope: initiator-scope-list Scope: initiator-scope-list
Query: (iscsi-name=iqn.2001-04.com.acme.sn.456) Query: (iscsi-name=iqn.2001-04.com.acme.sn.456)
2. Find all of the iSCSI Target Names that may allow access to a 2. Find all of the iSCSI Target Names that may allow access to a
given initiator: given initiator:
Service: service:iscsi:target Service: service:iscsi:target
Scope: initiator-scope-list Scope: initiator-scope-list
Query: (access-list=iqn.1998-03.com.os.hostid.045A7B) Query: (auth-name=iqn.1998-03.com.os.hostid.045A7B)
3. Find all of the iSCSI Target Names that may allow access to 3. Find all of the iSCSI Target Names that may allow access to
any initiator: any initiator:
Service: service:iscsi:target Service: service:iscsi:target
Scope: initiator-scope-list Scope: initiator-scope-list
Query: (access-list=iscsi) Query: (auth-name=any)
4. Find the iSCSI Target Names from which the given initiator is 4. Find all of the iSCSI Target Names that may allow access to
this initiator, or that will allow access to any initiator:
Service: service:iscsi:target
Scope: initiator-scope-list
Query: &(auth-name=iqn.1998-03.com.os.hostid.045A7B)
(auth-name=any)
5. Find all of the iSCSI Target Names that may allow access to
a given CHAP user name:
Service: service:iscsi:target
Scope: initiator-scope-list
Query: (auth-cred=chap/my-user-name)
6. Find all of the iSCSI Target Names that may allow access to
a given initiator that supports two IP addresses, a CHAP
credential and an SRP credential, and an initiator name:
Service: service:iscsi:target
Scope: initiator-scope-list
Query: &(|(auth-name=iqn.com.mydisk:host47)(auth-name=any)
|(auth-addr=10.1.1.47)(auth-addr=10.1.2.47)(auth-addr=any)
|(auth-cred=chap/foo)(auth-cred=srp/my-user-name)
(auth-cred=any))
7. Find the iSCSI Target Names from which the given initiator is
allowed to boot: allowed to boot:
Service: service:iscsi:target Service: service:iscsi:target
Scope: initiator-scope-list Scope: initiator-scope-list
Query: (boot-list=iqn.1998-03.com.os.hostid.045A7B) Query: (boot-list=iqn.1998-03.com.os.hostid.045A7B)
5. In addition, a management service may wish to discover all 8. In addition, a management service may wish to discover all
targets: targets:
Service: service:iscsi:target Service: service:iscsi:target
Scope: management-server-scope-list Scope: management-server-scope-list
Query: <empty-string> Query: <empty-string>
More details on booting from an iSCSI target are defined in [BOOT]. More details on booting from an iSCSI target are defined in [BOOT].
Name of submitter: Mark Bakke Name of submitter: Mark Bakke
Language of service template: en Language of service template: en
skipping to change at page 16, line 16 skipping to change at page 16, line 22
Template Text: Template Text:
-------------------------template begins here----------------------- -------------------------template begins here-----------------------
template-type=iscsi:target template-type=iscsi:target
template-version=0.1 template-version=0.1
template-description= template-description=
This is concrete service type. The iscsi:target service type is used This is concrete service type. The iscsi:target service type is used
to register individual target addresses to be discovered by others. to register individual target addresses to be discovered by others.
UAs will generally search for these by including one of the following: UAs will generally search for these by including one of the
following:
- the iSCSI target name - the iSCSI target name
- the iSCSI initiator name (must be in the access-list of the target) - iSCSI initiator identifiers (iSCSI name, credential, IP address)
- the service URL - the service URL
template-url-syntax= template-url-syntax=
url-path = ipaddr [ : tcpport ] / iscsi-name url-path = ipaddr [ : tcpport ] / iscsi-name [ / identity ]
ipaddr = DNS host name or ip address ipaddr = DNS host name or ip address
tcpport = decimal tcp port number tcpport = decimal tcp port number
iscsi-name = iSCSI target name iscsi-name = iSCSI target name
identity = optional initiator identity allowed to access target
; The iscsi-name part of the URL is required and must be the iSCSI ; The iscsi-name part of the URL is required and must be the iSCSI
; name of the target being registered. ; name of the target being registered.
; A device representing multiple targets must individually ; A device representing multiple targets must individually
; register each target/address combination with SLP. ; register each target/address combination with SLP.
; ;
; Example: ; Example:
; service:iscsi:target://10.1.3.40:5003/iqn.2001-04.com.acme.sn.45678 ; service:iscsi:target://10.1.3.40:5003/iqn.2001-04.com.acme.sn.45678
iscsi-name = string iscsi-name = string
# The iSCSI Name of this target. # The iSCSI Name of this target.
skipping to change at page 17, line 12 skipping to change at page 17, line 22
mgmt-entity = string O mgmt-entity = string O
# The fully qualified domain name, or IP address in dotted-decimal # The fully qualified domain name, or IP address in dotted-decimal
# notation, of the management interface of the entity containing # notation, of the management interface of the entity containing
# this target. # this target.
# #
alias = string O alias = string O
# The alias string contains a descriptive name of the target. # The alias string contains a descriptive name of the target.
access-list = string M auth-name = string M X
# A list of iSCSI Initiator Names that can access this target. # A list of iSCSI Initiator Names that can access this target.
# Normal iSCSI names will be 50 characters or less; max length is 255. # Normal iSCSI names will be 80 characters or less; max length
# is 255.
# Normally, only one or a few values will be in the list. # Normally, only one or a few values will be in the list.
# Using the equivalence search on this will evaluate to "true" # Using the equivalence search on this will evaluate to "true"
# if any one of the items in this list matches the query. # if any one of the items in this list matches the query.
# If this list contains the default name "iscsi", any initiator # If this list contains the default name "any", any initiator
# is allowed to access this target. # is allowed to access this target, provided it matches the
# other auth-xxx attributes.
auth-addr = string M X
# A list of initiator IP addresses (or host names) which will
# be allowed access to this target. If this list contains the
# default name "any", any IP address is allowed access to this
# target, provided it matches the other auth-xxx attributes.
auth-cred = string M X
# A list of credentials which will be allowed access to the target
# (provided they can provide the correct password or other
# authenticator). Entries in this list are of the form
# "method/identifier", where the currently defined methods are
# "chap" and "srp", both of which take usernames as their
# identifiers.
boot-list = string M O boot-list = string M O
# A list of iSCSI Initiator Names that can boot from this target. # A list of iSCSI Initiator Names that can boot from this target.
# This list works precisely like the access-list attribute. A name appearing # This list works precisely like the auth-name attribute. A name
# in this list must either appear in the access-list, or the # appearing in this list must either appear in the access-list,
# access-list must contain the initiator name "iscsi". Otherwise, an # or the access-list must contain the initiator name "iscsi".
# initiator will be unable to find its boot target. # Otherwise, an initiator will be unable to find its boot target.
# If boot-list contains the name "iscsi", any host can boot from it, # If boot-list contains the name "iscsi", any host can boot from it,
# but I am not sure if this is useful to anyone. # but I am not sure if this is useful to anyone.
# If this attribute is not registered, this target is not "bootable". # If this attribute is not registered, this target is not "bootable".
# #
# Note that the LUN the host boots from is not specified here; a # Note that the LUN the host boots from is not specified here; a
# host will generally attempt to boot from LUN 0. # host will generally attempt to boot from LUN 0.
# #
# It is quite possible that other attributes will need to be defined # It is quite possible that other attributes will need to be defined
# here for booting as well. # here for booting as well.
skipping to change at page 18, line 23 skipping to change at page 18, line 48
template-type=iscsi:sms template-type=iscsi:sms
template-version=0.1 template-version=0.1
template-description= template-description=
This is a concrete service type. The iscsi:sms service type This is a concrete service type. The iscsi:sms service type
provides the capability for entities supporting iSCSI to discover provides the capability for entities supporting iSCSI to discover
appropriate management services. appropriate management services.
template-url-syntax= template-url-syntax=
url-path = ; The URL of the management service. Defined in RFC 2608. url-path = ; The URL of the management service [RFC2608].
protocols = string M L protocols = string M
# The list of protocols supported by this name service. This # The list of protocols supported by this name service. This
# list may be expanded in the future. There is no default. # list may be expanded in the future. There is no default.
# #
# "isns" - This management service supports the use of the iSNS # "isns" - This management service supports the use of the iSNS
# protocol for access management, health monitoring, and # protocol for access management, health monitoring, and
# discovery management services. This protocol is defined # discovery management services. This protocol is defined
# in [ISNS]. # in [ISNS].
isns isns
--------------------------template ends here------------------------ --------------------------template ends here------------------------
7. Security Considerations 7. Security Considerations
Service type templates provide information that is used to interpret Service type templates provide information that is used to interpret
information obtained by clients through SLP. If the iSCSI templates information obtained by clients through SLPv2. If the iSCSI templates
are modified or if false templates are distributed, iSCSI targets and are modified or if false templates are distributed, iSCSI targets and
name servers may not correctly register themselves, or iSCSI clients name servers may not correctly register themselves, or iSCSI clients
may not be able to interpret service information. may not be able to interpret service information.
SLP provides an authentication mechanism for UAs to assure that The SLPv2 security model does not provide confidentiality, but does
service advertisments only come from trusted SAs [RFC2608]. If trust provide an authentication mechanism for UAs to assure that service
is an issue then SLP authentication should be enabled in the network. advertisements only come from trusted SAs [RFC2608].
Once a target or management server is discovered, authentication and Once a target or management server is discovered, authentication and
authorization are handled by the iSCSI protocol, or by the management authorization are handled by the iSCSI protocol, or by the management
server's protocol. It is the responsibility of the providers of server's protocol. It is the responsibility of the providers of
these services to ensure that an inappropriately advertised or these services to ensure that an inappropriately advertised or
discovered service does not compromise their security. discovered service does not compromise their security.
7.1. IPsec Integration 7.1. Security Implementation
Although SLPv2 security provides authentication, it does not provide For all implementations, IPsec SHOULD be implemented. When security
confidentiality. In many environments, confidentiality of discovery policy information distribution using SLPv2 is supported, IPsec MUST
information is important. For instance, the existence of a be implemented.
particular iSCSI target name within a building can indicate that
there is an expensive/important piece of equipment in there, and its
discovery information. This may provide enough information for an
attacker to attempt a denial-of-service or other attacks on the iSCSI
device.
SLPv2 authentication does not provide confidentiality of discovery To provide confidentiality, IPsec with ESP and a non-null transform
information. When this is a concern, in particular when SLPv2 is SHOULD be implemented. When security policy information distribution
used to distribute security policy information, IPsec MUST be used via SLPv2 is used, IPsec with ESP and a non-null transform MUST be
with SLPv2 when discovering iSCSI targets. When this is not a used.
concern, SLPv2 security MAY be implemented and used.
The use of IPsec and IKE for SLPv2 is described in [IPS-SEC], and is SLPv2 authentication is OPTIONAL to implement and use, and SLPv2
a work in progress. authentication SHOULD be implemented when IPsec is not supported.
The use of IPsec and IKE for SLPv2 in an IP storage environment is
described in [IPS-SEC].
8. Summary 8. Summary
This document describes how SLP can be used by iSCSI initiators to This document describes how SLP can be used by iSCSI initiators to
find iSCSI targets and storage management servers. Service type find iSCSI targets and storage management servers. Service type
templates for iSCSI targets and storage management servers are templates for iSCSI targets and storage management servers are
presented. presented.
9. References 9. Normative References
[RFC2608] E. Guttman, C. Perkins, J. Veizades, M. Day. "Service [RFC2608] E. Guttman, C. Perkins, J. Veizades, M. Day. "Service
Location Protocol, version 2", RFC 2608, July 1999. Location Protocol, version 2", RFC 2608, July 1999.
[RFC2609] E. Guttman, C. Perkins, J. Kempf. "Service Templates and [RFC2609] E. Guttman, C. Perkins, J. Kempf. "Service Templates and
service: Schemes", RFC 2609, July 1999. service: Schemes", RFC 2609, July 1999.
[RFC2119] S. Bradner. "Key Words for Use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[ISCSI] J. Satran, et. al. "iSCSI", draft-ietf-ips-iscsi-18.txt,
September 2002.
[IPS-SEC] B. Aboba, et. al., "Securing Block Storage Protocols over
IP",
draft-ietf-ips-security-16, September 2002.
10. Informative References
[RFC2614] J. Kempf, E. Guttman. "An API for Service Location", RFC [RFC2614] J. Kempf, E. Guttman. "An API for Service Location", RFC
2614, June 1999. 2614, June 1999.
[2614BIS] J. Kempf, E. Guttman. "An API for Service Location", draft- [2614BIS] J. Kempf, E. Guttman. "An API for Service Location", draft-
kempf-svrloc-rfc2614bis-00.txt, February 2002. kempf-svrloc-rfc2614bis-00.txt, February 2002.
[RFC2119] S. Bradner. "Key Words for Use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[RFC3082] J. Kempf, J Goldschmidt. "Notification and Subscription for
SLP", RFC 3082, March 2001.
[ISCSI] J. Satran, et. al. "iSCSI", draft-ietf-ips-iscsi-10.txt,
January 2002.
[SAM2] ANSI T10. "SCSI Architectural Model 2", March 2000. [SAM2] ANSI T10. "SCSI Architectural Model 2", March 2000.
[NDT] K. Voruganti, et. al. "iSCSI Naming and Discovery", draft- [NDT] M. Bakke et. al. "iSCSI Naming and Discovery", draft-ietf-
ietf-ips-iscsi-name-disc-05, March 2002. ips-iscsi-name-disc-08, September 2002.
[AUTH-MIB] M. Bakke, J. Muchow, "Definitions of Managed Objects for
User Identity Authentication", draft-ietf-ips-auth-
mib-02.txt, September 2002.
[ISNS] J. Tseng, et. al. "Internet Storage Name Service", [ISNS] J. Tseng, et. al. "Internet Storage Name Service",
draft-ietf-ips-isns-05, November 2001. draft-ietf-ips-isns-14, October 2002.
[BOOT] P. Sarkar, D. Missimer, C. Sapuntzakis. "A Standard for [BOOT] P. Sarkar, D. Missimer, C. Sapuntzakis. "A Standard for
Bootstrapping Clients using the iSCSI Protocol", Bootstrapping Clients using the iSCSI Protocol",
draft-ietf-ips-iscsi-boot-04, November 2001. draft-ietf-ips-iscsi-boot-07, October 2002.
[RFC3082] J. Kempf, J Goldschmidt. "Notification and Subscription for
SLP", RFC 3082, March 2001.
[RSIP] Kempf, J., Montenegro, G., "Finding an RSIP Server with [RSIP] Kempf, J., Montenegro, G., "Finding an RSIP Server with
SLP", draft-ietf-nat-rsip-slp-00, February 2000. SLP", draft-ietf-nat-rsip-slp-00, February 2000.
[IPS-SEC] B. Aboba, et. al., "Securing iSCSI, iFCP, and FCIP",
draft-ietf-ips-security-10, February 2002.
[SVCID] E. Guttman, "The serviceid: URL Scheme for Service
Location",
draft-guttman-svrloc-serviceid-01, January 2002.
Author's Address: Author's Address:
Mark Bakke Mark Bakke
Cisco Systems, Inc. Cisco Systems, Inc.
6450 Wedgwood Road 6450 Wedgwood Road
Maple Grove, MN Maple Grove, MN
USA 55311 USA 55311
Voice: +1 763-398-1000 Voice: +1 763-398-1000
E-Mail: mbakke@cisco.com E-Mail: mbakke@cisco.com
 End of changes. 

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