As per Relevance of the word services, we have this rfc below:
Network Working Group M.
Request For Comments: 1862 University of
Category: Informational J. Romkey,
M.
University of
K.
T.
C.
Bunyip Information Systems, Inc
November 1995
Report of the IAB Workshop on Internet Information Infrastructure
October 12-14, 1994
Status of this
This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited
This document is a report on an Internet architecture workshop
initiated by the IAB and held at MCI on October 12-14, 1994.
workshop generally focused on aspects of the
infrastructure on the Internet
1.
The Internet Architecture Board (IAB) holds occasional
designed to consider long-term issues and strategies for
Internet, and to suggest future directions for the
architecture. This long-term planning function of the IAB
complementary to the ongoing engineering efforts performed by
groups of the Internet Engineering Task Force (IETF), under
leadership of the Internet Engineering Steering Group (IESG) and
directorates
An IAB-initiated workshop on the architecture of the "
infrastructure" of the Internet was held on October 12-14, 1994
MCI in Tysons Corner, Virginia
In addition to the IAB members, attendees at this meeting
the IESG Area Directors for the relevant areas (Applications,
Services) and a group of other experts in the following areas
McCahill, et al Informational [Page 1]
RFC 1862 IAB Workshop Report November 1995
gopher, the World Wide Web, naming, WAIS, searching, indexing,
library services. The IAB explicitly tried to balance the number
attendees from each area of expertise. Logistics limited
attendance to about 35, which unfortunately meant that many
qualified experts were omitted from the invitation list
The objectives of the workshop were to explore the architecture
"information" applications on the Internet, to provide the IESG
a solid set of recommendations for further work, and to provide
place for communication between the communities of people
with the lower and upper layers of the Internet protocol suite,
well as allow experience to be exchanged between the communities
The 34 attendees divided into three "breakout groups" which met
the second half of the first day and the entire second day.
group wrote a report of its activities. The reports are contained
this document, in addition to a set of specific recommendations
the IESG and IETF community
2.
Although there were some disagreements between the groups on
functionalities for architectural components, there was
agreement on the general shape of an information architecture and
general principles for constructing the architecture. The
of the architecture generalized a number of concepts that
currently used in deployed systems such as the World Wide Web,
the main thrust was to define general architectural components
than focus on current technologies
Research recommendations include
- increased focus on a general caching and replication
- a rapid deployment of name resolution services,
- the articulation of a common security architecture for
applications
Procedural recommendations for forwarding this work in the
include
- making common identifiers such as the IANA assigned
available in an on-line
- tightening the requirements on Proposed Standards to insure
they adequately address
McCahill, et al Informational [Page 2]
RFC 1862 IAB Workshop Report November 1995
- articulating the procedures necessary to facilitate joining
working group meetings,
- reviewing the key distribution infrastructure for use
information
3. Group 1 report: The Distributed Database
Elise Gerich, Tim Berners-Lee, Mark McCahill, Dave Sincoskie,
Schwartz, Mitra, Yakov Rekhter, John Klensin, Steve Crocker,
Editors: Mark McCahill, Mike Schwartz, Ton
3.1 Problem and
Because of the increasing popularity of accessing
information, current Internet information services are
performance, reliability, and scaling problems. These are
problems, given the distributed nature of the Internet. Current
future applications would benefit from much more widespread use
caching and replication
For instance, popular WWW and Gopher servers experience
overloading, as many thousands of users per day attempt to
them simultaneously. Neither of these systems was designed
explicit caching or replication support in the core protocol
Moreover, because the DNS is currently the only widely
distributed and replicated data storage system in the Internet, it
often used to help support more scalable operation in
environment -- for example, storing service-specific
information, or providing a means of rotating service accesses
replicated copies of NCSA's extremely popular WWW server. In
cases, such uses of the DNS semantically overload the system.
DNS may not be able to stand such "semantic extensions" and
to perform well. It was not designed to be a general-
replicated distributed database system
There are many examples of systems that need or would benefit
caching or replication. Examples include key distribution
authentication services, DHCP, multicast SD, and Internet
pages
To date there have been a number of independent attempts to
caching and replication facilities. The question we address here
whether it might be possible to define a general service interface
protocol, so that caches and replica servers (implemented in
variety of ways to support a range of different situations)
McCahill, et al Informational [Page 3]
RFC 1862 IAB Workshop Report November 1995
interoperate, and so that we might reduce the amount of wasted re
implementation effort currently being expended. Replication
caching schemes could form a sort of network "middleware" to
a common need of distributed services
It should be noted that it is an open question whether it would
feasible to define a unified interface to all caching and
problems. For example, very different considerations must go
providing a system to support a nationwide video service
1,000,000 concurrent users than would be needed for
worldwide accesses to popular WWW pages. We recommend research
experimentation to address this more general issue
3.2 Characteristics of
While on the surface caching and replication may appear to occupy
ends of a spectrum, further analysis shows that these are
different approaches with different characteristics. There are
where a combination of the two techniques is the optimal solution
which further complicates the situation
We can roughly characterize the two approaches as follows
Caching
- a cache contains a partial set of
- a cache is built on
- a cache is audience-specific, since the cache is built
response to demands of a
Replication
- replicated databases contain the entire data set or
server-defined subset of a given
- a replicated database can return an authoritative answer
existence of an
- data is pushed onto the replicating server rather than pulled
While there are important differences between caches and
databases, there are some issues common to both, especially
considering how updates and data consistency can be handled
McCahill, et al Informational [Page 4]
RFC 1862 IAB Workshop Report November 1995
A variety of methods can be used to update caches and replicas
- master-
- peer-to-
- flooding techniques (such as that used by NNTP).
Which strategy one chooses influences important characteristics
the cache or replicated database, such as
- consistency of
- is locking used to achieve consistency? this
performance...
- are there a priori guarantees of existence of an item in
database (is the answer authoritative, do you detect
after the fact, or is there no guarantee on authoritativeness
the answer?)
Consistency guarantees depend on the granularity of
(ms, sec, hr, day), and there are cases where it is acceptable
trade consistency for better performance or availability. Since
is a range of qualities of service with respect to consistency
performance, we would like to be able to tune these parameters for
given application. However, we recognize that this may not
possible in all cases since it is unlikely one can implement a
performance solution to all of these problems in a single system
Beyond simply performing replication or caching, there is a need
managing cache and replication servers. There are several models
organizing groups of caches/replication servers that range
totally adaptive to a rigidly administered, centrally
model
- a club model. Minimal administrative overhead to join the club
Participation is a function of disk space, CPU,
network bandwidth
- centrally coordinated service. Here administrators can
advantage of their knowledge of the system's topology and
community they intend to serve. There may be scaling
with this model
- hybrid combinations of the club and centrally coordinated
McCahill, et al Informational [Page 5]
RFC 1862 IAB Workshop Report November 1995
There are a couple of models for how to organize the management of
group of cooperating servers, but this does not address the
of what sorts of commands the manager (be it a person or a program
issues to a cache or replicated server. A manager needs to be able
address issues on a server such as
- control of caching algorithms, defining how information is
out of the cache based on disk space, usage demands, etc. This
where you would control time-to-live and expiry settings
- flushing the cache. There are circumstances where
information source has become inaccessible and the normal
aging strategy is inappropriate since you will not be able
get the information again for an indeterminate amount of time
- management control might also be a way for information
to control how information is pushed on servers for
data consistency, but this raises tricky problems with trust
authentication
Given a common set of management controls needed, a common
would allow for simplified management of a collection of caching
replicating servers since you would be able to both control them
a single set of commands and query them about their capabilities.
common language/protocol would also allow different
to interoperate
Replicating or caching information immediately raises issues
billing, access control and authentication. Ignoring
and access control issues simplifies the replication and
problem a great deal. Exactly who is running the replication
caching server makes a big difference in how you approach this issue
If the information publisher runs a set of servers, they can
handle billing and authentication. On the other hand, if
organization is running a cache on its firewall (a boundary cache),
and purchasing information from a vendor, there are sticky
regarding intellectual property in this scenario
Selecting an appropriate cache or replica of a database is simple
the case of a captive user group (for instance a company behind
firewall). In this case, configuring the user's software to
through one or more boundary caches/replication servers directs
users to the closest server. In the more general case, there
several replicated/cached copies of an object, so you may
several URLs when you resolve a URN. How do you select the best URL
Either client developers create ad hoc performance metrics or (in
ideal world) the lower level protocols would give the
McCahill, et al Informational [Page 6]
RFC 1862 IAB Workshop Report November 1995
application some guidance about the "closest" copy of the object.
other words, if better information about network performance
available from lower levels of the protocol stack, applications
not have to build ad hoc models of network
We did not model the functions of a cache/replication server
detail, but we did an (incomplete) model of some of the
(see Figure 1). The idea here was to start work on a general
which might include features such as a push function for use in
maintaining consistency and in preloading information that
information publisher believes will be requested in the near future
Preloading information via a push command might be a function
observed behavior patterns (when you ask for A you'll probably want
and C). The decision about what to preload can be made either by
information publisher or by the cache server. The cache server
the advantage that it has better knowledge of the use patterns of
community. The distributed nature of links to other servers
limit the knowledge of a single information publisher. In any case
being able to accurately predict usage patterns can result
significant performance enhancements for caches
Figure 1: a rough cut at
requests from client (in
|
|
|
\|/
+---------------------+
| | (management
| cache/replicated db |<--- commands from admins
| | publishers,
+---------------------+
|
|
|
\|/
requests sent to information providers (out
in: (requests from a client
- give me meta-info about cached object (how up-to-date
ttl, expiry, signatures/checksum, billing information )
- give me the
- go get the object from the
McCahill, et al Informational [Page 7]
RFC 1862 IAB Workshop Report November 1995
- cache, what objects should I pre-fetch
(this assumes that the client software believes that
cache/replica has some knowledge of use patterns and
predict what the user will do next
out: (requests sent to an information publisher or
cache further up the food chain
- server, do I have latest copy of this object
- give me object x and the meta data for object
- I have a copy of object x (announcing you have a
of object x to other caches or URN to URL server
- info publisher, what objects should I pre-fetch
(this assumes that the information publisher has
knowledge of use patterns and can predict what the
will do next
management: (commands from administrators,
cooperating caches, and object publishers
- turn parameters (e.g. consistency) on/
- flush the
- there's a new version of object x, take
3.3
Caching and replication are important pieces of Internet middleware
and solutions need to be found soon. Caches and replicas
different performance characteristics, and there are cases where
combination of the two provides the best solution. There are
many strategies for updating and maintaining consistency of
and replicated databases, and we do not believe any
implementation can suffice for the broad range of needs in
Internet. One possible solution would be to define a
protocol for a replicated distributed database and for caching
that different information application implementations
interoperate and be managed via a common management interface.
common protocol would provide a framework for future protocols (e.g.,
URN2URL, DHCP) or existing protocols (e.g., Gopher or WWW)
presently lack a consistent solution
McCahill, et al Informational [Page 8]
RFC 1862 IAB Workshop Report November 1995
4. Group 2A report: Building an Information
Karen Sollins, Abel Weinrib, Barry Leiner, Clifford Neuman,
LaLiberte, Erik Huizer, John Curran, John Klensin, Lixia Zhang
Michael Mealling, Mitchell Charity, Mike St. Johns, Paul
This group took as its central agenda exploring an
architecture, the services that would instantiate such
architecture, and the functional interfaces between a realization
such an architecture and both layers on which it would sit and
layers that would sit on it. In order to describe an architecture
one must describe not only what it includes, but also what
excludes
4.1. The core model and service
The general architecture has as its centerpiece objects, or as
are known in the Uniform Resource Identifier Working Group
resources. An object in this architecture has
characteristics. First, it has an identifier, assigned within
context of some namespace. Such an identifier is globally unique
will not be reassigned to another object. Thus, it can be said to
globally unique for a long time. Because such an identifier
remain unique for all time, it cannot contain location-
information ... locations can and will be reused. Also,
resources may appear in zero, one, or many locations simultaneously
location-dependent information can lead to a vast number
identifiers for an object, which will make it difficult to
separately retrieved copies of an object as being the same object
These locations are defined by the supporting layers that
transport and access. Therefore the definition of locations is
within the architecture, although their existence is accepted
Second, an object will support one or more abstract types.
determination beyond this statement was not made. One can
from these two points that an object cannot be part of such
architected universe without having at least one such identifier
without supporting at least one type if it has at least one location
In addition, the architecture contains several other components
First, there will be a prescribed class of objects called links
express a relationship among other objects including the nature
that relationship. It is through links that composite
composed of related objects can be created and managed. Finally
there is a need for several sorts of meta-information, both in
to discover identifiers (e.g. for indices and in support
searching) and to aid in the process of mapping an identifier to
or more potential locations. Both of these sorts of meta-
are associated with objects, although they will be used and
McCahill, et al Informational [Page 9]
RFC 1862 IAB Workshop Report November 1995
most likely managed differently, to support their distinctive
and update requirements
Given this architecture of information objects, one can
several boundary points. First, something that does not have
identifier or type is outside the architecture. Second,
architecture does not, at this point, include any statement
computations, or communications paradigms other than second-
by assuming that traversal of links will occur. Third,
pre-fetching, caching, and replication are important, such
may be hidden from higher level software components, and thus are
part of the data model exposed to the application in the normal
(though some applications may want to specify such characteristics).
Now one can ask how such a model fits into a layered network model
how it might be modularized and realized. We envisioned
information layer as an information "wholesale" layer. It
the general, broad model and provision of shared, network-
information. Above this sit the "retailers," the marketers
providers of information to the marketplace of applications users
Below the "wholesalers" lie the providers of "raw materials."
will be the provision of supporting mechanisms and architecture
which information objects can come
The remainder of this group's report describes the
decomposition of the wholesale layer, including the
among those modules, separate discussions of the interactions
between the retail and wholesale layers and then between
wholesale and raw material layers. The report concludes
recommendations for where the most effective immediate efforts
be made to provide for the wholesale layer and make it useful
4.2. The Wholesale
In order to realize the information architecture in the network
variety of classes of services or functionality must be provided.
each case, there will be many instances of a sort of service
coordinating to a lesser or greater degree, but all within
general Internet model of autonomy and loose federation. There
may be variants of any sort of service, to provide more
or constrained service. In addition, services may exist that
provide more than one of these services, where that is deemed useful
Each such service will reside in one or more administrative
and may be restricted or managed based on policies of those domains
The list of core services is described below. Because there are
interdependencies, there may often be forward references
describing a service and its relationships to other services
McCahill, et al Informational [Page 10]
RFC 1862 IAB Workshop Report November 1995
* RESOURCE DISCOVERY: Much of the activity of resource discovery
indexing and searching, will be in the domain of the retailers
although there are supporting hooks that can be provided by
wholesaler layer as well. A resource discovery service will
mappings from descriptions to identifiers of objects. They will
to be queried. Thus there is a general functionality for a
layer service that answers queries formulated in certain ways
responds with identifiers. The business of on what basis indices
computed or how they are managed will be domain specific
* NAMING or IDENTIFICATION: There are two aspects to assigning
identifier to an object, one in the wholesale layer, and one
arguably, in the retail layer. In the wholesale layer, one
generate identifiers that are guaranteed to be unique. In the
layer one might ask the question about whether two objects are
same or different by the rules of an identification authority
therefore would determine whether they should bear the same
different identification from that authority. It should be
that the URI Working Group has included these two functions in
requirements document for URNs
An identification service will obviously provide functionality to
uniqueness authority. It will also provide identification in
process of publication of objects, as will be discussed below, in
management of resource discovery information, object location
storage services, as well as cache and replication management
* NAME or IDENTIFICATION RESOLUTION: Since identifiers are
to be location independent, there is a need for a resolution service
Such a service may sometimes return other identifiers at this
level of abstraction (the equivalent of aliases) or
information, the information delivered to a transport service
access or retrieve an object
* OBJECT RETRIEVAL: Object retrieval is tightly coupled
resolution, because without resolution it cannot proceed.
retrieval provides the functionality of causing a representation
an object to be provided locally to the requester of an
retrieval. This may involve the functionality of object
(see below) and object storage, caching and replication services
well as the supporting transport facilities
* OBJECT PUBLICATION: When an object comes into existence in
universe of the information infrastructure, it is said to
"published." There will be two common scenarios in publication.
will be the use of tools to directly enter and create the
that comprises an object in the information infrastructure.
there may be object creation tools visible to users in applications
McCahill, et al Informational [Page 11]
RFC 1862 IAB Workshop Report November 1995
In contrast there may also be tools outside the
infrastructure (for example word processing or text editing tools
that provide for the entry of data separately from the operation
assigning an object an identifier and causing it to
information infrastructure definitions of objects. Thus, there
also be visible at the interface between the wholesale and
layers the ability to cause some pre-existing data to become one
more objects. In addition to interacting with the
service, publication is likely to cause interaction with
storage, and possibly caching and replication
* DEFINITIONS: If the information infrastructure is to both
and evolve over a long time period, we must be prepared for a
variety and growing number of different sorts of information
different functionalities that each supports. For objects
on the net, the functionality that each provides must be exposed
able to be learned. To do this objects must be able to indicate
name or identifier the types of functionality they are supporting
Given such an identifier, an object is only useful to a client,
the client can discover the definition and perhaps a
implementation of the type in question. This will be acquired from
definitions service, which will be used in conjunction
applications themselves directly, object publication, and
retrieval
* ATTRIBUTE MANAGEMENT: The attributes considered here relate
policy, although any understanding of that policy will be above
wholesale level. There are, for example, access management
copyright attributes. There is a question here about whether
is or should be any access time enforcement or only after the
enforcement. The information is likely to be in the form
attribute-value pairs and must be able to capture copyright
effectively
* ACCOUNTING: An accounting service provides metering of the use
resources. The resources wholly contained in the wholesale layer
the services discussed here. It will also be important to
metering tools in the wholesale layer to be used by the retail
to meter usage or content access in that layer. Metering may be
for a variety of purposes ranging from providing better
or service from the resources to pricing and billing.
accounting services will be used by object storage, caching
replication, lower layer networking services, as well as pricing
billing services. In the form of content metering it will
interact with attribute management
McCahill, et al Informational [Page 12]
RFC 1862 IAB Workshop Report November 1995
* PRICING, BILLING and PAYMENT: Pricing and payment services
two layers in the information infrastructure. Servers that
account balances and with which users interact to retrieve and
account information are applications that will be built on top
wholesale layer services. Pricing will be determined in
applications environment for application level activities. However
it must be possible for middle layer services to process
instruments analogous to cash, credit card slips, and checks,
an understanding of the specific implementation of the
mechanism. Application programming interfaces supporting
should be provided, and a common tagged representation of
instruments should allow instruments from a variety of
systems to be presented within middle layer protocols
* OBJECT STORAGE, CACHING and REPLICATION: There is a
that caching and replication are important, but the discussion
that was left to another group that had taken that as the focus
their agenda. Object storage will take an object and put
somewhere, while maintaining both the identity and nature of
object. It is tightly coupled to caching and replication, as well
accounting, often in order to determine patterns of caching
replication. It is also tightly coupled to object publication
translation, and provides interfaces to both supporting
facilities such as local file systems, as well as direct access
applications, needing access to objects
* TRANSLATION: A translation service allows an object to behave
a nature different than that it would otherwise support. Thus,
example, it might provide a WYSIWYG interface to an object
functionality might not otherwise support that, or it might
text on the fly from an audio stream. Translation services will
used by object publication (allowing for identification of an
including a translation of it) and with object storage, providing
interface only within the wholesale or to the retail layers
* SERVER AND SERVICE LOCATION: It will be necessary as part of
infrastructure to be able to find services of the kinds
here and the servers supporting them. This service has
contact with the lower layer of raw materials, in that it
provide, in the final analysis, the addresses needed to
locate objects and services using lower level protocols, such as
existing access protocols in use today, for example FTP, SMTP, HTTP
or TCP. This service will provide functionality directly to
discovery as well as remote object storage services
McCahill, et al Informational [Page 13]
RFC 1862 IAB Workshop Report November 1995
* ADAPTIVE GLUE: This is not a single service as much as
recognition that there must be a path for a flow of
between the network layers and the applications. The application
have constraints, based both on its own needs as well as needs of
objects in the wholesale layer. Only the application can really
what compromises in services provided below are acceptable to it.
the same time, the supporting network layers understand
qualities of service are available at what price. Hence there is
potential for flow of information both up and down through
wholesale layer, perhaps mediated by the wholesale layer. Hence
adaptive glue has hooks into all three levels
* SECURITY: Security services will be a critical piece of
infrastructure architecture. For any real business to be conducted
organizations must make their information available over the network
yet they require the ability to control access to that information
a per user and per object basis. To account properly for the use
higher level services, organization must be able to identify
authenticate their users accurately. Finally, payment services
be based on security to prevent fraudulent charges, or disclosure
compromising information
The two biggest problems in providing security services at
wholesale layer are poor infrastructure and multiple
mechanisms that need to be individually integrated with applications
The poor state of the infrastructure is the result of a lack of
accepted certification hierarchy for authentication. A commonly
position is that there will not be a single hierarchy, but there
be established authorities whose assertions are widely accepted,
indirectly certify the identities of individuals with which one
not had prior contact
Integration with applications is made difficult because,
security services are themselves layered upon one another,
services do not fit into the information architecture at a
layer. By integrating security services with lower layers of
information infrastructure, security can be provided to
layers, but some security information, such as client's identity,
be needed at higher layers, so such support will not be
transparent. Further, the security requirements for each
layer information service, and of the application itself, must
considered and appropriate use must be made of the middle-
security services applied
Integration with applications will require user demand for security
together with common interfaces such as the GSS-API, so
applications and middle layer information services can utilize
security services that are available, without understanding
McCahill, et al Informational [Page 14]
RFC 1862 IAB Workshop Report November 1995
details of the specific security mechanism that is employed
* BOOTSTRAPPING: In order for a newly participating machine to
the infrastructure, it must have some way of finding out about
least one instance of many of the services described here. This
be done either by providing it with some form of
provided by the human bringing it up or by a bootstrapping service
The bootstrapping service is more flexible and manageable; it
included here in recognition that this information must be
in some form or other. The bootstrapping service will sit
on the raw materials layer and will have contact with all
services described here
This completes the description of the services as identified by
group in the wholesale layer. Although this section suggests
services have interfaces to the retail and raw materials layers,
of these topics will need to be described separately as well,
clarify the functionality expected by each layer of the layer below
3. Interface to retail
The interface to the retail layer is the embodiment of the
model and attendant services. Thus the interface provides
application environment with a collection of objects
identifiers for distinguishing them within the wholesale layer
support for a typing or abstract functionality model. It
for the ability to create or import objects into this object world
the publication paradigm, and allows objects to evolve to support
or evolving functionality through the translation paradigm.
to the objects is provided by object storage, enhanced with
and replication services and mediated by the attributes managed
attribute management and accounting or content metering.
of resources (figuring out which identifier to be chasing)
provided by resource discovery services. Types are registered
hence available both as definitions and perhaps in the form
implementations from a definition service. Lastly, there is
vertical model of providing the two-way services of adaptive glue
quality of service negotiation and for security constraints
requirements, with access and services at all three layers
4. Interface to the raw materials
The raw materials layer falls into networking and operating systems
Hence it provides all those services currently available from
networking and operating systems. Wholesale services such as
management will be dependent on local operating system support
as a file system, as well as perhaps transport protocols. In fact
all instances of any of the above services will be dependent on
McCahill, et al Informational [Page 15]
RFC 1862 IAB Workshop Report November 1995
storage, process management, local access control and other
mechanisms, as well as general transport protocols for
both often among services of the same sort and among
dependent on each other that may not be collocated. In addition
group identified a set of issues that appear important for
networking components of the raw materials layer to provide to
wholesale layer in addition to the basic best effort
services that are commonly available. These take the form of a
list with the recognition that they are not all equally easy
possible
* Connectivity: It is useful and important for the operation
applications and the wholesale services to understand
connectivity is currently available. The group identified
categories of connectivity that it would be useful to know
represented by four questions
1) Is there a wire out of the back of my machine
2) Am I connected to a router
3) Am I connected to the global internet? (Can I get
my own domain?)
4) Am I connected to a specific host
These are probably in increasing difficulty of knowing
* Connectivity forecast: Although this is recognized as
extremely difficult or impossible to do, some form of
forecast would be very useful to the upper
* Bandwidth availability and reservation: It is useful for
application to know both what bandwidth might be available to it and
better yet, for it to be able to make some form of reservation
* Latency availability and reservation: It is useful for
application to know both what latency the network is
and, better yet, be able to set limits on it by means of
reservation
* Reliability availability and reservation: Again,
constraints are important for many applications, although they
have differing reliability constraints and may be able to
differently to different circumstances. But, if the
could make a statement (reservation) about what level
unreliability it can tolerate, it might be able to make tradeoffs
McCahill, et al Informational [Page 16]
RFC 1862 IAB Workshop Report November 1995
* Burstiness support: Although it is unlikely that the network
make predictions about the burstiness of its services, if
application can predict to the network its burstiness behavior,
network might be able to take advantage of that knowledge
* Service envelope: It is possible that, as an alternative to
above four issues, the raw materials layer could negotiate a
service envelope with the layers it is supporting
* Security availability: In many cases, it will be important for
upper layers to be able to know what sorts and levels of security
available from the raw materials layer. This is true of both
operating system support as well as transmission
* Cost: If there is to be usage charging at other than fixed
rates, it will be important for applications and users to
what those costs or at least estimates of them will be
* Policy routing: If it will be important for transport services
support policy routing, it will be important for users of
transport services to identify into which policy classes they
fall
4.5.
This group has two categories of recommendations. One is
services in the wholesale layer that will both be especially
and readily achieved because work is soon to be or already underway
The other set of recommendations was a three item rank ordering
services that are most important for the lower layer to provide
the wholesale layer
Within the wholesale layer, the first services that should
provided are
* Object retrieval
* Name resolution
* Caching and replication
In addition, the group rank ordered three areas in which there
be quick payoff if the raw materials layer could provide them.
are
1.
2. Bandwidth, latency, and reliability or service
McCahill, et al Informational [Page 17]
RFC 1862 IAB Workshop Report November 1995
3. Security constraints on communication and
5. Group 2B Report: Components of an Internet Information
Cecilia Preston, Chris Weider, Christian Huitema, Cliff Lynch,
Romkey, Joyce Reynolds, Larry Masinter, Mitra, Jill
Group 2B discussed various aspects of problems in the
Information Infrastructure, thinking about recommendations to
IESG to focus on particular areas, and also paying attention to
of the philosophical and economic backgrounds to some of
problems. Economics can dictate some points of architecture: one
see economically why a publisher might bear the burden of the
of publishing, or a consumer might bear the burden of
associated with consumption, but not how some free-floating
party would necessarily bear the costs of providing services (such
third-party translators).
The group discussed the following topics
access(URL
URN
service
cache &
security &
payments,
search &
boot
general
McCahill, et al Informational [Page 18]
RFC 1862 IAB Workshop Report November 1995
5.1
There are several issues in the use of Uniform Resource Names
Uniform Resource Locators. URN resolution is a database lookup
returns the URLs associated with a URN. The architecture must
into account not only how the lookup is performed, but how
database is maintained. Both the lookup problem and the
problem must be solved at the same time to allow deployment of URNs
There are at least two problems in human interaction with
names. First, the notion of a unique name is a fallacy. Unique
cannot be enforced. Names may be forged or may simply be
due to human error. The architecture must accept this observation
still operate in the face of it. Designing for global uniqueness,
not requiring it, was adequate. Errors based on names not
unique are likely to be insignificant compared to other errors
Also, people frequently make assertions and assumptions about
rather than the documents that are being named. Making
about names is working at the wrong level of indirection.
assumptions about names, such as determining the contents of
named object from the syntax of the name, can lead to
surprises
Having a single, unified naming system is vital. While it is
to have multiple competing forms of other aspects of the
architecture, the naming system is what ties it all together.
must be only one naming system. If there is more than one, it may
be possible to compare names or to lookup locations based on names
and we will continue (to our detriment) to use locators rather
names
5.2 Global Service
The IANA has become the central switch point for
identification. and recommended that numbers that are
defined and kept in documents for use in distributed
systems (for instance, Assigned Numbers) should also be
online in some kind of database for use by applications.
distribution requires both an access method (perhaps multiple
methods) and an update method
5.3
Issues involving security arose over and over again.
includes things like validation of authority, confidentiality
integrity of data, integrity of services, access control. The
agreed that, although often overlooked, confidentiality is important
McCahill, et al Informational [Page 19]
RFC 1862 IAB Workshop Report November 1995
and, more strongly: anonymity is important. It should be possible
access documents or objects without the architecture requiring you
leave digital fingerprints all over the place
Security must occur on an end-to-end basis. Documents or objects
on the Internet may not only traverse the Internet. Relying
security mechanisms in the underlying protocol suite does
necessarily provide end-to-end authentication or confidentiality
Currently lower layer security is ill-defined and
unimplemented. Designers building information applications atop
Internet currently receive little guidance in how to design
features into their applications, leading to weak ad hoc
nonexistent security in new applications. Designers are also
as to how to deal with the "security considerations" section that
mandatory in RFCs, and often fill them with boilerplate text
Furthermore, retrofitting security into existing architectures
not work well. The best systems are built considering security
the very beginning. Some systems are being designed that,
instance, have no place for a digital signature to authenticate
data they pass. These issues apply to data management as well
The group makes the following recommendations to the IESG
security
A. Develop and communicate a security model usable by designers
information applications - current models are not considered usable
B. RFC authors should be given advice on what security
need to be outlined and how to write them. The IESG security
should prepare guidelines for writing security considerations
C. Proposed Standards should not be accepted by the IESG unless
really consider security. This will require that recommendations
and B have been implemented and that the guidelines have
enough visibility to reasonably expect authors to know of
existence
D. Develop security modules usable by the implementors of
clients and servers - reusable across many different,
applications and platforms
E. Make clear what security services you can expect from the
layers
F. Make sure that the key distribution infrastructure is reviewed
usability by information applications
McCahill, et al Informational [Page 20]
RFC 1862 IAB Workshop Report November 1995
5.4 Search and
Searching is looking through directories that point to information
Indexing is scanning information to create directories. A "
directory" is the result of combining several indices
Indexing is currently done on the Internet via many mechanisms.
the current ad hoc nature of the indexing, information is
indexed multiple times. This is wasteful, but due to the
economics of the Internet, it tends not to cost more money. If
Internet (or parts of thereof) transitions to usage based charging
it may cost the information provider too much to allow
information to be indexed. In general, the provider should
control over how the information they control is indexed
Above all, the architecture should not encourage a situation
information is normally not indexed. It should encourage
collection of indexing data only a single time. Having a
computation of a summary which is sent to a search/index server
vastly preferable to having that server "walk the net" to
information to index
Indexing and search techniques are quite varied. It is quite
that index and search are too close to general computation to try
standardize on a single protocol for either. Instead, it is
that the architecture allow multiple search techniques. There
currently certain types of indices that can only be generated
humans because of their level of semantic content. There are
differences in the quality and usability of indices that
machine-generated vs. human generated
Unified directories tend to combine indexing results from
different techniques. The architecture should constrain indexing
that it remains possible to merge the results of two searches done
different protocols or indexing systems. Returning information
standard formats such as URNs can help this problem
Vocabulary issues in search and index are very difficult. The
and information services communities do not necessarily
vocabulary that is consistent with the IETF community, which can
to difficult misunderstandings
"Searching the Internet" is an inappropriate attempt to
the information you're attempting to search. Instead, we
certain public spaces on the Internet. The concept of public
vs. private space on the Internet deserves further investigation
McCahill, et al Informational [Page 21]
RFC 1862 IAB Workshop Report November 1995
Indexing can run afoul of access control considerations.
control must be done at the object, but access control
should be propagated through indices as well. The index should
able to say "you're not allowed to ask that" rather than the
attempting to retrieve the object and being denied
An architectural point was raised that an index query should
the same result independent of who is asking. This is an
notion in the Domain Name System. This is inconsistent with
real-world indexing (for instance, corporate record
systems) which doesn't want to admit that some documents exist
you're not allowed to read them
5.5
Electronic mail, netnews, FTP and the web are frequently used
access information on the net today. Each protocol seems to provide
consistent view of the information on the Internet. In addition,
recent popularity of multi-protocol clients such as Mosaic seem
imply that the information content of the Internet is
retrievable and manageable. This perception is misleading
most protocols are used for other applications than they
originally designed for. In addition, Telnet, which has no concept
information retrieval and management, is often used to
information as well, for example in DIALOG and card file accesses
Since each protocol has different access and management capabilities
the inconsistencies show up in erratic search and retrieval results
puzzling error messages, and a basic lack of standard techniques
dealing with information. A consistent underlying
architecture will go a long way towards alleviating these problems
As the information architecture develops we should reconsider
electronic mail and netnews architecture in terms of the
architecture
The group noted that there have been difficulties in scheduling
working group meetings and recommends that there be a clearly
process inside the IETF to facilitate scheduling such meetings
6. Conclusions and
The workshop provided an opportunity for ongoing conversations
the architecture to continue and also provided space for
examination of some issues and for some new voices and
from other areas of Internet growth to participate in
architectural process
McCahill, et al Informational [Page 22]
RFC 1862 IAB Workshop Report November 1995
Part of the conclusion of the workshop is a set of recommendations
the IESG and IETF community
Recommendations on research/implementation directions
1. Caching and replication are important and overlooked pieces
Internet middleware. We should do something about it as soon
possible, perhaps by defining an architecture and service model
common implementation
2. Within the 'wholesale' layer, i.e. within the layer which
a consistent view of the information resources available on
Internet, the first services that should be provided are
* Object retrieval
* Name resolution
* Caching and replication
3. There would be quick payoff if the raw materials layer, i.e.
layer in which information resources are physically transmitted
computers, could provide the following services
*
* Bandwidth, latency, and reliability or a service
* Security constraints on communication and
4. Develop security modules usable by the implementors of
clients and servers - reusable across many different,
applications and
Recommendations to the IESG, IETF, and
1. Numbers that are formally defined and kept in documents
distributed information systems (for instance, Assigned Numbers
should be available in some kind of database for use by applications
2. Develop and communicate a security model usable by designers
information applications - current models are not considered
or are not widely accepted on the Internet
3. RFC authors should be given advice on how security
need to be written. The IESG security area should prepare
for writing security considerations
McCahill, et al Informational [Page 23]
RFC 1862 IAB Workshop Report November 1995
4. Proposed Standards should not be accepted by the IESG unless
really consider security. This will require recommendations 2 and 3
to be implemented first
5. Make clear what security services you can expect from the
layers
6. Make sure that the key distribution infrastructure is reviewed
usability by information applications
7. There needs to be a process inside the IETF for scheduling a
meeting between two working groups - for example, so that the
distribution WG can meet jointly with IIIR
McCahill, et al Informational [Page 24]
RFC 1862 IAB Workshop Report November 1995
APPENDIX A - Workshop
The workshop was held at MCI's facility in Tyson Corners, Virginia
The workshop organizers and attendees wish to thank MCI for the
of their facilities to host the workshop
All attendees met in joint session for the first half of October 12.
They then split into three groups. The first group considered
"distributed database" problem which has arisen over and over
in the design of parts of the Internet. The two other groups met
consider a list of issues pertaining to the
infrastructure. The groups ran independently until the morning
October 14, when they met again in joint session
The following people attended the workshop
Abel Weinrib abel@bellcore.
Barry Leiner BLeiner@ARPA.
Cecilia Preston cpreston@info.berkeley.
Chris Weider clw@bunyip.
Christian Huitema Christian.Huitema@SOPHIA.INRIA.
Cliff Lynch calur@uccmvsa.ucop.
Clifford Neuman bcn@isi.
Dan LaLiberte liberte@ncsa.uiuc.
Dave Sincoskie sincos@THUMPER.BELLCORE.
Elise Gerich epg@MERIT.
Erik Huizer Erik.Huizer@SURFnet.
Jill Foster Jill.Foster@newcastle.ac.
John Curran jcurran@near.
John Klensin klensin@infoods.mit.
John Romkey romkey@asylum.sf.ca.
Joyce Reynolds jkrey@isi.
McCahill, et al Informational [Page 25]
RFC 1862 IAB Workshop Report November 1995
Karen Sollins sollins@lcs.mit.
Larry Masinter masinter@parc.xerox.
Lixia Zhang LIXIA@PARC.XEROX.
Mark McCahill mpm@boombox.micro.umn.
Michael 