ROAMOPS Working Group, Monday 11th 9:30AM Reported by: Pat R. Calhoun - Agenda Bashing - Document Status - Charter Review - MSAF Presentation Agenda Bashing: - Should tunneling be standardized in this group? No. - Should an ISP advertise tunneling support? This could be a phonebook issue. It seems reasonable to address this issue in this WG. - What is the relationship between RADIUS and Roamops? - Add a pointer to the EAP draft in our roaming requirements and proxy behavior drafts. Document Status - Review of Roaming Implementation will be issued as an informational RFC. It is being reviewed by the RFC Editor - Roaming Requirements has changed. Bernard does not feel comfortable with the current requirements. - Proxy RADIUS Behavior document has changed several times since Memphis. - NAI document is in its final form. We will push this document forward to proposed standard after the IETF. - Accounting draft has gone through several changes. It has moved from batch move to real-time mode. Relationship between RADIUS and Roamops: There is a feeling that Proxy behavior draft should NOT belong in the roamops, but in the RADIUS WG. It is quite clear that RADIUS does NOT want to define how RADIUS Proxy works. Since Proxy is THE most important part of ROAMING, we need to define it within this WG. The fact that RADIUS documents are split amongst many Working Groups, it gets confusing for to cross-reference. We could try to push this document in the RADIUS WG once the document is complete. Charter Review - No one in the room admits to have read the charter. There also does not seem to have any objections to the document. The major changes are: - Listed documents have changed - Added the statement that no output from the working group shall suck! - Goals and milestones have changed. - Roaming implementations have moved forward. - Sept 97 the Roaming requirements and NAI drafts will move forward. - Oct 97, submit internet-draft on phonebook attributes. We have solicited help on writing the draft and received offers from Jay Farhat (iPass) and Quinten Miller (Microsoft). - December 97, we will submit the Proxy draft as a proposed standard. - February 98, submit the accounting draft for proposed standard. - A statement was made that there is still much more work to do. We still need to address moving away from Proxies, and send the authentication request directly to the autenticating RADIUS Server. This can be done with the use of DNS, Service Location and possibly IPSEC. Phonebook issues: We have decided to talk about phonebooks and request some requirements. We will describe it as an LDAP schema, which is handled by the ACID Working Group. We will NOT describe the transfer mechanism, just the schema. We will include a phone number, pricing information, location, modem type, tunnel types, Access Codes(???), kinds of connectivity supported by the POP, timezone, support numbers, languages supported, IPV4/V6 support, services (i.e. Gaming Servers, netnews, etc), address remaping (NAT), Authentication types, random text. We will NOT define dialer behavior. MSAF Presentation - Micheal Kronenberger and Dominique Linden - Agenda - Introduction GIA (Global Intraet Access) - Common Service Definition - Settlement Document - Discussion Introduction: - Led by service providers who manage over 80% of the world's communication volume - The address is http://www.msaf.org - IETF, Technological Providers are leading, technical standards. MSAF create templates for bi-lateral agreements. - GIA Used to remotely access companies or service provides in other areas. - Develops interoperability agreements. - Used as guidelines for contract negotiations - Access to Internet is NOT part of the service - The user's company is responsible for authentication of users - Used for business users only. Common Service Definitions: - Access Methods - Call Flow - Performance Metrics - Internet Positioning - Directory Service - Billing/Settlement - Minimal Customer Care - L2TP has been defined as the official tunneling protocol - The address is assigned by the dial-in network. - Autentication and Authorization is managed by the corporate network. - Service Provider will do initial authentication for setting up the tunnel and for accounting purposes. Settlement Documents - format of information exchange - recommendations for settlement process does NOT define: - Settlement rates - Settlement terms between service providers - Accounting record formation (will use IETF standard) For question or comments, send mail to dominiq@mbd.ntt.co.jp. The CSD will be submitted to the roamops mailing list, Monday 11th 3:30PM Agenda: - Roaming Requirements - RADIUS Proxy Behavior - NAI - Accounting Roaming Requirements - A problem exists with the usage of the word MUST. For example, the draft states that Fraud detection MUST be done. However, there are no methods defined to do so. Possibly more text in the draft needs to define what Fraud detection means and that it is NOT dealt with as a protocol. Modify the text to state" These mechanisms are done using local policies" and to "minimize fraud as opposed to prevention of fraud". - Connect Speed MUST be supported in the accounting request. This is a problem. However, the latest RADIUS extensions draft does support this info. - Section 4.4.2. Provider attributes SHOULD be provided. - Add IPSEC MAY be used in conjunction with RADIUS. RADIUS Proxy behavior - Jay Farhat will submit a document which will describe how to eliminate Proxying by implementing a mechanism to send the authentication directly to the authenticating server. NAI (Network Address Identifier) - Discussion whether there should be a lower or upper limit for user name. - There are NO objections to anything in the document. - A WG Last Call will be sent to the mailing list for the NAI document, followed by sending the document to proposed standard. Accounting - There is a question as to why we are trying to define a new accounting format instead of using RADIUS accounting. First off, RADIUS accounting is informational only. - Transfer method is not specified in the draft. This COULD be a problem and will be added to the draft. However, it was mentioned that at the last IETF we should NOT define it. We will define it in a separate document. - The list of metrics should be changed to state that it is extensible.