Finding Stuff BOF (Michael Mealing & Erik Guttman, Chairs)
42nd IETF Monday 13:00 Reported by Ted Hardie (hardie@nasa.gov)
Mailing list: findstuff@lists.internic.net
Subscription requests:
Write to listserv@lists.internic.net with SUBSCRIBE FINDSTUFF in the body of
the message.
The BOF was held to discuss the need for a document describing current technology
and practice related to searching, lookups, and discovery. The chairs proposed that
such a document would need to main sections one identifying current mechanisms
and one describing their applicability. The chairs stressed that the task could only
succeed if it avoided discussions of general requirements, new protocols, or the
relative ranking of different protocols.
As a precursor to the discussion, Erik and Patrik Falstrom presented a brief glossary
of terms:
Discovery: used in bootstrap situations where there is no a priori information;
commonly based on broadcast or mutlicast protocols; sometimes based on solitication
(active) or advertisement (passive). Discovery may also be seen as unbounded, in that
it may not be possible to tell when the complete set of replies or advertisements has
been heard
Lookup: used when a key is known and a service is available to render information
related to that key. The DNS is the best current example-the name is the key and the
hierarchy of DNS servers provide a mechanism for returning information based on
the key.
Search: an attempt to find services or data when only partial information about them
and their location is available. Searches are the most problematic case, especially
when done globally. Searches are often considered successful when they return a key
which allows for a lookup.
During discussions about the need for a taxonomy of protocols available for discovery,
lookup, and search, two needs were identified: the need to provide working groups
looking for a search technology accurate information on the mechanisms currently
available and the need to map elements from one protocol into other protocols. In
both cases, identifying the scope of particular protocols and mechanisms was seen as
critical to success, as was avoiding using that discussion of scope to rank the protocols.
The group identified the following issues as elements of the applicability statements
needed:
- Purpose (search/lookup/discovery)
- Scalability
- Administration issues
- Configuration requirements
- Network services are required?
- Security:
- Authentication
- Access Control
- Update rate
- Data state information maintained
Protocols Covered:
WWWseeker: (Ryan Moats) WWWseeker is a centralized database which maps
organizational information to domain names; draft-rfced-info-moats-01.txt discusses
maintaining the centralized database. 3 million domains in the current version--last
updated in April 1998. Supports SVR for finding websites; supports whois, rwhois
and could support whois++. Search engine is perl/cgi; it and last database are freely
available at
http://blackhole.vip.att.net/wwwseeker/; contact jayhawk@att.com
for the elements which are only available for non-commercial use.
LDAP: (Mark Wahl): LDAP is intended primarily for search and lookup, not discovery.
Its general model is a tree-based hierarchy; most deployments are single server or small
islands of servers; information is loaded through administrative action (update possible).
Static information traditional; there has been recent work on dynamic entries---change
notification mechanism and timeouts (LDAP-ext). LSD is looking at interconnects
between LDAP servers and at locating LDAP servers.
SRV RR (Paul Vixie). SRV allows you to identify a protocol and a domain name and
get the names of servers, the ports on which they are available, their relative
"weights", etc. . Original applicability statement said that it could be rolled out with a
release of software which used SRV records instead of A records (getaddrinfo instead
of getaddr). SRV is now in BIND, Microsoft's DNS code, and Cisco's DNS code. Paul
is adamant that SRV remain an access method which maintains the DNS as a coherent
distributed database and strongly opposes any changes which might return different
answers to the same query based on location, language, or any other non-chronological
characteristic.
SLP: (Erik Guttman) Described in RFC2165, SLP provides discovery; it can also
provide search and registration. The data it handles is highly dynamics, commonly
changing in seconds. SLP provides no server to server protocol. It can scale to a
single administration (size and use of network administration implies single
administration; similar for naming). It is not a general purpose directory scheme.
SLPv2 is LDAPv3 friendly; both v1 and v2 also can use DHCP. SLP works in the
absence of other protocols.
SDP/SAP: (Eve Scholer): SAP is the Session Announcement Protocol; SDP is the
Session Description Protocol. SDP describes the audio and video streams which,
combined, form a multimedia session. SAP is used to announce the availability of
specific sessions. It's current is in MBONE tools like sdr. It is fully distributed and
scales to any number of passive listeners; it does not scale to any number of
announcers, however, as increasing the number of announers increases the period at
which individual sessions are announced. It has few configuration requirements. The
data with which it works is transient, but not highly dynamic. Multicast network
services must be available for SAP and SDP to function.
RVP/GENA: (Sonu Agganwal) (Rendezvous Event Protocol/Generalize Event
Notification Architecture) These protocols propose a method for event subscriptions
and notifications by extending HTTP with new methods: subsribe, unsubscribe,
notify, and poll. They also propose new headers in HTTP:
- Subscription-ID
- Notification-Type
- Delivery-Control
- Call-back
Multiple delivery mechanisms may be used, and they can be layered on tcp or udp.
RVP uses WEBDAV to extend GENA; in it, individuals have properties. Properties
are text/xml type. Its proposers believe it might be applied to: status tracking; location
discovery; general notification; instant messages. Each resources is url-based;
obtaining initial url outside of current protocol.
URN (Michael Mealing): URNs meant to name things; resolving those names into
something is another problem (URN creates a key for lookup). URN needs a way to
lookup for rules of syntax of URNs. Resolver discovery system based on the DNS;
uses a lookup of rule based on a key. Applicability: Meant to scale to global; meant
to be perrsistent--never allow reassignment.
Rwhois(Michael Mealing): tried to solve a problem the Internic had with hierarchical
spaces; based on dns names. Meant to scale globally (used for IP addresses and
domain names contacts).
Whois++(Michael Mealing): trying to solve a large, flat namespace problems in which
you might use a mesh to query route. Meant to scale globally.
ACAP; (Chris Newman). ACAP came out of the IMAP community. It allows user
configuration information and preferences to be stored on a central server, so that a
user can access from any allowed machine. It has no bootstrapping, but it does have
the facilities needed to manage large lists. Focused on concept that information on the
server is frequently updated, but owned by the user. Their may be administrative
defaults. Also has inheritence to provide admin defaults; some notification facilities
(RFC2244).
DASL: (Rajiv Dulepet) Searching related to DAV properties; still in early stages of
development, but searches are limited to specific namespaces, collections, or DAV
properties.
BOF Decisions and Action Items:
Documents providing a glossary and taxonomy of search, lookup, and discovery will
be written; Ned Freed, Ian King, Peter Reintjes volunteered to act as editors. Those
willing to describe the available protocols were seperately recorded.
The BOF felt it was not appropriate to charter a working group at this time.
None received