CURRENT_MEETING_REPORT_


Reported by Daniel Karrenberg

Minutes of the Generic Internet Service Specification BOF (GISS)

Agenda


   o Presentation of the project
   o Brainstorming
   o Concrete actions
   o To Working Group or not to Working Group ?


Presentation

Tony Bates gave a brief presentation of the project.  The project is a
RARE/RIPE joint project and is funded by SURFnet through RARE. The
project is open and would like input from Internet Service (IS)
providers wherever possible.  It was still at the stage of defining the
scope and structure for a specification document which was hoped could
be used, not as a mandatory document, but as a document specifying the
relevant issues in Internet service provision.  The primary focus is at
the service provider level focusing on coordination and information on
what new (and possibly old?)  service providers need to know.  The
Internet Service interface is between different service providers.  The
user/provider interface appears to be covered other documents.  FYI16
being a notable example.  A plan for the project has been produced plus
some very draft text to start the discussion rolling.

Brainstorming

If things are too fixed, it could be difficult for people who try to
provide a useful service to do things a bit differently.  For instance
CIDR, is an issue now but it may not be an issue next year because
everyone is doing it.  The bottom line is that this document needs to be
revised regularly.

Customers should be able to see from the document how innovative the
provider is.  It should not be a constraining item for providers but
more of a helping document.  The problem that we want to solve is that
it becomes more unclear what a Internet service is.  It's not so much
about performance, performance is just a part of it.  There is something
like a service level agreement, but no service guarantees.  We want to
say things that can be agreed upon between a customer and provider, but
without figures.  Maybe just hints to what kind of things a customer can
ask it's provider (i.e., last statistics, access to first router).

The document should talk about the issues, but not mandate.  Enumerating
the issues would not be a controversy.  Preferably not ``Thou shall''.

                                   1





We have to make sure we cover the whole basis.  Maybe some advise on the
speed an organisation may need (organisations without prior knowledge).
All existing attempts at this type of document have died because
providers did not want the IETF to tell them what they should do.

What kind of reporting do you want to have from your provider ?  What
kind of backup of general routing arrangements does a provider have ?

Some details of items to be in the specification were worked through.


Details:
 
o Routing issues
        - filtering
        - redistribution
        - CIDR
o Addressing
        - local Internet registries
        - CIDR
o Information Provision
        - stats
        - NOC based info (net status)
o Operations
        - hours
        - contacts
        - trouble ticket systems
        - member of the club
o Connectivity
        - who can I reach
        - what policies restrict my connectivity
        - scope
        - capacity and load
        - backup agreements / resilience
o Engineering and Maintenance
        - MTBF
        - MTBR
        - future planning / capacity planning
o Attachment
        - DMZs, PPP (Dial-up, mobile)
        - L2, L3 attachment issues (SMDS, FR, ...)
o Generic Services Coordination
        - DNS secondaries
        - archive mirroring
        - News provision
        - registration issues
        - mailing list mechanisms
        - NTP
        - Resource Discovery Tools Coordination
        - MBONE
        - tunneling nets
        - CERT / security in general
o Other networks
        - what other nets do you connect (other than ``normal'' Internet
                networks
o AUP (more than routing)
        - what happens when violated / enforcements
        - what agreements
o remote/local management




Concrete Actions


Tony Bates          Tony Bates would try to get all these items done
                    using the basic structure of the first draft.  The
                    document would be reviewed by the following.
                    Reviewers:  Dan Long, David Conrad and John Curren
Daniel Karrenberg   Follow-up on the revision of FYI 16.  Make sure
                    that it is less U.S. centric.


To Working Group or Not to Working Group?

We need to keep Service Providers informed of the document progress.
The draft will be sent to ORAD. We will see if there is enough critical
mass to create a working group at the next IETF in Amsterdam.  Spread
the word among providers to make sure they do not feel left out and get
more input.

Attendees

Tony Bates               tony@ripe.net
Erik-Jan Bos             erik-jan.bos@surfnet.nl
Henry Clark              henryc@oar.net
Robert Collet            rcollet@icm1.icp.net
David Conrad             davidc@iij.ad.jp
John Curran              jcurran@nic.near.net
Kishan Dudkikar          kishan@icm1.icp.net
Alisa Hata               hata@cac.washington.edu
Daniel Karrenberg        daniel@ripe.net
Daniel Long              long@nic.near.net
James Miner              jjm@fibercom.com
Peder Norgaard           pcn@tbit.dk
Vilson Sarto             vilson@fapq.fapesp.br
Bernhard Stockman        boss@ebone.net
Marten Terpstra          marten@ripe.net
Kirk Williams            kirk@sbctri.sbc.com


                                   2