home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / roamops / roamops-minutes-97aug.txt < prev   
Text File  |  1997-10-10  |  7KB  |  165 lines
  1.      ROAMOPS Working Group, 
  2.      Monday 11th 9:30AM
  3.      
  4.      Reported by: Pat R. Calhoun
  5.      
  6.      - Agenda Bashing
  7.      - Document Status
  8.      - Charter Review
  9.      - MSAF Presentation
  10.      
  11.      Agenda Bashing:
  12.      - Should tunneling be standardized in this group? No. 
  13.      - Should an ISP advertise tunneling support? This could be a phonebook 
  14.      issue. It seems reasonable to address this issue in this WG.
  15.      - What is the relationship between RADIUS and Roamops?
  16.      - Add a pointer to the EAP draft in our roaming requirements and proxy 
  17.      behavior drafts.
  18.      
  19.      Document Status
  20.      - Review of Roaming Implementation will be issued as an informational 
  21.      RFC. It is being reviewed by the RFC Editor
  22.      - Roaming Requirements has changed. Bernard does not feel comfortable 
  23.      with the current requirements.
  24.      - Proxy RADIUS Behavior document has changed several times since 
  25.      Memphis. 
  26.      - NAI document is in its final form. We will push this document 
  27.      forward to proposed standard after the IETF.
  28.      - Accounting draft has gone through several changes. It has moved from 
  29.      batch move to real-time mode. 
  30.      
  31.      Relationship between RADIUS and Roamops:
  32.      There is a feeling that Proxy behavior draft should NOT belong in the 
  33.      roamops, but in the RADIUS WG.
  34.      It is quite clear that RADIUS does NOT want to define how RADIUS Proxy 
  35.      works. Since Proxy is THE most important part of ROAMING, we need to 
  36.      define it within this WG. The fact that RADIUS documents are split 
  37.      amongst many Working Groups, it gets confusing for to cross-reference. 
  38.      We could try to push this document in the RADIUS WG once the document 
  39.      is complete.
  40.      
  41.      Charter Review
  42.      - No one in the room admits to have read the charter. There also does 
  43.      not seem to have any objections to the document. The major changes 
  44.      are:
  45.      - Listed documents have changed
  46.      - Added the statement that no output from the working group shall 
  47.      suck!
  48.      - Goals and milestones have changed. 
  49.      - Roaming implementations have moved forward. 
  50.      - Sept 97 the Roaming requirements and NAI drafts will move forward. 
  51.      - Oct 97, submit internet-draft on phonebook attributes. We have 
  52.      solicited help on writing the draft and received offers from Jay 
  53.      Farhat (iPass) and Quinten Miller (Microsoft).
  54.      - December 97,  we will submit the Proxy draft as a proposed standard. 
  55.      - February 98, submit the accounting draft for proposed standard.
  56.      - A statement was made that there is still much more work to do. We 
  57.      still need to address moving away from Proxies, and send the 
  58.      authentication request directly to the autenticating RADIUS Server. 
  59.      This can be done with the use of DNS, Service Location and possibly 
  60.      IPSEC.
  61.      
  62.      Phonebook issues:
  63.      We have decided to talk about phonebooks and request some 
  64.      requirements. We will describe it as an LDAP schema, which is handled 
  65.      by the ACID Working Group. We will NOT describe the transfer 
  66.      mechanism, just the schema. We will include a phone number, pricing 
  67.      information, location, modem type, tunnel types, Access Codes(???), 
  68.      kinds of connectivity supported by the POP, timezone, support numbers, 
  69.      languages supported, IPV4/V6 support, services (i.e. Gaming Servers, 
  70.      netnews, etc), address remaping (NAT), Authentication types, random 
  71.      text. We will NOT define dialer behavior. 
  72.      
  73.      MSAF Presentation
  74.      - Micheal Kronenberger and Dominique Linden 
  75.      - Agenda
  76.      - Introduction GIA (Global Intraet Access) 
  77.      - Common Service Definition
  78.      - Settlement Document
  79.      - Discussion
  80.      
  81.      Introduction:
  82.      - Led by service providers who manage over 80% of the world's 
  83.      communication volume
  84.      - The address is http://www.msaf.org
  85.      - IETF, Technological Providers are leading, technical standards. MSAF 
  86.      create templates for bi-lateral agreements.
  87.      - GIA Used to remotely access companies or service provides in other 
  88.      areas.
  89.      - Develops interoperability agreements.
  90.      - Used as guidelines for contract negotiations 
  91.      - Access to Internet is NOT part of the service
  92.      - The user's company is responsible for authentication of users 
  93.      - Used for business users only.
  94.      
  95.      Common Service Definitions:
  96.      - Access Methods
  97.      - Call Flow
  98.      - Performance Metrics
  99.      - Internet Positioning
  100.      - Directory Service
  101.      - Billing/Settlement
  102.      - Minimal Customer Care
  103.      - L2TP has been defined as the official tunneling protocol 
  104.      - The address is assigned by the dial-in network.
  105.      - Autentication and Authorization is managed by the corporate network. 
  106.      - Service Provider will do initial authentication for setting up the 
  107.      tunnel and for accounting purposes.
  108.      
  109.      Settlement Documents
  110.      - format of information exchange
  111.      - recommendations for settlement process
  112.      
  113.      does NOT define:
  114.      - Settlement rates
  115.      - Settlement terms between service providers
  116.      - Accounting record formation (will use IETF standard)
  117.      
  118.      For question or comments, send mail to dominiq@mbd.ntt.co.jp. The CSD 
  119.      will be submitted to the roamops mailing list,
  120.      
  121.      Monday 11th 3:30PM
  122.      
  123.      Agenda:
  124.      - Roaming Requirements
  125.      - RADIUS Proxy Behavior
  126.      - NAI
  127.      - Accounting
  128.      
  129.      Roaming Requirements
  130.      - A problem exists with the usage of the word MUST. For example, the 
  131.      draft states that Fraud detection MUST be done. However, there are no 
  132.      methods defined to do so.  Possibly more text in the draft needs to 
  133.      define what Fraud detection means and that it is NOT dealt with as a 
  134.      protocol. Modify the text to state" These mechanisms are done using 
  135.      local policies" and to "minimize fraud as opposed to prevention of 
  136.      fraud".
  137.      - Connect Speed MUST be supported in the accounting request. This is a 
  138.      problem. However, the latest RADIUS extensions draft does support this 
  139.      info.
  140.      - Section 4.4.2. Provider attributes SHOULD be provided. 
  141.      - Add IPSEC MAY be used in conjunction with RADIUS.
  142.      
  143.      RADIUS Proxy behavior
  144.      - Jay Farhat will submit a document which will describe how to 
  145.      eliminate Proxying by implementing a mechanism to send the 
  146.      authentication directly to the authenticating server.
  147.      
  148.      NAI (Network Address Identifier)
  149.      - Discussion whether there should be a lower or upper limit for user 
  150.      name.
  151.      - There are NO objections to anything in the document.
  152.      - A WG Last Call will be sent to the mailing list for the NAI 
  153.      document, followed by sending the document to proposed standard.
  154.      
  155.      Accounting
  156.      - There is a question as to why we are trying to define a new 
  157.      accounting format instead of using RADIUS accounting. First off, 
  158.      RADIUS accounting is informational only.
  159.      - Transfer method is not specified in the draft. This COULD be a 
  160.      problem and will be added to the draft. However, it was mentioned that 
  161.      at the last IETF we should NOT define it. We will define it in a 
  162.      separate document.
  163.      - The list of metrics should be changed to state that it is 
  164.      extensible.
  165.