< draft-kempf-srvloc-notify-04.txt		draft-kempf-srvloc-notify-05.txt >
	Service Location James Kempf		A new Request for Comments is now available in online RFC libraries.
	INTERNET DRAFT Sun Microsystems
	September 15, 2000 Jason Goldschmidt
	Bucknell University
	Notification and Subscription for SLP
	draft-kempf-srvloc-notify-04.txt
	Status of This Memo
	This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026. Internet-Drafts are work-
	ing documents of the Internet Engineering Task Force (IETF), its
	areas, and its working groups. Note that other groups may also dis-
	tribute working documents as Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six
	months and may be updated, replaced, or obsoleted by other documents
	at any time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at:
	http://www.ietf.org/ietf/1id-abstracts.txt
	The list of Internet-Draft Shadow Directories can be accessed at:
	http://www.ietf.org/shadow.html.
	Abstract
	The Service Location Protocol 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.
	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 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 Overview
	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.
	As a result, SAs perform notification when they come on line and
	when 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, or advertisements that are not of interest because the
	attributes don't match attributes in which the UA is interested).
	The design requires SAs to perform notification by IP multicasting
	(or broadcasting if multicast is not available) one or several SLP
	SrvReg or SrvDereg messages using the multicast transmit algorithm
	described in Section 9.0. The multicast is performed on the SLP
	multicast address (239.255.255.253, default TTL 255) and is
	administratively scoped in the same manner as SLP [4]. 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 <*to be assigned by IANA*>. UAs interested in
	notification join the multicast group 239.255.255.253 and listen on
	port <*to be assigned by IANA*>.
	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 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 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, the DA compares the service type
	and scopes in the new subscription against a list of existing
	subscriptions. If no previous subscription was seen having the same
	service type and scopes, the DA multicasts DAAdverts using the multi-
	cast transmit algorithm described in Section 9.0 including the
	NotifyAt extension. A subscription consists of a service
	type and a collection of scopes. 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. If a subscription request
	is made which matches an existing request, the DA does not perform
	the multicast NotifyAt, but it does inform new SAs having a service
	type and scopes corresponding to the subscription. It does so by
	including the NotifyAt in the the reply to their registrations.
	The NotifyAt that is multicast when a subscription has not been
	seen before informs existing SAs that a UA has requested a subscription
	to events involving their service type. If the service type and scopes
	match a registration when an SA registers with the DA, the NotifyAt
	MUST be included in the SrvAck. The SrvAck MUST be included whenever a
	SrvReg matching a subscription is received. If the SAs don't support
	notification, they simply ignore the extension. 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.
	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.
	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 = <TBD> | 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]. 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 or simple type in the SrvRqst.
	When a DA receives a Subscribe extension for a scopes/service type
	combination that it has not previously seen and the extension is not a
	resubscription from an existing subscriber, it determines the multicast
	addresses to use based on the algorithm described in Section 8.0.
	The multicast addresses are then bundled into a NotifyAt along with
	the scopes and service type. The DA also includes a lifetime in the
	NotifyAt, informing subscribing UAs and notifying SAs how long the
	subscription is active. The lifetime is included to prevent old
	subscriptions from hanging around after the UA making the subscription
	has exited. The NotifyAt is then multicast as part of a DAAdvert
	according to the multicast transmission algorithm, and is included in
	the SrvRply to the requesting UA.
	If the scopes/service type have previously been seen, the DA does
	not perform immediate multicast, but waits until new SAs register,
	because all existing SAs have been informed of the subscription
	previously.
	The DA itself is required to perform notification if a service
	advertisement times out. This informs the UA that the service
	advertisement is no longer valid.
	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 = <TBD> | 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 \
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	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, in IPv4 dotted decimal notation. The following ABNF [5]
	syntax describes the list:
	sglist = sgitem / sgitem "," sglist
	sgitem = scope-name ":" ipv4-number
	sccope-name = ; See RFC 2608 for the format of scope names.
	ipv4-number = 1*3DIGIT 3("." 1*3DIGIT)
	An example of a scope/group list is:
	eng:239.255.255.42,corp:239.255.255.43
	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 concrete instances of 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. A DA that receives
	a subscription 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 with the abstract type flag not set,
	the DA MUST NOT include the abstract type, but rather must include
	the concrete type name. If the type name in the SrvRqst is a simple
	type, then the abstract type flag in the Subscribe extension MUST
	be ignored.
	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
	<*to be assigned by IANA*>. The UA MAY also want to note the expiration
	lifetime of the 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 transmit 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 multicast 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.
	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 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 is 239.1.0.42 and for service type Y in scope B is 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
	once, or at most, a very few times, backing off exponentially in time.
	Subsequent multicasts of notification have progressively smaller TTLs.
	The TTL on each retransmission is divided by the corresponding number
	in the sequence 16, 8, 2, so that the sequence of TTLs is 255, 16, 2, 1
	with 4 messages.
	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 transmitting
	agent 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.
	A DA also multicasts a DAAdvert when a subscription comes in for
	containing a service type and scopes that do not match any on the
	DA's list of known subscriptions. The same algorithm should 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. Multiple DAAdvert messages MUST NOT be
	multicast. 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.
	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.
	To avoid missing subscriptions from UAs that do not subscribe with
	all DAs, DAs MUST track notification messages in the scopes they
	support. To avoid multiple multicast NotifyAt messages, a DA MUST wait
	a random amount of time, uniformly distributed between 0 and 3 seconds
	before they send 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.
	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 prior to the expiration
	of the old one, and so the SA is informed to continue notifying.
	Note that this procedure still does not inform SAs that come up before
	the UA has renewed its subscription with a 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 the 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.
	13. 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.
	14. References
	[1] E. Guttman, C. Perkins, J. Veizades, and M. Day.
	Service Location Protocol.
	RFC 2608, July 1999.
	[2] S. Bradner.
	Key Words for Use in RFCs to Indicate Requirement Levels.
	RFC 2119, March 1997.
	[3] E. Guttman, C. Perkins, J. Kempf
	Service Templates and service: Schemes.
	RFC 2609, July 1999.
	[4] D. Meyer.		RFC 3082
	Administratively Scoped IP Multicast.
	RFC 2365, July 1998.
	[5] D. Crocker and P. Overell.		Title: Notification and Subscription for SLP
	Augmented BNF for Syntax Specifications: ABNF.		Author(s): J. Kempf, J. Goldschmidt
	RFC 2234, November 1997.		Status: Experimental
			Date: March 2001
			Mailbox: james.kempf@sun.com, jason.goldschmidt@sun.com
			Pages: 14
			Characters: 33410
			Updates/Obsoletes/SeeAlso: None
	[6] Hanna, S., B. Patel, M. Shah		I-D Tag: draft-kempf-srvloc-notify-05.txt
	Multicast Address Dynamic Client Allocation Protocol (MADCAP).
	draft-ietf-malloc-madcap-XX.txt, A work in progress.
	[7] http://www.iana.org/in-notes/iana/assignments/multicast-addresses		URL: ftp://ftp.rfc-editor.org/in-notes/rfc3082.txt
	15. Full Copyright Statement}
	Copyright (C) The Internet Society (1997). All Rights Reserved.		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.
	This document and translations of it may be copied and furnished to		This memo defines an Experimental Protocol for the Internet community.
	others, and derivative works that comment on or otherwise explain it		It does not specify an Internet standard of any kind. Discussion and
	or assist in its implementation may be prepared, copied, published and		suggestions for improvement are requested. Distribution of this memo
	distributed, in whole or in part, without restriction of any kind,		is unlimited.
	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		This announcement is sent to the IETF list and the RFC-DIST list.
	revoked by the Internet Society or its successors or assigns.		Requests to be added to or deleted from the IETF distribution list
			should be sent to IETF-REQUEST@IETF.ORG. Requests to be
			added to or deleted from the RFC-DIST distribution list should
			be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.
	This document and the information contained herein is provided on an		Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
	"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING		an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body
	TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING		help: ways_to_get_rfcs. For example:
	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."
	16. Author's Addresses		To: rfc-info@RFC-EDITOR.ORG
			Subject: getting rfcs
	James Kempf Jason Goldschmidt		help: ways_to_get_rfcs
	Sun Microsystems C0318 Bucknell University
	UMPK15-214 Lewisburg, PA, 17837
	901 San Antonio Rd. USA
	Palo Alto, CA 94040
	USA
	Phone: +1 650 786 5890 +1 570 577 5624		Requests for special distribution should be addressed to either the
	Email: james.kempf@sun.com jgoldsch@acm.org		author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless
			specifically noted otherwise on the RFC itself, all RFCs are for
			unlimited distribution.echo
			Submissions for Requests for Comments should be sent to
			RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC
			Authors, for further information.
End of changes. 12 change blocks.
	591 lines changed or deleted		37 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/