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 [email protected]. 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.

You are viewing proxied material from ftp.icm.edu.pl. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.