NOTE: This charter is a snapshot of the 41st IETF Meeting in Los Angeles, California. It may now be out-of-date. Last Modified: 12-Feb-98
Glen Zorn <firstname.lastname@example.org>
Pat Calhoun <email@example.com>
Operations and Management Area Director(s):
John Curran <firstname.lastname@example.org>
Michael O'Dell <email@example.com>
Operations and Management Area Advisor:
John Curran <firstname.lastname@example.org>
Michael O'Dell <email@example.com>
To Subscribe: firstname.lastname@example.org
In Body: include
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 to 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:
Re-submit existing Internet-Drafts as work of the ROAMOPS Working Group
Submit Internet-Drafts to IESG for publication as RFCs
Review the charter for additional work required
Submit the roaming implementations review draft for publication as an Informational RFC.
Submit the roaming requirements and network authentication identifier drafts for publication as a Proposed Standard.
Submit Internet-Drafts on phone book attributes and format.
Submit the authentication draft for publication as a Proposed Standard.
Submit the accounting draft for publication as a Proposed Standard.
· Roaming Requirements
· The Network Access Identifier
· The Accounting Data Interchange Format (ADIF)
· Guidelines for the Operation of RADIUS Proxies in Roaming
· Secure Radius Server Operation Guidelines for Dial Roaming
· An LDAP Schema for Phone Books
Request For Comments:
Review of Roaming Implementations
Minutes of Roaming Operations (roamops) Working Group
Reported by Ken Peirce
Co-chair in attendance: Glen Zorn, Microsoft
Wednesday Session 1
19:30 - 19:45 Agenda Bashing
19:45 - 20:00 Roaming Requirements Document Last Call
20:00 - 20:15 NAI Last Call
20:15 - 20:45 LDAP Phonebook Schema
20:45 - 21:15 Accounting Data Interchange Format
21:15 - 21:45 Roaming and Mobile IP
21:45 - 22:00 Roaming Requirements Fulfillment
Thursday Session 2
13:00 - 13:45 Modem Outsourcing
13:45 - 14:45 DIAMETER Roaming
14:45 - 15:00 Wrap-up
**Co-chair introduced the last call for the Roaming Requirements Document.
Q: Question brought up by attendee concerning perceived vagueness of phrase "real time accounting required."
A lengthy discussion was held on this issue, centering about the level of detail required for a requirements document. Some felt that the spirit of that phrase combined with other accounting references indicated clearly that the wording prevented the use of store and forward, or "batch" accounting and that this was sufficient. The phrase was also worded in this fashion because of intractable arguments as to the definition of the word "reliable." Others attendees, citing legal usage of the records in question, demanded more exact language. It was determined that additional language could be used to disambiguate the accounting requirements. The new clause will be worded:
"In today's roaming implementations, real time accounting is a practical necessity in order to support fraud detection and risk management. As a result, a roaming standard must support accounting with reliability and timeliness appropriate to the application."
The Roaming Requirements Document was approved by those present with the new clause.
**Co-chair introduced the last call for the NAI Document
An attendee noted that several implementations were in violation of the document. The chair noted that when asked why the implementers violated the NAI, they replied "because there is no standard.
A question was brought up concerning a 2 part proxy unsupported by the NAI. It was agreed to take the issue to the list.
The NAI was approved without change by those present.
**The Co-chair introduced the LDAP Phonebook ID for discussion (Glen Zorn author)
General support was expressed for the document by members of the WG.
An attendee noted that the document used bit-fields to represent modem capabilities, and that as these capabilities change frequently, the document would be more stable if a string was used instead.
The author agreed to consider the change. The author also asked for comments on the correctness of the structure of the inheritance tree described in the document.
An attendee requested that the author send a copy of the ID to the members of the ACID(?) WG. The author agreed to do so.
**The Co-chair introduced the Accounting Database Interchange Format(ADIF) ID for discussion. (Bernard Aboba author)
A presentation was made that summarized the ID.
Following the presentation, several issues were raised by the attendees:
Q: What happens if multiple vendors' attribute value pairs are used in a single packet(like multiple 26's)? A: (Bernard): Dump complete set of AVPs into base 64 record. Draft will note that multiple 26's will be supported.
Q: Aren't there ordering requirements?
A: (Bernard): There should be no ordering required to avoid ordering problems. You must encode attributes in ADIF in the order in which they were received in the packet. The BNF section will be rewritten to eliminate reordering.
Q: How is the format extended?
A: (Bernard): By stating the protocol and attribute space. Additional language will be added to the draft to cover extensions.
Q: How do you encode attributes with multiple values?
A: (Bernard): One way is to add sub-attributes. Another is to use spaces.
The author left an open request to attendees to find attributes that could not be encoded using the rules.
Q: For proxy RADIUS and TACACS+, would there be interest in adding path information to the headers?
A: (Bernard): Accounting transfer is out of scope of the WG, but it is possible if format is MIME compatible.
The author asked if the WG would be interested in working the ID. The WG consented to this effort.
**The Co-chair introduced the issue of Roaming and Mobile IP
This work was determined to be out of the WG charter and was returned to the RADIUS WG.
**The Co-chair introduced the topic of Roaming Requirements Fulfillment.
Volunteers were sought to work on a document to this end.
Butch Anton/Mark Beadles Phonebook update
Butch Anton has initial doc. submission
Greg Suddarth proxy area
The meeting was then adjourned.
Co-chair in attendance: Pat Calhoun, Sun and Glen Zorn, Microsoft
**Co-chair Glen Zorn reminded WG that last call for the Roaming Requirements Document and NAI Document were at 5pm today.
**Co-chair Glen Zorn introduced the first presenter.
Nancy Greene of Nortel gave a presentation entitled: "Modem Outsourcing and the Requirements it brings to Resource Control"
AQ = Attendee Question
AQ: What about security(of DSM-CC)?
Nancy) A: DSM-CC has very little security, that is being sought from DIAMETER.
AQ: What is the value of DSM-CC over RADIUS?
(many respondents) A: Resource management. RADIUS does not have resource management.
AQ: What about IANA language for future RADIUS extensions?
(many respondents) A: The extensions cover new attributes, not commands.
AQ: What criteria are used in allocating resources?
Nancy) A: DNIS and ANI.
**Co-chair Glen Zorn introduced the next presenter.
Pat Calhoun(also Co-chair) of Sun gave a presentation entitled "DIAMETER"
Attendees noted that the author should speak with kerberos/rfc1510 and SIP authors as they are looking at change on the fly TCP/UDP operation (as is DIAMETER)
AQ:Does draft require security because of the M bit?
(Pat) A: Only if you receive the AVP.
AQ: Why would you combine digital signature and encryption?(due to export restrictions that only inhibit export of encryption products)
Pat) A: You don't have to, but most IETF efforts have this pairing. The author will have several security specialists review the document.
After some discussion, it was noted that a sha would have to be done on every AVP if the M bit is set.
An attendee attempts at writing proxy guideline document found that setting mutable/non-mutable bit is very much up to particular participants.
Pat Calhoun of Sun presented "DIAMETER ROAMOPS Extensions"
Author noted that document will support access-challenge. The operator of the mailing list make the list archives available to the list soon.
ROAMOPS - Agenda
Modem Outsourcing and the Requirements it brings to Resource Control
Roster Not Submitted