Embedded Files
To: IETF-Announce:;@IETF.CNRI.Reston.VA.US
Sender: ietf-announce-request@IETF.CNRI.Reston.VA.US
From: Daniel Karrenberg <Daniel.Karrenberg@ripe.net>
Subject: March IETF: Generic Internet Service Specification (giss) BOF
Date: Tue, 16 Mar 93 13:01:14 -0500
X-Orig-Sender: mdavies@CNRI.Reston.VA.US
GISS BOF Announcement
- ---------------------
What is GISS ?
GISS stands for Generic Internet Service Specification.
The goal of the project is to produce a document describing
all aspects of a "useful Internet service". The intention
is to provide guidance to both service providers and custo-
mers. All important aspects of Internet services will be
covered. This includes essential secondary aspects such as
DNS service, routing protocols, routing policy features.
Service providers will be able to use the document to
specify the service they intend to offer. Users will be
able to use it as a checklist for the services they require.
The document will reference existing sources such as the
relevant Internet RFCs.
It is intended to give the document wide circulation includ-
ing publication as RTC report, RIPE document and/or RFC as
appropriate.
There will be Birds of a Feather meeting scheduled for Tuesday 30th March
at 19:30 until 22:00 to discuss the ideas for a Generic Internet Service
Specification (GISS).
Find below a plan for the GISS work and also a very very basic draft
of the ideas for a GISS. The intention of the BOF is to establish if the scope
and structure of the ideas are on track and some brainstorming of the service
aspects outlined in the draft. Everyone is encouraged to attend with a
particular emphasis on service providers.
PLAN
######
Basic Action Plan for GISS Project
Tony Bates
RIPE NCC, Amsterdam
March, 1993
1. Introduction
The goal of the project is to produce a document describing
all aspects of a "useful Internet service". The intention
is to provide guidance to both service providers and custo-
mers. All important aspects of Internet services will be
covered. This includes essential secondary aspects such as
DNS service, routing protocols, routing policy features.
Service providers will be able to use the document to
specify the service they intend to offer. Users will be
able to use it as a checklist for the services they require.
The document will reference existing sources such as the
relevant Internet RFCs.
It is intended to give the document wide circulation includ-
ing publication as RTC report, RIPE document and/or RFC as
appropriate.
2. Simple Action Plan
This simple action plan represents the steps to be taken in
bringing the Generic Internet Service Specification (GISS)
to reality. With this type of specification a large amount
of the work involves open discussion with various groups
within the Internet Community. Currently, it is unclear
exactly what such a specification should consist of and the
input of both users and service providers is sought.
1) RIPE, Prague. Feb, 1993
- Following the Birds of a Feather (BOF) meeting pub-
lish the initial ideas discussed within the BOF.
+ IN PROGRESS.
- Establish a RIPE working Group (giss-wg@ripe.net) and
continue to enhance the ideas and revise an initial
paper on the topic.
+ DONE.
2) IETF, Columbus, March, 1993
- Present the current paper one to two weeks in advance
of Columbus IETF and announce the GISS BOF to the IETF
March 3, 1993 [Page 1]
GISS March 1993
list. Discuss at this BOF what should actually be
covered in such a specification from both the users and
service providers perspective. Enhance and modify the
draft in the light of input from Columbus.
3) RIPE, Amsterdam, April, 1993
- Distribute the material so far gathered one to two
weeks before RIPE meeting in Amsterdam. Encourage peo-
ple to attend the first GISS working group. Make a
small presentation of various aspects so far discussed
within the working group session.
- Discuss the possibility of merging some of the aspect
of the RAEC Working group if felt desirable.
4) JENC-4, Trondheim, May, 1993
Send to various RARE lists two to three weeks of JENC-4
announcing a GISS discussion session and the current
draft of the specification. Continue to revise and fold
in comments from the JENC-4 discussion session.
5) IETF, Amsterdam, July, 1993
Finalise the paper and send to both RIPE and IETF lists
so any formal decision on the status of the document
can be taken.
6) RIPE, Autumn, 1993
Discuss in the working group the need for possible con-
tinuation work and anything else required in this area.
March 3, 1993 [Page 2]
#############
DRAFT OUTLINE
#############
Proposal for a Generic Internet Service
Specification (GISS)
Tony Bates
RIPE Network Coordination Centre
Amsterdam
The Netherlands
(WORK IN PROGRESS -- VERSION 0.1)
* DRAFT * DO NOT REDISTRIBUTE * DRAFT *
March, 1993
ABSTRACT
This proposal attempts to define a Generic Internet
Service Specification. It is felt such a specification is
desired and worthwhile to enhance and improve the under-
standing and quality of Internet services.-
March 16, 1993
_________________________
- Work on this project is done in conjunction with
the RARE technical programme and RIPE. The main fund-
ing for the project has been provided by SURFnet
through RARE.
March 16, 1993
Proposal for a Generic Internet Service
Specification (GISS)
Tony Bates
RIPE Network Coordination Centre
Amsterdam
The Netherlands
(WORK IN PROGRESS -- VERSION 0.1)
* DRAFT * DO NOT REDISTRIBUTE * DRAFT *
March, 1993
1. INTRODUCTION
The Internet today has evolved into a complex and rich variety of ser-
vices. This is due to many things; the large proliferation of Internet
applications, the growing number of resources, the ever increasing
Internet infrastructure, the diversity of Internet providers and
users. This complexity has reached a point whereby it is becoming
increasingly difficult to understand what an `Internet Service' is or
even what it should be. This statement in itself is of course vague
and this essentially sums up the the emphasis of this proposal; to try
to take the ambiguity out of the words `Internet Service'.
2. SCOPE
To realise the scope of this specification we must first define what
in general terms we consider an Internet Service to be. Figure 1,
shows in a conceptual sense how we define an Internet Service.
When a user here shown as U wishes to use, access or somehow interact
with a resource shown here as R, located in the Internet (often
referred to as the "Capital 'I' Internet" to stress the global Inter-
net rather form of local internetwork). User U will need to make use
of some form of an Internet Service (IS) to do this. Equally, the
resource itself must use an Internet Service to make it possible for
the resource to be used or accessed. Both the user U and resource R
need to make use of an Internet Service and if we take this one step
further we see that both the user U and resource R are interchangeable
in terms of Internet Service. Resource R may equally be a user as
well, making use of other resources and vice versa for user U. So the
simplified concept of an Internet service is;
- - the ability to access and hence be part of the Internet by any
means whatsoever.
March 16, 1993
__________
( Resource )
( R )
(__________)
#
#
Internet Service (IS)
#
________#________
( )
( Capital `I' )
( Internet )
(_________________)
#
#
Internet Service (IS)
#
#
+-----------+
| USER U |
+-----------+
Figure 1: Concepts of an Internet Service
This Internet Service provision and it various aspects is what this
specification concerns itself with.(1)
This specification is aimed at both Internet Users and Service Provid-
ers alike to give them the needed perspective when assessing and pro-
viding an Internet Service. Although as the title implies, the propo-
sal is written in terms of generality, it should be noted that there
is an intentional emphasis on a pragmatic and applicable approach with
an eye towards current technology. It keeps its focus on the primary
aspects of the Internet Service. It is intended to be of use by the
intelligent layman as well as someone with an existing knowledge of
the Internet.
The goal of this proposal is to provide a reference document that can
be used to assess and understand what services constitute an Internet
Service and what service offerings are potentially available in vari-
ous categorised aspects of Internet Service.
If the specification's scope is correct and deemed useful, one could
see this as a potential framework by which a "service provider" can
_________________________
(1) It should be clear that when the term `service'
is used it is explicitly used in the context of the de-
finition of the Internet Service outlined rather than
any form of protocol related context.
March 16, 1993
describe its service. It could also act as basic template document for
use as part of a standard "Request For Information" or "call for
tender" process.
With this scope realised, it should be noted what this specification
will not cover. For many, there are bound to be other aspects of an
Internet Service which could be covered. Publications or more specifi-
cally "off-line" documents relevant to the Internet community could be
considered part of an Internet Service in themselves. However, this
is beyond the scope of this specification. The "cost" or "price" of a
service and the relevant `pros and cons' in terms of cost benefit
could also be covered. Again, this is beyond the scope of this paper.
The specification will also not attempt to try to tell you `how' you
should decide on an Internet Service. This is far too subjective and
the aim is one of openness and no bias is intimated.
>>>>
>>>> This is the model and the focus of an IS
>>>> I think we are interested in...
>>>> May need more of the what the scope isn't
>>>> Comments ?
>>>>
3. MOTIVATION
There are several motivations behind this proposal. Most of these
stem from the vast growth of the Internet within the last few years
and the direct need for a greater understanding of what an Internet
Service is and comprises of.
In the last few years the Internet infrastructure has changed from
essentially a single `core' backbone with some application gateways
into various transit and regional based service providers making a
complex and globally connected network. Service providers provide
various types of service and there is a growing need to have a docu-
ment that can act as a reference for service providers to specify the
services they intend to offer and for users to determine the services
they may require.
There are several excellent publications regarding the Internet itself
discussing various aspects ranging from technical summaries to "how
to" walk-throughs of the use of Internet applications. However, there
is currently no "de-facto" specification of what an Internet Service
actually is. Such a specification is badly needed to make it in the
future easier for both user and provider to understand what an Inter-
net Service is.
>>>>
>>>> May need more not sure ?
>>>>
4. CLARIFICATION
Throughout this specification certain generalised terms are assumed
and if this specification is to be clear these need to be clarified at
this point. A glossary is given in Appendix ? which should be used as
March 16, 1993
a reference to accompany this specification.
In the conceptual model defined in Section 2 we used some terms that
at this point should be enhanced upon to make it clear what the Inter-
net service is that we are attempting to specify.
4.1. Internet
In this case the Internet means the global internet itself. The com-
plex infrastructure in which connectivity between two distinct hosts
use the Internet Protocol (IP) to interact with each other in some.
The use of the capital "I" is used to stress the difference from some
form of local internetwork potentially made up of various types and
physical and transport based protocols.
4.2. Service
In this case we mean a provision of service between the Internet and a
User or Resource. This is contrast to other measurements of service
such as price per bit or even quality of service. The Service is
purely the way in which a user or resource make use of the Internet.
It does not attempt to make signify any higher level or quality
related the Service mechanism itself.
4.3. Network
When the term network is used. It is generally referring to an infras-
tructure or mesh making up a web of connectivity. This is often also
used in terms of IP to refer to the layer 3 or "network layer" entity
called an IP network. When this term is used we will explicitly note
these as an IP network.
4.4. Service Provider
A Service Provider is an organisation that provides the Service. They
are the entities who will participate in the provision of the Internet
Service between the User and Internet.
4.5. Resource
An internet resource is something is of use by users of the Internet.
For example, a database of information or a large archive of public
domain software could be described as a resource.
4.6. User
Here a user is taken to mean anything that makes use of the Internet
and hence makes use of an Internet Service. Often, a user may also
have resources of its own that can be available to the Internet as a
whole.
>>>
>>> Still not that clear - may need more.
>>>
March 16, 1993
5. STRUCTURE OF THE SPECIFICATION
The structure in many ways the most important aspect of the specifica-
tion. As each aspect of an "Internet Service" is detailed it is done
with a conscious effort to align with the natural way with which one
should consider an Internet Service. By this, I mean the aspects are
broken down into logical aspects. The main points of an Internet Ser-
vice are as follows:-
1) Access to the Internet.
Access to the Internet can be achieved in various different way
and these will be examined. Access is by far the most important
aspect of an Internet Service. Access can may different forms.
The two primary methods of access are categorised within the
specification as either "application gateway" access or "IP-
layer" access.
2) Supporting Services
Supporting services are services felt as mandatory to be provided
as part of an Internet Service. The most obvious of these would
be electronic mail. A service provider who does not have support
for electronic mail under some guise or other will have severe
problems communicating with its users. Other `supporting service'
will also be examined.
3) Connectivity
Connectivity is of course a major part of the Internet Service.
Connectivity itself is not just as simple as what is the reacha-
bility provided by the Internet Service, but also the type of
connectivity in terms of bandwidth, performance, round trip time
and so on. Although, this has some inference on quality of ser-
vice the main focus of this aspect is to determine the various
types of connectivity as opposed to any quality aspects of con-
nectivity.
4) Support
As with any service there is always a need for support. This
falls into several categories that need to be looked at. Specifi-
cally the areas of support that are of interest are the ones that
enhance and add to the Internet Service.
5) Supporting Internet Resources
Some Internet resources are seen as generalised and are offered
by service providers today. These are mentioned as optional
resources as part of the Internet Service itself. Again, the
inference is away from mandating these resources in any way but
are noted as possible options of supporting Internet resource
offerings.
March 16, 1993
Of course this is over simplified but one should keep these primary
aspects in mind. Within each of these aspects there will be many
secondary items that have some overlap. However, these will be noted
as appropriate.
With this outline in mind I intend to walk through each aspect in turn
noting what is the minimum requirement for each service plus addi-
tional features that could be part of such a service aspect. As has
already been noted, within each aspect there are various components
that will need to examined. As an introductory example and to
highlight this in terms of the layout - if we look at item 1 above,
"Access to the Internet". This can can be broken down into two major
different types of access. Application gateway access and direct IP-
layer access of some form. Within each of these there are additional
secondary aspects that need to be examined. For example with applica-
tion gateway based access you could have an application protocol based
gateway such as a mail or virtual terminal based gateway. Alterna-
tively this could be purely some form of dial-up access to a "login"
account that allows a usr to send mail from a machine connected to the
internet or even dial-up uucp access for mail and netnews. Hopefully,
from this brief example you get a sense of the structure of the
specification itself.
>>>> This will also need quite a bit more and will change I
>>>> expect once I get a feel of whether this is the correct approach
>>>> Wording is not good either I know ???
6. SPECIFICATION
6.1. ACCESS
Whenever a potential user realises the need for an Internet Service
the first and most important aspect of the service is how you will
access the Internet. The two primary methods of access are;
1) Gateway Access.
2 IP-Layer Access.
6.1.1. GATEWAY ACCESS
Gateway based access is a method of providing either a protocol trans-
lation gateway or a "store and forward" type gateway.
>>>>> etc,....
>>>>>
6.1.2. IP-LAYER ACCESS
IP Layer access means having the ability to send IP [REF] datagrams
directly. This aspect of an Internet Service falls into to separate
March 16, 1993
types of IP-layer access.
1) Continuous
>>> Discuss what this means. Talk a little about various low layer types
>>> of attachments.
2) Demand Driven
>>> Talk about SLIP/PPP type access, etc. [REF]
6.2. COMMON ASPECTS OF ACCESS
There are several important aspects of access that are relevant of
both gatewayed and IP-layer access.
>> Primary things like
>>
>> - General IP connectivity requirements, TCP, UDP, etc [REF]
>> - ICMP requirements and behaviour [REF]
>> - Routing requirements [REF]
>> - Addressing, subnetting [REF]
>> examine various secondary. So for example an aspect could be - a
>> provider should publish its routing policy if we think this is a valid
>> point.
6.3. SUPPORTING SERVICES
Once the access is defined we need to determine what the common or
minimum services a service provider should provide. With such a vast
amount of Internet applications available it is very easy to produce a
long list of applications. However, the clear intent is to detail only
the services that are felt mandatory to provide as part of a generic
Internet Service. The minimum services that should be provided are as
follows;
1) Mail
>>> Talk about RFC821 RFC822 SMTP X.400, i.e. Domains outside
>>> RFC 822 world.
2) DNS
>>> Talk about namespace, DNS RFCs, in-addr special zone
>>> Forwarders
6.3.1. SECONDARY SERVICES
Although not seen a general requirement some applications are becoming
March 16, 1993
more and more common place as part of an Internet Service as worthy of
note. The most important of these by far is remote login services.
>>> Details of Telnet , r-protocols to highlight incompatibility of
>>> them (BSDisms). [REF]
6.4. CONNECTIVITY
All the way through this paper connectivity has been somewhat assumed.
However, connectivity itself has several important aspects.
>>> Talking about
>>> response times
>>> reachability
>>> performance
>>> backup
>>> bandwidth
6.5. SUPPORT
>>> Will cover Helpdesk
>>> information services
>>> NOC
>>> Monitor (SNMP)
>>> Statistics (OPSTAT)
>>> 24 x 7
>>> UPS (maybe)
>>> Trouble Ticket/Information flow.
>>> Others
6.6. SUPPORTING INTERNET RESOURCES
>>> Discussion of....
>>> `In-House resources as opposed to remote access based resources.
>>> For example
>>> FTP archive services
>>> News, NNTP, etc
>>> Internet Resource Discovery Tools.
>>> Others ?
7. AN EYE TO THE FUTURE
>>> Some overview discussion is probably needed in terms of
>>> IPv7. Maybe try to clarify the aspects of this spec that
>>> will potentially be unchanged by the introduction of IPv7
>>> whatever that is....
8. REFERENCES
>>>
>>> Various references.
March 16, 1993
>>> Maybe should also try to provide in an appendix a one page giving
>>> pointers to where the references can be got. This is a major
>>> problem with most papers. It is not always easy to know
>>> where to get the various references so this could be useful esp.
>>> as it is aimed at users.
9. APPENDICES
>>>
>>> The idea for the appendices would be have any additional tertiary aspects
>>> in here such as more discussion of gateways, etc,....
>>>
>>>
>>> Another appendix will be the glossary as well
>>> The will be reasonably extensive when it is finished.
>>
March 16, 1993
------- End of Forwarded Message
Page updated
Google Sites
Report abuse