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
Wrap
Text File
|
1997-10-10
|
7KB
|
165 lines
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.