Subject: SLP iSCSI: Rationale behind the SLP draft (long)

From: Mark Bakke <[email-masked]>
Date: Fri, 16 Mar 2001 10:42:45 -0600

I just sent this to the IP Storage reflector, to explain the
rationale behind using SLP for discovering iSCSI targets.

I am sending it to this list in case some of it provides useful
feedback.  I apologize for using the bandwidth if it does not.

The drafts are all referenced, however, I don't think that they
are required reading for this.  The biggest weakness we see in
SLP right now is the fact that it does not have a way to
propagate changes in certain attributes, such as if we add a 
new initiator to a target's access list, it would be nice to notify
the initiator to go discover the target.

iSNS is another protocol that appears to have been created using
SLP's message structure and authentication blocks as a base.  It
does not do simple multicast discovery; it provides more of a
centralized management system for initiators and targets.  It is
quite feasible that simpler implementations would need only SLP,
and a larger setup might use iSNS to manage anything, so this
was an attempt to put some perspective on the similarities and
differences between the two, and where they might be used.

I also included a list of other discovery mechanism at the end,
along with a feeble attempt to show why we didn't pursue them
instead.

Regards,

Mark

Anyway, here's the article:

David Black has requested that I send something to the
list showing the rationale behind the SLP draft, including
its fit in the big picture and its relationship with iSNS.
Here's an attempt to do so.  I believe it to be consistent
with the Naming & Discovery, iSNS, and iSCSI/SLP drafts,
and their IETF-50 presentations.

The relevant drafts are:

  draft-ietf-ips-iSCSI-name-disc-00
  draft-ietf-ips-isns-00
  draft-bakke-iscsi-slp-00

Naming and Discovery Requirements

These are the discovery and name services requirements
from draft-ietf-ips-iscsi-name-disc-00.  From a discovery
requirements point-of-view, SLP and iSNS provide some
similar services.  SLP provides very simple discovery services
for smaller networks; iSNS provides more comprehensive
management services for larger networks.  Where they overlap,
SLP and iSNS can interoperate fairly easily.

1. Multicast method to discover targets, to allow zero-
   configuration of initiators and targets.

   SLP provides this.

2. A method to look up a WWUI, and get one or more addresses.
   "Where is target <wwui>?"

   SLP and iSNS both provide this.

3. A method to find targets that a given initiator should access.
   "I am initiator <wwui>; which targets should I access?"

   SLP and iSNS both provide this.

4. Ability to limit discovery to relevant initiators and targets.

   iSNS uses Discovery Domain, which are used to limit which initiators 
   and targets can discover each other.  Each target and initiator
   belong to Discovery Domain; the iSNS will not allow initiators to
   discover targets outside their domain.

   SLP uses a named Scope.  Each target and initiator is configured
   with one or more scope names; a target will only respond to an
   initiator who has a matching scope.  Note that this is not a
   security mechanism; an initiator can ask for any scope it wishes,
   and a target can respond to any scope it wishes.  This provides
   a simple mechanism to limit discovery, but does not attempt to
   provide security.
   
5. Access Lists by initiator WWUI

   SLP and iSNS both provide the ability to store a list of initiator
   WWUIs that are allowed access to a given target.

6. iSCSI Object Model support

   SLP registers only the targets
   iSNS registers targets, initiators, network entities, portals

7. TLV Message Format

   SLP and iSNS both do this.  However, SLP uses a text key and
   value for its attributes; iSNS uses a binary key value.

8. Authentication of discovery messages

   iSNS uses SLP's authentication mechanism

9. Registration and Query

   SLP registers targets only
   iSNS registers targets, inititors, network entities, portals

10. State Change Notification

   iSNS provides a state change service for which entities can
   register.

   SLP does not provide state change or event notification.  There
   is a draft on doing some notification, but it is not adequate for
   propagating attribute changes, which are necessary for an
   initiator to discover that it has gained (or lost) access to
   a target, or that a target has added a new address.

11. Light-weight Protocol

   Neither protocol should be too much of a burden to implement.

   Adding authentication to the protocol can be done later, and will be
   the same effort for both.  In the case that both SLP and iSNS are
   supported in the same product, they can share the code for this
   feature.

12. Compatibility with Boot Requirements

   Both the SLP template and the iSNS specification have worked to
   ensure that they fit in with the boot requirements.

   SLP has defined DHCP options that allow it to locate a directory
   agent, avoiding multicast traffic from initiators in a DHCP
   environment.

13. Compatibility with LDAP

   Although this is not a requirement, we have seen the desire for
   interworking with LDAP discussed on the list enough that it may
   merit a requirement at some point.  Both SLP and iSNS are designed
   with LDAP compatibility in mind.

14.  Entity Status Inquiry/Heartbeat

  iSNS provides an ESI/heartbeat ping message to monitor the
  availability of initiators and targets.  The heartbeat is
  originated by the iSNS server.

  We have not defined this capability for SLP.  It may be possible
  to do something similar if targets advertise themselves with a
  shorter lifetime, and initiators expire their discovered targets
  appropriately.  Adding a directory agent (DA) may be required for
  this to work properly.

15.  Distribution of X.509v3 Public Key certificates
  
  iSNS provides this capability.

  Our SLP template does not attempt to do this for two reasons:

    - SLP attributes are strings; the binary certificates would have
      to be escaped or uuencoded.

    - iSCSI only registers targets; there is no way for targets
      to discover an initiator's certificate.

16. Usage of Multicast

  SLP normally relies on multicast, for initiators to request
  advertisements from targets.  Multicast use can be eliminated
  at the expense of adding a DA, and configuring its address on
  each of the initiators and targets.
  
  iSNS does not use multicast.

We had originally started out looking for something to fulfill the
multicast requirements that iSNS did not do.  However, we found that
if one already had SLP, it was just as easy to find individual
targets, or at least canonical targets using it as it was to locate
an iSNS service.  SLP can then be used to handle discovery for
simpler host and device environments, and iSNS could be added later
to help manage these environments.      

SLP and iSNS both fulfill many of the requirements from
the naming & discovery draft.  However, they don't completely
overlap, and they take two different approaches to discovery.

SLP provides Discovery of Targets.

  SLP is used for discovery ONLY.  It uses a distributed
  model, that can start with initiators and targets, and
  no directory servers.  It can add Directory Agents to
  scale to medium-sized environments and reduce or eliminate
  the use of multicast.  Some work is underway on mesh-
  enhanced SLP (mSLP), which provides peer-to-peer information
  exchange between DAs for larger environments.  

  From a pure discovery point of view, SLP's chief weakness
  is that it does not yet have a notification mechanism.

  - Discovery of iSCSI targets
  - Discovery of iSNS services
  - Multicast-optional discovery mechanism for targets and
    other name services.
  - Open source implementations
  - Existing standard protocols

iSNS provides Centralized Management of Initiators and Targets.

  In addition to target discovery, iSNS provides higher-level
  functions such as centralized access management, active
  monitoring, public-key certificate management, and state-change 
  notifications.

  - Discovery of iSCSI targets
  - Centralized management of initiator and target access
  - Active monitoring of initiators and targets
  - State change notification

Using SLP with iSNS

Although SLP and iSNS solve several of the same problems, they
are fairly well-suited to interoperating.  They share a common
authentication structure, which is not something one would want
to code twice.  SLP can be used to do basic discovery where
configuring an iSNS server is not warranted, and can help
discover iSNS servers in environments where centralized management
is needed.  It is relatively simple for an iSNS server to
provide a proxy SLP service agent on behalf of the targets it
manages, allowing initiators to participate that implement only
the basic SLP.  Similarly, an iSNS server can work with gateways
to provide its services for targets that support only SLP.

When initiators and targets support BOTH SLP and iSNS, there
are a few rules that should be followed:

1. Initiators can use both SLP and iSNS concurrently to discover
   their targets.  In fact, an initiator should be able to use
   more than one iSNS, if it is accessing storage from two
   different providers.  This allows an initiator to discover
   its locally-managed devices using SLP, and its centrally-
   managed devices using iSNS.

2. Targets should be advertised using a single discovery method.
   A target should be advertised either with SLP, or with a
   single iSNS environment.  Targets discovered multiple ways
   would probably not break anything, but a target discovered
   via multiple services could produce conflicting information
   to the initiator.

3. Gateways or iSCSI proxies can be used to provide local SLP
   discovery of targets that are managed using iSNS.

Implementation Approach

I recommend a three-phase approach to implementing iSCSI
naming and discovery.  The first phase is to simply support the
WWUIs, and their use with the iSCSI protocol, and allow static
configuration of hosts and targets.  The second is to support
SLP for simple discovery.  This should be relatively quick to 
implement, as the source for SLP is readily available.  The third
would be to support iSNS as a storage management capability.

1. Simple naming and configuration

  - Admins configure targets with some form of access list, which
    may include the initiator WWUIs that are supposed to access
    them.

  - Admins configure initiators with the canonical target "iscsi"
    for targets that may provide them services.

  - Initiators use the SendTargets text command to discovery their
    targets.  This eliminates configuring target WWUIs in the
    initiator.

2. SLP for multicast and simple discovery

  - Instead of configuring initiators with target addresses, admins
    enable SLP on the initiator.

  - Targets also enable SLP, and are discovered by the initiators.

3. iSNS for centralized management

  - Initiators and targets are configured to be managed by an iSNS
    service.

  - Admins configure both hosts and targets from the iSNS server.

  - Initiators and targets use the iSNS protcol to discover each other.

Other Discovery Protocols

  There are several other discovery protocols; each has its
  strengths and weaknesses.  Here are some of them.  Take a look
  at "Building Networks on the Fly", IEEE Spectrum, March 2001
  for more information on these.

1. DNS SRV Records - these seemed too limiting, and there did
   not seem to be much point in making DNS do more.  The SLP
   folks started their work because DNS SRV records didn't meet
   their requirements.

2. LDAP, with an appropriate schema defined, could handle iSCSI
   registrations and queries, and distribute essentially the
   same information as SLP.  There are three reasons we didn't
   go directly to LDAP:

   1. LDAP would require a heavier implementation than SLP
   2. LDAP would not solve the multicast requirements
   3. SLP is built to be compatible with LDAP; SLP can be used
      by iniators and targets, with LDAP as a back-end database.
      This is left as an exercise for the implementor.

3. Jini is controlled by a single company, and is tied to a
   particular programming language, which is not appropriate
   for an internet standard.

4. UPnP from Microsoft is based on XML data with an HTTP transport.
   XML has a lot of merit for application interfaces like these, but
   the code for XML and HTTP could be a bit heavy for a really simple
   device.  It's company-controlled anyway, so we can't use it.

5. Salutation - Have not explored this in depth.  Salutation has
   been around longer than the other protocols.  It is made to be
   more flexible; it does not assume IP.

6. Bluetooth, HAVi - These are done by controlled-membership
   organizations, and are designed for specific non-IP environments.

-- 
Mark A. Bakke
Cisco Systems
[email-masked]
763.398.1054

Subject: iSCSI: Rationale behind the SLP draft
From: Mark Bakke <[email-masked]>
To: IPS <[email-masked]>
Date: Thu, 15 Mar 2001 15:04:52 -0600

David Black has requested that I send something to the
list showing the rationale behind the SLP draft, including
its fit in the big picture and its relationship with iSNS.
Here's an attempt to do so.  I believe it to be consistent
with the Naming & Discovery, iSNS, and iSCSI/SLP drafts,
and their IETF-50 presentations.

The relevant drafts are:

  draft-ietf-ips-iSCSI-name-disc-00
  draft-ietf-ips-isns-00
  draft-bakke-iscsi-slp-00

Naming and Discovery Requirements

These are the discovery and name services requirements
from draft-ietf-ips-iscsi-name-disc-00.  From a discovery
requirements point-of-view, SLP and iSNS provide some
similar services.  SLP provides very simple discovery services
for smaller networks; iSNS provides more comprehensive
management services for larger networks.  Where they overlap,
SLP and iSNS can interoperate fairly easily.

1. Multicast method to discover targets, to allow zero-
   configuration of initiators and targets.

   SLP provides this.

2. A method to look up a WWUI, and get one or more addresses.
   "Where is target <wwui>?"

   SLP and iSNS both provide this.

3. A method to find targets that a given initiator should access.
   "I am initiator <wwui>; which targets should I access?"

   SLP and iSNS both provide this.

4. Ability to limit discovery to relevant initiators and targets.

   iSNS uses Discovery Domain, which are used to limit which initiators 
   and targets can discover each other.  Each target and initiator
   belong to Discovery Domain; the iSNS will not allow initiators to
   discover targets outside their domain.

   SLP uses a named Scope.  Each target and initiator is configured
   with one or more scope names; a target will only respond to an
   initiator who has a matching scope.  Note that this is not a
   security mechanism; an initiator can ask for any scope it wishes,
   and a target can respond to any scope it wishes.  This provides
   a simple mechanism to limit discovery, but does not attempt to
   provide security.
   
5. Access Lists by initiator WWUI

   SLP and iSNS both provide the ability to store a list of initiator
   WWUIs that are allowed access to a given target.

6. iSCSI Object Model support

   SLP registers only the targets
   iSNS registers targets, initiators, network entities, portals

7. TLV Message Format

   SLP and iSNS both do this.  However, SLP uses a text key and
   value for its attributes; iSNS uses a binary key value.

8. Authentication of discovery messages

   iSNS uses SLP's authentication mechanism

9. Registration and Query

   SLP registers targets only
   iSNS registers targets, inititors, network entities, portals

10. State Change Notification

   iSNS provides a state change service for which entities can
   register.

   SLP does not provide state change or event notification.  There
   is a draft on doing some notification, but it is not adequate for
   propagating attribute changes, which are necessary for an
   initiator to discover that it has gained (or lost) access to
   a target, or that a target has added a new address.

11. Light-weight Protocol

   Neither protocol should be too much of a burden to implement.

   Adding authentication to the protocol can be done later, and will be
   the same effort for both.  In the case that both SLP and iSNS are
   supported in the same product, they can share the code for this
   feature.

12. Compatibility with Boot Requirements

   Both the SLP template and the iSNS specification have worked to
   ensure that they fit in with the boot requirements.

   SLP has defined DHCP options that allow it to locate a directory
   agent, avoiding multicast traffic from initiators in a DHCP
   environment.

13. Compatibility with LDAP

   Although this is not a requirement, we have seen the desire for
   interworking with LDAP discussed on the list enough that it may
   merit a requirement at some point.  Both SLP and iSNS are designed
   with LDAP compatibility in mind.

14.  Entity Status Inquiry/Heartbeat

  iSNS provides an ESI/heartbeat ping message to monitor the
  availability of initiators and targets.  The heartbeat is
  originated by the iSNS server.

  We have not defined this capability for SLP.  It may be possible
  to do something similar if targets advertise themselves with a
  shorter lifetime, and initiators expire their discovered targets
  appropriately.  Adding a directory agent (DA) may be required for
  this to work properly.

15.  Distribution of X.509v3 Public Key certificates
  
  iSNS provides this capability.

  Our SLP template does not attempt to do this for two reasons:

    - SLP attributes are strings; the binary certificates would have
      to be escaped or uuencoded.

    - iSCSI only registers targets; there is no way for targets
      to discover an initiator's certificate.

16. Usage of Multicast

  SLP normally relies on multicast, for initiators to request
  advertisements from targets.  Multicast use can be eliminated
  at the expense of adding a DA, and configuring its address on
  each of the initiators and targets.
  
  iSNS does not use multicast.

We had originally started out looking for something to fulfill the
multicast requirements that iSNS did not do.  However, we found that
if one already had SLP, it was just as easy to find individual
targets, or at least canonical targets using it as it was to locate
an iSNS service.  SLP can then be used to handle discovery for
simpler host and device environments, and iSNS could be added later
to help manage these environments.      

SLP and iSNS both fulfill many of the requirements from
the naming & discovery draft.  However, they don't completely
overlap, and they take two different approaches to discovery.

SLP provides Discovery of Targets.

  SLP is used for discovery ONLY.  It uses a distributed
  model, that can start with initiators and targets, and
  no directory servers.  It can add Directory Agents to
  scale to medium-sized environments and reduce or eliminate
  the use of multicast.  Some work is underway on mesh-
  enhanced SLP (mSLP), which provides peer-to-peer information
  exchange between DAs for larger environments.  

  From a pure discovery point of view, SLP's chief weakness
  is that it does not yet have a notification mechanism.

  - Discovery of iSCSI targets
  - Discovery of iSNS services
  - Multicast-optional discovery mechanism for targets and
    other name services.
  - Open source implementations
  - Existing standard protocols

iSNS provides Centralized Management of Initiators and Targets.

  In addition to target discovery, iSNS provides higher-level
  functions such as centralized access management, active
  monitoring, public-key certificate management, and state-change 
  notifications.

  - Discovery of iSCSI targets
  - Centralized management of initiator and target access
  - Active monitoring of initiators and targets
  - State change notification

Using SLP with iSNS

Although SLP and iSNS solve several of the same problems, they
are fairly well-suited to interoperating.  They share a common
authentication structure, which is not something one would want
to code twice.  SLP can be used to do basic discovery where
configuring an iSNS server is not warranted, and can help
discover iSNS servers in environments where centralized management
is needed.  It is relatively simple for an iSNS server to
provide a proxy SLP service agent on behalf of the targets it
manages, allowing initiators to participate that implement only
the basic SLP.  Similarly, an iSNS server can work with gateways
to provide its services for targets that support only SLP.

When initiators and targets support BOTH SLP and iSNS, there
are a few rules that should be followed:

1. Initiators can use both SLP and iSNS concurrently to discover
   their targets.  In fact, an initiator should be able to use
   more than one iSNS, if it is accessing storage from two
   different providers.  This allows an initiator to discover
   its locally-managed devices using SLP, and its centrally-
   managed devices using iSNS.

2. Targets should be advertised using a single discovery method.
   A target should be advertised either with SLP, or with a
   single iSNS environment.  Targets discovered multiple ways
   would probably not break anything, but a target discovered
   via multiple services could produce conflicting information
   to the initiator.

3. Gateways or iSCSI proxies can be used to provide local SLP
   discovery of targets that are managed using iSNS.

Implementation Approach

I recommend a three-phase approach to implementing iSCSI
naming and discovery.  The first phase is to simply support the
WWUIs, and their use with the iSCSI protocol, and allow static
configuration of hosts and targets.  The second is to support
SLP for simple discovery.  This should be relatively quick to 
implement, as the source for SLP is readily available.  The third
would be to support iSNS as a storage management capability.

1. Simple naming and configuration

  - Admins configure targets with some form of access list, which
    may include the initiator WWUIs that are supposed to access
    them.

  - Admins configure initiators with the canonical target "iscsi"
    for targets that may provide them services.

  - Initiators use the SendTargets text command to discovery their
    targets.  This eliminates configuring target WWUIs in the
    initiator.

2. SLP for multicast and simple discovery

  - Instead of configuring initiators with target addresses, admins
    enable SLP on the initiator.

  - Targets also enable SLP, and are discovered by the initiators.

3. iSNS for centralized management

  - Initiators and targets are configured to be managed by an iSNS
    service.

  - Admins configure both hosts and targets from the iSNS server.

  - Initiators and targets use the iSNS protcol to discover each other.

Other Discovery Protocols

  There are several other discovery protocols; each has its
  strengths and weaknesses.  Here are some of them.  Take a look
  at "Building Networks on the Fly", IEEE Spectrum, March 2001
  for more information on these.

1. DNS SRV Records - these seemed too limiting, and there did
   not seem to be much point in making DNS do more.  The SLP
   folks started their work because DNS SRV records didn't meet
   their requirements.

2. LDAP, with an appropriate schema defined, could handle iSCSI
   registrations and queries, and distribute essentially the
   same information as SLP.  There are three reasons we didn't
   go directly to LDAP:

   1. LDAP would require a heavier implementation than SLP
   2. LDAP would not solve the multicast requirements
   3. SLP is built to be compatible with LDAP; SLP can be used
      by iniators and targets, with LDAP as a back-end database.
      This is left as an exercise for the implementor.

3. Jini is controlled by a single company, and is tied to a
   particular programming language, which is not appropriate
   for an internet standard.

4. UPnP from Microsoft is based on XML data with an HTTP transport.
   XML has a lot of merit for application interfaces like these, but
   the code for XML and HTTP could be a bit heavy for a really simple
   device.  It's company-controlled anyway, so we can't use it.

5. Salutation - Have not explored this in depth.  Salutation has
   been around longer than the other protocols.  It is made to be
   more flexible; it does not assume IP.

6. Bluetooth, HAVi - These are done by controlled-membership
   organizations, and are designed for specific non-IP environments.

-- 
Mark A. Bakke
Cisco Systems
[email-masked]
763.398.1054

---

From: James Kempf <[email-masked]>
Date: Fri, 16 Mar 2001 09:50:53 -0800 (PST)

Mark,

>I have not seen RFC 3082; it is not available from either the
>ietf.org or networksorcery.com.  Do you have a copy you could
>sent me?
>

As I mentioned in my previous email, it has probably not made the
RFC directory yet because I was just notified on Tues. that I
had two days to make any last minute changes. In advance of
it being released, it is attached. I do not believe there
is any problem with my distributing it to you early,  as 
I made no changes in it.

>iSNS is a draft proposed by a storage networking startup called
>Nishan Systems.  I am listed as an author as well, but all I
>did was help with the iSCSI data model several months back.
>Its intent is to provide centralized management of storage;
>however, I want to use SLP for environments that need only
>discovery.
>

Well this sounds to me like the typical story with service discovery:

	- Working group/company/... designs protocol
	
	- Discovers that they need some way of finding server/network element
	implementing protocol
	
	- Designs their own service discovery protocol
	
	- Somebody comes along who knows about SLP and presents a good
	case for using it
	
	- Working group/company/.... insists that their application is
	so special and unique that a general purpose protocol such
	as SLP could not *possibly* satisfy the requirements
	
I'll try to attend the meeting on Wed. and I can give you some support,
but all I can say is: good luck. 

		jak

Network Working Group                                           J. Kempf
Request for Comments: 3082                                J. Goldschmidt
Category: Experimental                                  Sun Microsystems
                                                              March 2001

                 Notification and Subscription for SLP

Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  It does not specify an Internet standard of any kind.
   Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Abstract

   The Service Location Protocol (SLP) provides mechanisms whereby
   service agent clients can advertise and user agent clients can query
   for services.  The design is very much demand-driven, so that user
   agents only obtain service information when they specifically ask for
   it.  There exists another class of user agent applications, however,
   that requires notification when a new service appears or disappears.
   In the RFC 2608 design, these applications are forced to poll the
   network to catch changes.  In this document, we describe a protocol
   for allowing such clients to be notified when a change occurs,
   removing the need for polling.

1. Introduction

   The Service Location Protocol (SLP) [1] provides a mechanism for
   service agent (SA) clients to advertise network services and for user
   agent (UA) clients to find them.  The mechanism is demand-driven.
   UAs obtain service information by actively querying for it, and do
   not obtain any information unless they do so.  While this design
   satisfies the requirements for most applications, there are some
   applications that require more timely information about the
   appearance or disappearance in the services of interest.

   Ideally, these applications would like to be notified when a new
   service comes up or when a service disappears.  In order to obtain
   this information with SLP as described in RFC 2608, such applications
   must poll the network to periodically refresh their local cache of
   available service advertisements.

Kempf & Goldschmidt           Experimental                      [Page 1]

RFC 3082         Notification and Subscription for SLP        March 2001

   An example of such a client is a desktop GUI that wants to display
   network service icons as soon as they appear to provide users with an
   accurate picture of all services available to them.

   Because polling is inefficient and wasteful of network and processor
   resources, we would like to provide these applications a mechanism
   whereby they can be explicitly notified of changes.  In this
   document, we describe a scalable mechanism allowing UAs to be
   notified of changes in service availability.

2. Notation Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [2].

3. Terminology

   In this section, we present some additional terminology beyond that
   in [1] and [3].

   Notification - A message sent to an interested agent informing that
                  agent that a service has appeared or disappeared.

   Subscription - A request to be informed about changes in service
                  availability for a particular service type and scopes.

4. Design Considerations

   The primary design consideration in a notification protocol for SLP
   is that we would like it to exhibit the same high degree of
   scalability and robustness that the base SLP protocol exhibits.
   Notification should work in small networks with only a few SAs, as
   well as large enterprise networks with thousands of SAs and hundreds
   of DAs.  Small networks should not be required to deploy DAs in order
   to receive the benefits of notification.  We also want to assure that
   notification in large networks does not cause heavy processing loads
   to fall on any one particular SLP agent.  This requires that the task
   of notification be distributed rather than centralized, to avoid
   loading down one agent with doing all the notification work.
   Finally, we would like the notification scheme to be robust in the
   face of DA failures, just as the base SLP design is.

   An important consideration is that the UA clients obtain
   notifications of SA events in a timely fashion.  If a UA has
   subscribed to notification for a particular service type, the UA
   should receive such notification regardless of the state of
   intervening DAs.  SLP is transparent with respect to DAs supporting a

Kempf & Goldschmidt           Experimental                      [Page 2]

RFC 3082         Notification and Subscription for SLP        March 2001

   particular scope; that is, a UA can use any DA with a particular
   scope and expect to get the same service advertisements.
   Notifications should exhibit the same property.  Whether or not a UA
   receives a notification should not depend on the DA to which they
   happen to connect. This preserves the DAs' identity as a pure cache.

   Another goal is that the notification messages contain enough
   information about the triggering event that the UA can determine
   whether or not it is of interest in the large majority of cases
   without having to issue another SLP request a priori.  The UA may, of
   course, issue an SLP request for related reasons, but it should not
   have to issue a request to obtain more information on the event that
   triggered the notification in most cases.  This reduces the amount of
   network traffic related to the event.

   In order to simplify implementation, we would like to use similar
   mechanisms for notification in large and small networks.  The
   mechanisms are not identical, obviously, but we want to avoid having
   radically different mechanisms that require completely separate
   implementations.  Having similar mechanisms reduces the amount of
   code in UA and SA clients.

   A minor goal is to make use of existing SLP message types and
   mechanisms wherever possible.  This reduces the amount of code
   necessary to implement the notification mechanism, because much code
   can be reused between the base SLP and the notification mechanism.
   In particular, we expect to make use of the SLP extension mechanism
   in certain cases to support subscription.

5. Notification Design Description

   In order to support scalability, we split the design into two parts.
   A small network design is used when no DAs are present in the
   network.  A large network design is used in networks with DAs.  The
   following subsections describe the two designs.

5.1 Small Network Design

   In networks without DAs, UAs are notified by an SA when the SA
   initially appears, and when the SA disappears.  This allows UAs to
   know about the list of service types the SA supports.  In small
   networks, there is no centralized agent available to administer
   subscriptions for newly appearing SAs.  This rules out any kind of
   subscription design in which a UA subscribes to notifications for a
   particular service type in particular scopes of interest, because a
   newly appearing SA can't tell whether or not there are any
   subscriptions without a centralizing agent to tell it.

Kempf & Goldschmidt           Experimental                      [Page 3]

RFC 3082         Notification and Subscription for SLP        March 2001

   As a result, SAs perform notification when they come on line and
   prior to shutting down regardless of their scope or service type, if
   they are capable of performing notification.  This means that a UA
   receives notification of all types of changes for all scopes and
   service types, and consequently must be prepared to filter out those
   changes in which it is not interested (other scopes, other service
   types).

   The design requires SAs to perform notification by IP multicasting
   (or broadcasting in IPv4 if multicast is not available) SLP SrvReg or
   SrvDereg messages using the multicast transmit algorithm described in
   Section 9.0.  The port number for notifications is not the default
   SLP port, because that port is only accessible to privileged users on
   some operating systems, but rather the port 1847, as assigned by
   IANA.

   In IPv4, the SA performs multicast on the SLP multicast address
   (239.255.255.253, default TTL 255) and is administratively scoped in
   the same manner as SLP [4].  IPv4 UAs interested in notification join
   the multicast group 239.255.255.253 and listen on port 1847.  In
   IPv6, the multicast is performed to the scoped IPv6 addresses for the
   service type advertised, as described in [8].  The SA advertises on
   all addresses up to and including the largest multicast scope that it
   supports.  IPv6 UAs interested in notification join the multicast
   groups corresponding to the multicast scopes and service type in
   which they are interested and listen on port 1847.  For example, an
   IPv6 UA that has access to site local scope and is interested in a
   service type whose hash is 42, calculated according to the algorithm
   in [8], joins the groups FF01:0:0:0:0:0:10042 through
   FF05:0:0:0:0:0:10042.

5.2 Large Network Design

   In networks with DAs, a DA supporting a particular scope can act as
   an intermediary for administering UA subscriptions.  A subscription
   consists of a service type and a collection of scopes.  A UA
   interested in being notified about changes in a particular service
   type attaches the Subscribe extension to a SrvRqst message sent to
   the DA.  The DA obtains multicast group addresses for notification
   based on the algorithm described in Section 8.0 and puts them into a
   NotifyAt extension which it attaches to the SrvRply.  The UA listens
   on the group addresses in the reply for notifications.

   When a new subscription comes in, existing SAs are informed about the
   subscription using the following procedure.  The DA compares the
   service type and scopes in the new subscription against a list of
   existing subscriptions.  If no previous subscription has the same
   service type and scopes, the DA MUST multicast a DAAdvert, using the

Kempf & Goldschmidt           Experimental                      [Page 4]

RFC 3082         Notification and Subscription for SLP        March 2001

   multicast transmit algorithm described in Section 9.0, and MUST
   include the NotifyAt extension with the multicast group addresses for
   notification.  If an existing subscription covers the same service
   type and scopes as the new subscription, the DA MUST NOT multicast a
   DAAdvert.

   A DA MUST keep track of subscriptions it has arranged as well as
   subscriptions arranged by other DAs in any scopes with which the DA
   is configured.  To avoid multiple multicast NotifyAt messages, a DA
   MUST wait a random amount of time, uniformly distributed between 0
   and 3 seconds before sending the multicast DAAdvert with NotifyAt.
   During this period, the DA MUST listen for NotifyAt messages that
   match the one from the new subscription.  If a matching NotifyAt is
   detected, the DA MUST not multicast.

   When a new SA registers with a DA that has existing subscriptions,
   the new SA is informed of notifications it should perform using the
   following procedure.  If the service type and scopes in the new SA's
   SrvReg messages match an existing subscription, a NotifyAt containing
   the multicast addresses for notification MUST be included in the
   SrvAck.  If the SA doesn't support notification, it simply ignores
   the extension.  If the service type and scopes in the new SA's SrvReg
   do not match any existing subscriptions, the DA MUST NOT include a
   NotifyAt.

   The DA itself MUST also perform notification, according to the
   multicast transmit algorithm, when a service advertisement times out.
   Time-out of a service advertisement results in the DA multicasting a
   SrvDereg for the deregistered URL.  This allows interested UAs to be
   informed of the service advertisement's demise even if the SA has
   disappeared without deregistering.  A DA MUST NOT perform
   notification when it receives a SrvReg from an SA, however, that is
   the job of the SA.

   As in small networks, notification is performed primarily by SAs.  If
   an SA receives a DAAdvert or SrvAck with a NotifyAt extension and the
   following conditions are met:

           1. The SA supports notification.

           2. The SA's service type matches the service type in the
              NotifyAt extension.

           3. The SA's scopes match one of the scopes of the NotifyAt
              extension.

Kempf & Goldschmidt           Experimental                      [Page 5]

RFC 3082         Notification and Subscription for SLP        March 2001

   then the SA saves the multicast addresses that correspond to the
   scopes and service types it supports.  The SA MUST perform
   notification immediately after the SA has performed the SrvReg or
   SrvDereg with the DA.  An SA that has detected a DA in its scopes
   MUST NOT multicast any notifications unless it receives a NotifyAt
   extension in a SrvAck with service type and scopes matching the SA's
   service type and scopes.

6. Subscribe Extension

   The Subscribe extension has the following format:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Extension Type = 0x0004    |        Extension Length       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Ex. Len. (ct) | Abs. Type Fl. |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The scope list and service type of the extension are taken from the
   accompanying SrvRqst.  The abstract type flag indicates whether the
   UA is interested in hearing from all SAs advertising concrete
   instances of an abstract type [3], and is only of interest if the
   service type in the SrvRqst is a concrete type.  If the flag is 1,
   the UA is interested in hearing from all SAs advertising concrete
   types having the same abstract type as the type of the SrvRqst.  If
   the flag is 0, the UA is only interested in hearing from SAs
   supporting the particular concrete type in the SrvRqst.  If the
   service type in the accompanying SrvRqst is not a concrete type, the
   flag is ignored.

7. NotifyAt Extension

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Extension Type = 0x0005    |        Extension Length       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Ext. Len (ct) |  Subscription Lifetime        |SGL List Len.  \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |SGL L. Len (ct)|       Scope/Group List                        \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Length of Service Type Name  |        Service Type Name      \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Kempf & Goldschmidt           Experimental                      [Page 6]

RFC 3082         Notification and Subscription for SLP        March 2001

   The service type name is in the same format as in the SrvRqst.  The
   scope/group list is a list of scope names and multicast group
   addresses.  The following ABNF [5] syntax describes the list:

        sglist          = sgitem / sgitem "," sglist
        sgitem          = scope-name ":" ip-addr
        ip-addr         = ipv4-number | ipv6-number
        scope-name      =  ; See RFC 2608 for the format of scope names.
        ipv4-number     =  1*3DIGIT 3("." 1*3DIGIT)
        ipv6-number     = ;See RFC 2373 [9] Section 2.2

   An example of a scope/group list for IPv4 is:

        eng:239.255.255.42,corp:239.255.255.43

   An example of a scope/group listfor IPv6 is:

        eng:FF02:0:0:0:0:0:1:1042,corp:FF03:0:0:0:0:0:1:1042

   The scope/group list gives the multicast addresses to use for
   notifications involving the service type for the given scopes.

   The service type name can be a simple type name, an abstract type
   name, or a concrete type name.  If the name is an abstract type name,
   all SAs advertising the abstract type MUST notify.  If the name is a
   concrete or simple type name, ONLY those SAs advertising the simple
   or concrete type MUST notify, others MUST NOT notify.  A DA that
   receives a subscription for a concrete type with the abstract type
   flag set, MUST include the abstract type name in all the NotifyAt
   messages it sends.  If the DA receives a subscription for a concrete
   type with the abstract type flag not set, the DA MUST NOT include the
   abstract type, but rather MUST include the concrete type name.

   There are three cases in which an agent may receive a NotifyAt
   extension: in a SrvRply returned to a UA, in a multicast DAAdvert,
   and in a SrvAck returned to an SA.  The three subsections below
   describe the response in each of these cases.

7.1 NotifyAt received with SrvRply

   When a UA sends a SrvRqst with a Subscribe extension, the DA responds
   with a SrvRply including a NotifyAt.  The DA MUST NOT unicast a
   NotifyAt to a UA with any other message and MUST NOT send a NotifyAt
   unless a SrvRqst with a Subscribe extension was received.

   The UA responds by setting up a multicast listener to the group
   addresses included in the extension on the SLP notification port
   1847.  The UA MAY also want to note the expiration lifetime of the

Kempf & Goldschmidt           Experimental                      [Page 7]

RFC 3082         Notification and Subscription for SLP        March 2001

   subscription assigned by the DA, and reissue a  subscription before
   the lifetime expires.

7.2 NotifyAt received with Multicast DAAdvert

   The DA multicasts a NotifyAt with a DAAdvert using the multicast
   transmit algorithm when a UA has requested notification and the
   scopes and service type in the subscription were not previously seen.
   This message informs existing SAs having the service type and scopes
   in the announcement that they should multicast notifications when
   they shut down.

   A receiving SA participating in notification responds by noting the
   multicast address if the service type and scopes match.  When the SA
   is about to go down, the SA MUST first unicast a SrvDereg without
   attribute tag list to its DAs (as per standard SLP), then it MUST
   multicast the same SrvDereg message according to the multicast
   transmit algorithm.  The SA MUST cease performing notification when
   the subscription lifetime expires, unless a subsequent NotifyAt is
   received prolonging the subscription.

   A UA that is performing passive DA detection will naturally also
   receive the extension, but the UA SHOULD ignore the extension.

7.3 NotifyAt received with SrvAck

   An SA can receive a NotifyAt with a SrvAck when it first comes up and
   registers itself with a DA.  If the DA has any subscriptions from UAs
   for the service type and scopes represented by the SA, it MUST return
   a NotifyAt with the SrvAck.

   The SA upon receiving the NotifyAt immediately multicasts the same
   SrvReg it sent to the DA, according to the multicast transmit
   algorithm.  The SA MUST only perform the multicast algorithm once,
   even if it registers with more than one DA and receives the NotifyAt
   in reply from more than one.  Prior to its demise and after
   deregistering with a DA, the SA MUST notify with the same SrvDereg,
   as described in Section 7.2.

8. Multicast Address Allocation

   Enterprise networks that allow SLP notification SHOULD deploy the
   Multicast Address Allocation Architecture (MAAA) including
   administratively scoped multicast and Multicast Address Dynamic
   Client Allocation Protocol (MADCAP) [6].

   If it is not possible to obtain a multicast address for use in SLP
   notifications, the SLP multicast address is used.

Kempf & Goldschmidt           Experimental                      [Page 8]

RFC 3082         Notification and Subscription for SLP        March 2001

   If the MAAA infrastructure is deployed, DAs and SAs obtain their
   scope configuration from MADCAP, because the SLP scopes are the same
   as the MADCAP scopes.  Each SLP scope MUST correspond to a multicast
   scope name, in the sense of [6].  In such a case, a DA allocates,
   using MADCAP, a new multicast group address for each new service
   type/scope pair to which a UA subscribes.  The allocation is made by
   MADCAP from the multicast address range for the scope.  In this way,
   only those UAs interested in the service type and scopes in the
   subscription receive the multicast notification.  The DA sets up the
   lease on the multicast address to correspond with the duration of the
   subscription.  If the MADCAP server runs out of addresses, the SLP
   multicast group is used as a last resort.

   For example, if the multicast scope has an address range of 239.1.0.0
   through 239.1.255.255, the notification group address for service
   type X in scope A could be 239.1.0.42 and for service type Y in scope
   B could be 239.1.42.42.

9. Multicast Transmit Algorithm

   The DA and SAs use a multicast transmit algorithm similar to that
   used for discovering services in SLP, described in RFC 2608 [1],
   except the agent performing the notification doesn't wait for
   replies.  The agent performing the notification transmits a
   notification message repeatedly over a period of 15 seconds, backing
   off exponentially on the duration of the time interval between the
   multicasts.  The rationale for this algorithm is to limit the
   duration and scope of the multicast announcement while still
   repeating the announcement enough times to increase the probability
   that one message gets through.

   For an SA, a notification message is either a SrvReg or a SrvDereg
   message, depending on whether the SA is registering a new service or
   deregistering a service.  When a new service is registered, the
   SrvReg message MUST have the fresh bit set in the SLP header.  The
   entire list of attributes for the service SHOULD be included.  The
   SrvDereg message MUST NOT include an attribute tag list.
   Notifications MUST NOT be transmitted at any other time, to minimize
   multicast traffic.

   Since a SrvReg could contain attribute lists of arbitrary length, the
   message could potentially overflow the packet MTU for UDP.  If an
   attribute list causes a packet MTU overflow, the SA MUST set the
   overflow bit in the SLP header.  The attribute list in the
   notification message MUST be formatted so that a UA can use the
   attributes even if an overflow occurs.  If a UA needs more attributes
   than are transmitted in the notification message, it can contact the
   SA (if no DA is present) or the DA for the attributes it needs.

Kempf & Goldschmidt           Experimental                      [Page 9]

RFC 3082         Notification and Subscription for SLP        March 2001

   A DA multicasts a DAAdvert when a subscription comes in containing a
   service type and scopes that do not match any on the DA's list of
   known subscriptions.  The same algorithm MUST be used.  If the
   combination of the DA attributes and the NotifyAt message cause the
   DAAdvert to overflow a UDP packet, DA attributes MUST be truncated to
   allow the NotifyAt to fit and the overflow bit MUST be set in the
   header.  An SA knows that the purpose of the message is to inform it
   of a new subscription rather than for passive advertisement, because
   of the extension, and it can therefore ignore the DA attribute list
   field if the overflow bit is set in the header.  A DA also transmits
   a SrvDereg message when a service advertisement is deregistered due
   to timeout, following the same rules as for an SA.

10.0 DA Disappearance

   Robustness to DA failure is an important goal of the design.  When a
   DA disappears due to unforeseen circumstances, subscription
   information from UAs is lost.  UAs continue to get notifications from
   existing SAs.  However, new SAs will not be informed of the
   subscription unless other DAs also have the subscription information.
   Because a UA may not discover a new DA until it tries to perform an
   active request, the UA could potentially miss the appearance of new
   services.  For this reason, UAs that are concerned about receiving
   notification of absolutely every service that appears SHOULD issue
   subscriptions to every newly discovered DA that supports the scopes
   it supports.  Similarly, if a DA disappears through controlled
   shutdown, a UA performing passive discovery can detect the shutdown
   and reissue the subscription to an alternate DA.

   On the SA side, when a DA goes down, existing SAs continue to notify
   until the subscription expires.  Before ceasing to notify, an SA MUST
   determine whether the DA is still active and, if not, verify with
   another DA whether the subscription has been extended.  If no other
   DA is available, the SA MUST ignore the subscription expiration time
   and continue notifying until a new DA is discovered.  When a new DA
   is discovered the SA must send a new SrvReg to the DA, according to
   RFC 2608 [1].  The replying SrvAck contains a NotifyAt extension if
   the UA has renewed its subscription with the DA.  If the SrvAck does
   not contain a NotifyAt message the SA MUST continue to notify until
   the subscription expires.  If a UA is interested in continuing the
   notification, it renews the subscription with the new DA prior to the
   expiration  of the old one, and so the SA is informed to continue
   notifying.

Kempf & Goldschmidt           Experimental                     [Page 10]

RFC 3082         Notification and Subscription for SLP        March 2001

   Note that this procedure still does not inform SAs that come up
   between the time a newly booted DA comes up and the time the UA has
   renewed its subscription with the newly booted DA.  If this situation
   is of concern, multiple DAs can be used to assure that all
   subscriptions are covered when a DA goes down.

11.  Network Administration Considerations

   In SLP networks with DAs as described in RFC 2608, the only multicast
   is the SrvRqst for DAAdverts performed during active DA discovery,
   and unsolicited DAAdverts sent periodically by the DA for passive
   discovery.  There is no multicast involved in UA queries or SA
   registrations.  This allows network administrators to set up DAs for
   a particular collection of IP subnets and confine all service
   discovery traffic to unicast between the SA and UA clients and the
   DA.  Administratively scoped multicast can additionally be used to
   limit the extent of active DA discovery and passive DA advertising.
   The amount of multicast involved is not high and DHCP DA and scope
   configuration can be used to limit which DAs a particular UA or SA
   client sees, or to inhibit multicast entirely so that UAs and SAs
   only use configured DAs.

   With notification, however, multicast traffic involving events in SAs
   becomes available.  Because DAs request multicast addresses based on
   scope and service type, the multicast associated with particular
   events should only propagate to those subnets in which UAs and SAs of
   the same scope are interacting.  Routers should be configured with
   administrative multicast scoping to limit multicast.  If DAs are not
   deployed (or the MAAA is not deployed), however, the amount of
   multicast on the SLP multicast address when notifications are being
   used could quickly become very large.  Therefore, it is crucial that
   DAs supporting notification be deployed in large networks where UA
   clients are interested in notification.

12. Security Considerations

   The SrvReg and SrvDereg messages contain authentication blocks for
   all SLP SPIs supported by the DAs with which the SA registers.  Since
   these SPIs are necessarily the same as those that UAs can verify, a
   UA receiving a multicast notification is in a position to verify the
   notification.  It does so by selecting the authentication block or
   blocks that it can verify.  If authentication fails, either due to
   lack of an authentication block, or lack of the proper SPI, the UA
   simply discards the notification.  In a network without DAs, the SPIs
   of the UA and SA must also match.

Kempf & Goldschmidt           Experimental                     [Page 11]

RFC 3082         Notification and Subscription for SLP        March 2001

13. IANA Considerations

   The SLP Notification services use the IANA-assigned port number of
   1847.  The SLP extension identifiers assigned by IANA are 0x0004 for
   Subscribe and 0x0005 for NotifyAt.

14. Acknowledgements

   The authors would like to thank Charles Perkins, of Nokia, and Erik
   Guttman and Jonathan Wood, of Sun Microsystems, for their stimulating
   discussion and suggestions during the initial phases of the
   subscription/notification design.  We would also like to thank Erik
   for his intense scrutiny of the specification during the later
   phases.  His comments were instrumental in refining the design.
   Shivaun Albright, of HP, motivated simplification of the protocol to
   focus on initial registration and deregistration only.  Vaishali
   Mithbaokar implemented the simplified protocol.

15. References

   [1] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service
       Location Protocol", RFC 2608, July 1999.

   [2] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement
       Levels", BCP 14, RFC 2119, March 1997.

   [3] Guttman, E., Perkins, C. and J. Kempf, "Service Templates and
       service: Schemes", RFC 2609, July 1999.

   [4] Meyer, D., "Administratively Scoped IP Multicast", RFC 2365, July
       1998.

   [5] Crocker, D. and P. Overell, "Augmented BNF for Syntax
       Specifications: ABNF", RFC 2234, November 1997.

   [6] Hanna, S., Patel,B. and M. Shah, "Multicast Address Dynamic
       Client Allocation Protocol (MADCAP)", RFC 2730, December 1999.

   [7] http://www.isi.edu/in-notes/iana/assignments/multicast-addresses

   [8] Guttman, E., "Service Location Protocol Modifications for IPv6",
       Work in Progress.

   [9] Hinden, R. and S. Deering, "IP Version 6 Addressing
       Architecture", RFC 2375, July 1997.

Kempf & Goldschmidt           Experimental                     [Page 12]

RFC 3082         Notification and Subscription for SLP        March 2001

16. Author's Addresses

   James Kempf
   Sun Microsystems
   UMPK15-214
   901 San Antonio Rd.
   Palo Alto, CA 94040
   USA

   Phone:    +1 650 786 5890
   EMail:    [email-masked]

   Jason Goldschmidt
   Sun Microsystems
   UMPK17-202
   901 San Antonio Rd.
   Palo Alto, CA 94040
   USA

   Phone: +1 650 786 3502
   EMail: [email-masked]

Kempf & Goldschmidt           Experimental                     [Page 13]

RFC 3082         Notification and Subscription for SLP        March 2001

Full Copyright Statement

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Kempf & Goldschmidt           Experimental                     [Page 14]