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