Criteria for Evaluating Roaming Protocols (RFC2477)
Original Publication Date: 1999-Jan-01
Included in the Prior Art Database: 2000-Sep-13
Internet Society Requests For Comment (RFCs)
B. Aboba: AUTHOR [+2]
This document describes requirements for the provisioning of "roaming capability" for dialup Internet users. "Roaming capability" is defined as the ability to use multiple Internet service providers (ISPs), while maintaining a formal, customer-vendor relationship with only one.
Network Working Group B. Aboba
Request for Comments: 2477 G. Zorn
Category: Informational Microsoft Corporation
Criteria for Evaluating Roaming Protocols
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document describes requirements for the provisioning of "roaming
capability" for dialup Internet users. "Roaming capability" is
defined as the ability to use multiple Internet service providers
(ISPs), while maintaining a formal, customer-vendor relationship with
Operational roaming services are currently providing worldwide
roaming capabilities, and these services continue to grow in
popularity . Interested parties have included:
Regional Internet Service Providers (ISPs) operating within a
particular state or province, looking to combine their efforts
with those of other regional providers to offer services over a
National ISPs wishing to combine their operations with those of
one or more ISPs in another nation to provide greater coverage in
a group of countries or on a continent.
Businesses desiring to offer their employees a comprehensive
package of dialup services on a global basis. Those services can
include Internet access as well as secure access to corporate
intranets via a Virtual Private Network (VPN).
This document provides an architectural framework for the
provisioning of roaming capabilities, as well as describing the
requirements that must be met by elements of the architecture.
2.1. Requirements language
In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
"recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
described in .
Please note that the requirements specified in this document are to
be used in evaluating protocol submissions. As such, the
requirements language refers to capabilities of these protocols; the
protocol documents will specify whether these features are required,
recommended, or optional for use in roaming. For example, requiring
that a protocol support confidentiality is NOT the same thing as
requiring that all protocol traffic be encrypted.
A protocol submission is not compliant if it fails to satisfy one or
more of the must or must not requirements for the capabilities that
it implements. A protocol submission that satisfies all the must,
must not, should and should not requirements for its capabilities is
said to be "unconditionally compliant"; one that satisfies all the
must and must not requirements but not al...