home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / 93mar / giss-minutes-93mar.txt < prev    next >
Text File  |  1993-04-29  |  6KB  |  164 lines
  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4.  
  5. Reported by Daniel Karrenberg
  6.  
  7. Minutes of the Generic Internet Service Specification BOF (GISS)
  8.  
  9. Agenda
  10.  
  11.  
  12.    o Presentation of the project
  13.    o Brainstorming
  14.    o Concrete actions
  15.    o To Working Group or not to Working Group ?
  16.  
  17.  
  18. Presentation
  19.  
  20. Tony Bates gave a brief presentation of the project.  The project is a
  21. RARE/RIPE joint project and is funded by SURFnet through RARE. The
  22. project is open and would like input from Internet Service (IS)
  23. providers wherever possible.  It was still at the stage of defining the
  24. scope and structure for a specification document which was hoped could
  25. be used, not as a mandatory document, but as a document specifying the
  26. relevant issues in Internet service provision.  The primary focus is at
  27. the service provider level focusing on coordination and information on
  28. what new (and possibly old?)  service providers need to know.  The
  29. Internet Service interface is between different service providers.  The
  30. user/provider interface appears to be covered other documents.  FYI16
  31. being a notable example.  A plan for the project has been produced plus
  32. some very draft text to start the discussion rolling.
  33.  
  34. Brainstorming
  35.  
  36. If things are too fixed, it could be difficult for people who try to
  37. provide a useful service to do things a bit differently.  For instance
  38. CIDR, is an issue now but it may not be an issue next year because
  39. everyone is doing it.  The bottom line is that this document needs to be
  40. revised regularly.
  41.  
  42. Customers should be able to see from the document how innovative the
  43. provider is.  It should not be a constraining item for providers but
  44. more of a helping document.  The problem that we want to solve is that
  45. it becomes more unclear what a Internet service is.  It's not so much
  46. about performance, performance is just a part of it.  There is something
  47. like a service level agreement, but no service guarantees.  We want to
  48. say things that can be agreed upon between a customer and provider, but
  49. without figures.  Maybe just hints to what kind of things a customer can
  50. ask it's provider (i.e., last statistics, access to first router).
  51.  
  52. The document should talk about the issues, but not mandate.  Enumerating
  53. the issues would not be a controversy.  Preferably not ``Thou shall''.
  54.  
  55.                                    1
  56.  
  57.  
  58.  
  59.  
  60.  
  61. We have to make sure we cover the whole basis.  Maybe some advise on the
  62. speed an organisation may need (organisations without prior knowledge).
  63. All existing attempts at this type of document have died because
  64. providers did not want the IETF to tell them what they should do.
  65.  
  66. What kind of reporting do you want to have from your provider ?  What
  67. kind of backup of general routing arrangements does a provider have ?
  68.  
  69. Some details of items to be in the specification were worked through.
  70.  
  71.  
  72. Details:
  73.  
  74. o Routing issues
  75.         - filtering
  76.         - redistribution
  77.         - CIDR
  78. o Addressing
  79.         - local Internet registries
  80.         - CIDR
  81. o Information Provision
  82.         - stats
  83.         - NOC based info (net status)
  84. o Operations
  85.         - hours
  86.         - contacts
  87.         - trouble ticket systems
  88.         - member of the club
  89. o Connectivity
  90.         - who can I reach
  91.         - what policies restrict my connectivity
  92.         - scope
  93.         - capacity and load
  94.         - backup agreements / resilience
  95. o Engineering and Maintenance
  96.         - MTBF
  97.         - MTBR
  98.         - future planning / capacity planning
  99. o Attachment
  100.         - DMZs, PPP (Dial-up, mobile)
  101.         - L2, L3 attachment issues (SMDS, FR, ...)
  102. o Generic Services Coordination
  103.         - DNS secondaries
  104.         - archive mirroring
  105.         - News provision
  106.         - registration issues
  107.         - mailing list mechanisms
  108.         - NTP
  109.         - Resource Discovery Tools Coordination
  110.         - MBONE
  111.         - tunneling nets
  112.         - CERT / security in general
  113. o Other networks
  114.         - what other nets do you connect (other than ``normal'' Internet
  115.                 networks
  116. o AUP (more than routing)
  117.         - what happens when violated / enforcements
  118.         - what agreements
  119. o remote/local management
  120.  
  121.  
  122.  
  123.  
  124. Concrete Actions
  125.  
  126.  
  127. Tony Bates          Tony Bates would try to get all these items done
  128.                     using the basic structure of the first draft.  The
  129.                     document would be reviewed by the following.
  130.                     Reviewers:  Dan Long, David Conrad and John Curren
  131. Daniel Karrenberg   Follow-up on the revision of FYI 16.  Make sure
  132.                     that it is less U.S. centric.
  133.  
  134.  
  135. To Working Group or Not to Working Group?
  136.  
  137. We need to keep Service Providers informed of the document progress.
  138. The draft will be sent to ORAD. We will see if there is enough critical
  139. mass to create a working group at the next IETF in Amsterdam.  Spread
  140. the word among providers to make sure they do not feel left out and get
  141. more input.
  142.  
  143. Attendees
  144.  
  145. Tony Bates               tony@ripe.net
  146. Erik-Jan Bos             erik-jan.bos@surfnet.nl
  147. Henry Clark              henryc@oar.net
  148. Robert Collet            rcollet@icm1.icp.net
  149. David Conrad             davidc@iij.ad.jp
  150. John Curran              jcurran@nic.near.net
  151. Kishan Dudkikar          kishan@icm1.icp.net
  152. Alisa Hata               hata@cac.washington.edu
  153. Daniel Karrenberg        daniel@ripe.net
  154. Daniel Long              long@nic.near.net
  155. James Miner              jjm@fibercom.com
  156. Peder Norgaard           pcn@tbit.dk
  157. Vilson Sarto             vilson@fapq.fapesp.br
  158. Bernhard Stockman        boss@ebone.net
  159. Marten Terpstra          marten@ripe.net
  160. Kirk Williams            kirk@sbctri.sbc.com
  161.  
  162.  
  163.                                    2
  164.