NOTE: This charter is a snapshot of the 39th IETF Meeting in Munich, Bavaria, Germany. It may now be out-of-date.
Chair(s):
G. Zorn <glennz@microsoft.com>
Pat Calhoun <pcalhoun@usr.com>
Operations and Management Area Director(s):
John Curran <jcurran@bbn.com>
Michael O''Dell <mo@uu.net>
Operations and Management Area Advisor:
John Curran <jcurran@bbn.com>
Technical Advisor(s):
Michael O''Dell <mo@uu.net>
Mailing Lists:
General Discussion: roamops@tdmx.rutgers.edu
To Subscribe: roamops-request@tdmx.rutgers.edu
In Body: include
Archive: ftp://ftp-no.rutgers.edu/misc/IETF/roamops
Description of Working Group:
The purpose of this group is to develop or adopt procedures, mechanisms and protocols to support user roaming among groups of Internet service providers (ISPs). This is different from, but related to, the work of the IP Routing for Wireless/Mobile Hosts Working Group (mobileip) in that the roamops group is not concerned with the movement of hosts or subnets, but of users. In the near term, the goals of the group will be to produce an architectural document describing the basic mechanisms required to support user roaming. A repository for documentation describing current roaming implementations will also be maintained.
In addition, the group will address interoperability among ISPs and roaming users by standardizing such items as network usage data exchange (including the content, format and protocols involved), phone book attributes and exchange/update protocols, inter-ISP authentication mechanisms and exploring in depth the security issues involved with roaming. This work is expected to consist mainly of new or revised procedures and application-layer protocols.
Any and all business issues regarding the operation of an ISP roaming network (such as settlement, business and billing methods) are specifically NOT in the scope of the roamops Working Group and will not be discussed.
The group will work closely with other IETF Working Groups (including mobileip, radius, nasreqng saag and cat) to identify issues o which the roamops group should attend, as well as to assure their work does not make roaming unnecessarily difficult or impossible.
The utmost goal of the group will to make sure, by any means necessary, that it produces documents of high quality that are useful to the IETF community.
Goals and Milestones:
Done |
|
Re-submit existing Internet-Drafts as work of the ROAMOPS Working Group |
Jan 97 |
|
Submit Internet-Drafts to IESG for publication as RFCs |
Done |
|
Review the charter for additional work required |
Jul 97 |
|
Submit the roaming implementations review draft for publication as an Informational RFC. |
Sep 97 |
|
Submit the roaming requirements and network authentication identifier drafts for publication as a Proposed Standard. |
Oct 97 |
|
Submit Internet-Drafts on phone book attributes and format. |
Dec 97 |
|
Submit the authentication draft for publication as a Proposed Standard. |
Feb 98 |
|
Submit the accounting draft for publication as a Proposed Standard. |
Internet-Drafts:
· Dialup Roaming Requirements
· The Network Access Identifier
· Session Record Accounting in Roaming
· Guidelines for the Operation of RADIUS Proxies in Roaming
Request For Comments:
RFC |
Status |
Title |
RFC2194 |
Review of Roaming Implementations | |
Minutes ROAMOPS Working Group Meeting
Reported by: Pat R. Calhoun
Agenda
I. Agenda Bashing
II. Document Status
III. Charter Review
IV. MSAF Presentation
I. 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.
II. 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 to cross-reference. We could try to push this document in the RADIUS WG once the document is complete.
III. Charter Review
· No one in the room admits to having read the charter. There also does not seem to be 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.
- September 1997, the Roaming requirements and NAI drafts will move forward.
- October 1997, 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 1997, we will submit the Proxy draft as a proposed standard.
- February 1998, submit the accounting draft for proposed standard.
· A statement was made that there is still much work to do. We need to address moving away from Proxies and send the authentication request directly to the authenticating 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 remapping (NAT), Authentication types, random text. We will NOT define dialer behavior.
IV. MSAF Presentation
a) Micheal Kronenberger and Dominique Linden
b) Agenda
c) Introduction GIA (Global Intranet Access)
d) Common Service Definition
e) Settlement Document
f) 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 dial-in network assigns the address.
· The corporate network manages authentication and Authorization.
· 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
I. Roaming Requirements
II. RADIUS Proxy Behavior
III. NAI
IV. Accounting
I. 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 extension draft does support this information.
· Section 4.4.2. Provider attributes SHOULD be provided.
· Add IPSEC MAY be used in conjunction with RADIUS.
II. RADIUS Proxy Behavior
· Jay Farhat will submit a document that will describe how to eliminate Parodying by implementing a mechanism to send the authentication directly to the authenticating server.
III. 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.
IV. 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.
ROAMOPS - Global Intranet Access