[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Accounting Draft : changed to accomodate new scope changes

To: "Cdn (E-mail)" <cdn@ops.ietf.org>
Subject: Accounting Draft : changed to accomodate new scope changes
From: Jay Guha <jayg@apogeenet.com>
Date: Fri, 26 Jan 2001 13:36:59 -0500
Delivery-date: Fri, 26 Jan 2001 10:37:55 -0800
Envelope-to: cdn-data@psg.com

 <<draft-gilletti-cdni-aaa-reqs-01.txt>> 
Hi CDN-Internetworking,

Attached is the revised Accounting Draft with the scope changes discussed
last week.
Gilletti & myself have discussed this somewhat.

Outcome Required :
- review of draft by all interested parties
- approval of scope
- review & suggestions of CDRs (defined in page 13)
- suggestions if more pictures will make things clearer
- any suggestions for containment & closure

Sorry this is kindof late - I just got it to a level that I can share for
discussion.

Cheers

Jay Guha
_________________
Apogee Networks
> Park 80 West Plaza II,
> Saddle Brook, NJ 07663
Tel#:  201-368-8800x286
URL : www.apogeenet.com

This transmission contains confidential and/or legally privileged
information intended only for the use of the individuals named in this
message.  If you are not the intended recipient, you are hereby notified
that any disclosure, copying, distribution or the taking of any action in
reliance on the contents of this e-mail transmission is strictly prohibited.
If you have received this transmission in error, please notify us
immediately so that we can arrange for the return of the documents to us at
no cost to you.

Network Working Group D. Gilletti
Internet-Draft Entera
Expires: March 2, 2001 R. Nair
Cisco
J. Scharber
Entera
J. Guha
Apogee
January 2001

CDI Internetworking Authentication, Authorization, and Accounting
Requirements
draft-gilletti-cdi-aaa-reqs-00.txt

Status of this Memo

This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on March 2, 2001.

Abstract

In developing a solution for CDN Internetworking it is necessary to
define and accommodate requirements for Authentication, Authorization, and
Accounting. Since the Authentication, Authorization, and Accounting
(AAA) working group is already focused on defining these
requirements, this document attempts to leverage that work. It
contains the requirements that would have to be supported by a AAA
service to formulate a solution for CDN peering.

Gilletti, et. al. Expires March 2, 2001 [Page 1]

Internet-Draft CDNP.AAA September 2000

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Scope . . . . . . . . . . . . . . . . . . . . . 6
4. Reference Models . . . . . . . . . . . . . . . . . . . . . 7
5. Data Exchange Mechanism / Protocol. . . . . . . . . . . . . . 8
6. Accounting Works . . . . . . . . . . . . . . . . . . . . . . . 10
7. Interfaces to External Components. . . . . . . . . . . . . . . 14
8. Further Issues . . . . . . . . . . . . . . . . . . . . . . . . 14
9. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 15
10. Security Considerations . . . . . . . . . . . . . . . . . . . 17
11. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 18
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 22

Gilletti, et. al. Expires March 2, 2001 [Page 2]

Internet-Draft CDNP.AAA September 2000

1. Introduction

The initial model for the World Wide Web (WWW) was based on clients
interacting with origin servers to request and receive content or
services. As the Web increased in scale this model proved unwieldy
for several reasons and resulted in current industry efforts to
build and operate Content Distribution Networks or CDNs. The overall
purpose of these CDNs is to create a scalable service that can meet
aggregate client demand while improving the performance and quality
of delivery. With increased demand for CDN services a need has been
generated for a mechanism for interconnecting or peering these
systems.

A typical CDN has relationships with publishers and provides them
with accounting and access related information. This information is
typically provided in the form of aggregate or detailed log files.

In addition, these CDNs typically collect accounting information to
aid in operation, billing and SLA verification. Since all accounting
data is collected within the CDN's administrative domain there is no
requirement for generalized systems or protocols.

Peering or interconnecting these CDNs introduces the need to obtain
similar accounting data from a foreign domain. This requirement
means that customers of a peered CDN service (publishers, clients,
and CDNs) must now have a generalized or standard means of obtaining
accounting information to support current as well as planned
business models. For example, the desire to implement business
models such as "Pay Per View" may require that there exist a
mechanism for authenticating and authorizing clients at a delivery
point that lies in a foreign domain.

This document along with [4],[5], and [6] outline requirements to be
satisfied in order to develop a mechanism for interconnecting or
peering CDNs. The intent of this set of documents is to provide
structure and guidelines for the evaluation of proposed solutions.

This document is focused on describing requirements for the
Accounting Peering System as described in [6]

This document frames the requirements for the Accounting Peering
System against the ongoing work of the AAA working group. This was
done because the authors realized that considerable effort has
already been expended in identifying inter-domain trust models and
accounting requirements within that working group. Therefore, a
conscious decision has been made to leverage that existing body of
work before making additional proposals. As such, this document
relies heavily on RFC 2904[1], RFC 2975[2], and RFC 2977[3].

Gilletti, et. al. Expires March 2, 2001 [Page 3]

Internet-Draft CDNP.AAA September 2000

Since the concentration of this effort is to determine the requirements for CDN internetworking / peering, the accounting requirements within an individual CDN are largely ignored within this document.

Gilletti, et. al. Expires March 2, 2001 [Page 4]

Internet-Draft CDNP.AAA September 2000

2. Terminology

This section introduces new terminology not already defined in RFC
2975[2], RFC 2977[3], or [4].

CDN Service:
An action that is directly or indirectly related to the act of
moving content from publisher to consumer.

Customer:
A billable entity (typically a publisher, client or peered CDN)
that agrees to exchange compensation for a CDN Service.

Entitlement:
A right to access a given CDN Service or content object typically
provided to a customer by a provider.

Flat Rate:
Indicates there is no limit on the amount of CDN Service that a
customer can consume during a Period.

Percentile:
Indicates that a CDN Service will be billed at a rate that is
based on a multiplier (Usage Rate) times the Usage during the
Period.

Period:
The duration for which the Usage counter or Entitlement is active.

Provider:
An entity that offers a CDN Service in exchange for Compensation.

Unit Of Measure (UOM):
Indicates how Usage should be tracked (i.e. minutes, seconds,
bytes, etc).

Usage:
A counter that measures the access or use of a CDN Service by the
Customer.

Usage Rate:
A per-unit cost associated with the Usage of a CDN Service.

Tiered:
Indicates the existence of a schedule against which Usage of a
given CDN Service is tracked and billed.

Gilletti, et. al. Expires March 2, 2001 [Page 5]

Internet-Draft CDNP.AAA September 2000

3. Scope

This section describes the scope of the Accounting Peering System for a peered CDN model.

The Accounting Peering system is responsible for the definition, generation and exchange of usage / consumption data entities (CDRs) which depict the activities and works performed, requested, and completed between peering CDNs, and any component internetworking with a CDN. These CDRs typically will contain 'what work was done', 'who did the work', 'when was the work done', 'how was the work done', 'Resources Used' etc.

Each independent piece of activity or work performed by / to a CDN, needs to be defined, transmitted and collected by peering Accounting Systems and appropriate instrumentation.

The Acccounting data entities (CDRs) may be used by other downstream functional tiers such as Rating & Billing, Capacity Planning, Performance & Monitoring Analysis, Payment systems, Account Management, Settlement Systems etc. The downstream tiers are considered out-of-scope.

The Accounting Peering system shall also define interfaces / mechanism which will allow the exchange of CDRs to external components or systems.

The transport protocol between instrumentation and CDR receiving systems is to be defined so that exchange of CDRs can be enabled.

The accounting system will accommodate both cyclic (stateless) works and discrete (stateful) works.

The accounting system provides for real time and/or offline/batch exchange of accountable events.

The accounting system must have interfaces to the Authorization and Authentication Tiers and shall be able to exchange CDRs with the relevant tiers.

Gilletti, et. al. Expires March 2, 2001 [Page 6]

Internet-Draft CDNP.AAA September 2000

4. Reference Model

Reference models are required to introduce the elements (along with their associated roles) involved in the generation, exchange, and storage of CDRs for CDN Internetworking.

It also will serve to put into perspective the role, location, boundaries, and constraints of the accounting peering system amongst its peers and the other interrelated components / layers.

4.1 High-Level Architecture Model

For the purpose of functional illustration, the high-level Architecture model serves to identify the roles of Provisioning Elements, Network Elements, Service Elements, Accounting Elements, Measuring / Metering Elements, and other Operation Support Systems (OSS) elements and the inter-relationship amongst each other.

4.2 Interface Model

The interface model serves to illustrate the roles and responsibilities of entities which are directly involved in the exchange of the CDRs.

4.3 Operations Model

Various operating scenarios (use cases) may exist. These scenarios need to be well expressed so that the sequencing of actions performed by multiple entities is well-formed.

4.4 Data Flow Model

The Data Flow Model will layout the creation of CDRs via stimulus, the flowpath of the CDRs, and the processes affecting / transforming the CDRs within the flowpath.

Gilletti, et. al. Expires March 2, 2001 [Page 7]

Internet-Draft CDNP.AAA September 2000

5. Data Exchange Mechanism / Protocol

5.1 Introduction

This objective of this section is to develop a transport which shall be responsible
for the transfer / exchange of a 'WorkElement' (CDR) from one entity to another entity.

5.2 General Requirements

This section details some of the general requirements of a transport protocol.

5.2.1 Separation of Exchange Protocol from CDR payload

The transfer protocol must be cleanly decoupled from the CDR payloads that it will transfer.

5.2.2 Transfer Capability Negotiation

Support for push, pull and poll transfers modes need to be supported.

5.2.3 Singular, Batched, Flow, & RealTime Oriented Data Transfer

The transport protocol should support the embedding of one or more CDR payloads. There may be
real-time delivery requirements for certain classes of CDRs and there this must be supported.

5.2.4 Efficient Encoding

5.2.5 Transfer Flow & Rate Control

The transfer protocol shall support flow control mechanisms to achieve sustainable delivery throughput
between the two data exchange peers.

5.2.6 Guaranteed Delivery

It is to be assumed that all works that are to be accounted for MUST never be lost. Therefore all transfer
modes must achieve reliable and guaranteed delivery of CDR payloads. Unless there is a compelling
case for an unguaranteed delivery requirement, this assumption and requirement shall stand.

Gilletti, et. al. Expires March 2, 2001 [Page 8]
Internet-Draft CDNP.AAA September 2000

5.2.7 CDR Relationship Identifiers

CDR EventIdentifiers (unique) may be required if relationships exist across a set of CDRs. Situations where
interim CDRs are generated, it is necessary to track the sequencing of a related set to ensure completeness,
detect errors, and the retransmission of CDRs. If relationships of a set of CDR spans a distributed domain,
then a distributed numbering strategy must exist.

5.2.8 Protocol State Machines

Clear visualization of transport protocol state machines in the sender and receiver must be developed.

5.2.9 Encryption

It is recommended that encryption works from other IETF standard be leveraged to ensure
data / CDR security

5.3 Authorization and Authentication

Authorization and authentication negotiation mechanism must exist in the protocol to enable the initiation
of data exchange.

Gilletti, et. al. Expires March 2, 2001 [Page 9]
Internet-Draft CDNP.AAA September 2000

6. Accounting 'Works'

The objective of this section is to define a scaleable framework for depicting all the various acts / services / 'works' performed by any entity which internetworks with a CDN, and which needs to be accounted. It is envisioned that a finite (core) set of works will need to be defined so as to achieve initial adoption and traction. Thereafter the framework must accommodate expansion of acts / services / work in the CDN Internetworking domain.

6.1 Introduction

An expression of 'work' performed consists of a collection/sequence of
attributes which consist of identifiers, measures, and counters. The
attributes serve to answer the who, what, where, and perhaps why of
these elements of usage or acts of consumption (CDRs).

For the CDN peering/interconnection scenario, it is important to
construct the expressions/acts of consumption such that there is no
dispute and ambiguity in meaning between parties producing and
receiving these expressions. In each act of consumption, there is a
minimum set of attributes in which an act/expression of
consumption/usage is considered "complete and undisputable" and
therefore able to be used by any downstream tiers (ex : rating and billing).

In addition, there are various "modalities of usage" - session,
resource-consumption, transaction/event, and/or a combination of the
above. This is not to be confused by the "modalities of billing"
such as pre-paid, post-paid, flat-rate, time-of-day, tiered, subscription / transaction / UBB, etc.

On a further note, it is also important to keep in the background
that the cost of metering/billing for an act of consumption / usage should
not "cost" more than the value of the consumption. This will help to
keep perspective on the granularity of details/attributes required
to meter the usage and the associated cost/benefit ratios.

6.2 General Requirements

6.2.1 Framework

A framework which can accommodate the scaleable definition of CDRs is required. This framework shall be able to introduce new CDRs and their associated schemas at a later timeframe.

It is critical that this framework ensures that 'Context' of the CDR payload is available to any party such that domains / scope of CDR and attribute applicability / validity is defined. 'Context' will perhaps mean roles, domain, and scope .This will help eliminate the risks of overloading the meaning of attributes, will bring consistency and uniformity to the sender and receiver of CDRs by effectively ensuring that the CDR data tier is well-separated from the CDR processing or presentation tiers. Decisions on in-band or out-of-band context embedding will be needed and shall be defined in the framework. The framework shall support self-description of the usage attributes.

Gilletti, et. al. Expires March 2, 2001 [Page 10]
Internet-Draft CDNP.AAA September 2000

This framework shall NOT define any actions, rules, constraints and context with regards to the processing of CDRs.

XML technology should be considered as a vehicle to achieve the above framework. Other strategies can also be considered if the end-value is achievable.

6.2.2 Form-Factor of CDRs

The representation and form-factor of the CDRs must also be addressed. Binary based and character based form factors must be evaluated in light of the constraints, conditions and requirements existing in the general operating architecture of CDNs and the associated interconnection demands.

6.2.3 Sizing of Volumes and Timing Requirement of CDR exchange

For each independent operating scenario and 'work' (CDR) type, requirements on CDR transport exchange and timings need to be assessed. It may be required to specify exchange constraints or requirements of some CDR Types.

6.2.4 Identifiers

An identifier is an attribute which associates a name convention to an entity. Examples of identifies are OrganizationName, EndUserName, Name of Movie, ContentID etc These identifiers can and do have properties and characteristics such as persistence, scope & domain, time-to-live etc. In the accounting context, these identifiers must be resolvable, unambiguous, recoverable and unique in the applicable domain.

6.2.5 Measures

Measures are attributes that help to describe 'how' a certain piece of work was performed, delivered or consumed. Typical examples are QoS, JitterDelay, etc.
Measures need to be defined completely and without ambiguity by defining known minima, maxima, unit of increments etc. The definition of measures must remain persistent and consistent within its scope and domain.

6.2.6 Counters

Counters are attributes that help to describe the quantity of resources consumed by a singular accountable act / work. Typically Counters must be defined by its units, minima and maxima and the mathematical operations that are permissible on a counter.

6.2.7 Naming Systems and Conventions (Distributed,Domained,Global)

In a distributed environment, a domain consistent way of naming entities such as a customer, ContentID, ContentType etc is required, so that any member participating in the CDN Internetworking activities can be consistently identified.
Likewise, it is also useful and required to consider mechanism for universally naming a specific content. For example, a specific movie or song might need to be named in the same way in all of the different points of the federation, independently of the domain that is delivering the specific content. This SHOULD follow a standard that can be interpreted by every member of the federation.
Gilletti, et. al. Expires March 2, 2001 [Page 11]
Internet-Draft CDNP.AAA September 2000

6.2.8 Security Requirements

It is important to define the security requirements of the CDRs. Authentication and authorization mechanism for access to the CDRs will be needed. It is assumed that the CDRs will be stored in a place(s) and access to the storage facility shall be via a specific interface mechanism.

This document assumes that the solutions suggested within this
document will be compliant with the trust model given in RFC 2904[1].

6.3 Core Works Requirements

This section defines those 'work' items that form the initial core set of 'works' that must be supported by any 'CDN-I Acccounting' enabled entity.
The objective here is to achieve consensus around a set of accountable events which are deemed sufficiently important such that its definition and support is warranted.

6.3.1 Introduction

For each of the accountable works defined below in the subsections, the following must be defined :

6.3.1.1 List of Attributes

Each attribute must define its name, its meaning, whether it is a required / optional / conditional attribute, its data type (int, string, complex etc)

6.3.1.2 Encoding and Representation

The encoding and representation format of each attribute inside the CDR must be defined.

6.3.1.3 Use Case Model

Generally describes the involved entities in the creation of the CDR. The 'Context' of the CDR will most likely be defined here as well.

6.3.1.4 Work Flow Model

Details the sequencing of events of the involved entities which generates the CDR and where the CDR has to be sent.

6.3.1.5 Work State Model

Details the state transition diagram of the 'Work' by defining the triggers and the state of work from inception to completion. The 'State' of Work may or may not be distributed across one or more elements in the federation.

Gilletti, et. al. Expires March 2, 2001 [Page 12]
Internet-Draft CDNP.AAA September 2000

6.3.2 ContentInjection Work

This 'work' is the event(CDR) that represents the act of a Host Origin Server which successfully 'injects' a piece of 'content' into a CDN for further distribution.

A logical representation of this CDR is as below :

6.3.3 ContentDistribution Work

This 'work' is the event (CDR) that represents the act where a CDN 'distributes' the 'content' to geographically distributed caches.

A logical representation of this CDR is as below :

6.3.4 ContentAccess Work

This 'work' is the event (CDR) that represents the act where an end-user (EU) accesses a piece of WebContent.

A logical representation of this CDR is as below :

6.3.5 ContentSignalling Work

[ editors note : need to understand this more clearly (may involved resource allocation etc) Need to discuss with members ]

6.3.6 ContentRetrieval Work

This 'work' is the event (CDR) that represents the act where when a webpagecache miss occurs, the 'content' need to be retrieved from the origin server and delivered to the cache where the miss occurred.

A logical representation of this CDR is as below :

Gilletti, et. al. Expires March 2, 2001 [Page 13]

Internet-Draft CDNP.AAA September 2000

7. Interface to External Logical Components and Tiers

7.1 Interface to CDN-I Provisioning Tiers

The CDN-I provisioning tiers need to be able to interoperate with the CDN-I Accounting system.

7.2 Interface to Logical Business Tiers

This section handles the interface requirements with the downstream business tiers such as Settlement, Rating & Discounting, Billing, Order Mgmt, Capacity Planning etc.

The layers / tiers mentioned above must have access to the CDRs via a data exchange mechanism and needs to be defined.

8. Further Issues

Gilletti, et. al. Expires March 2, 2001 [Page 14]

Internet-Draft CDNP.AAA September 2000

9. Recommendations

[Editor's Note: This section is here only to record some ideas that
need to be discussed while this specification is being progressed.]

One means of accommodating these types of services is to build off
of the ongoing work of the IETF AAA working group [2]. At present
this work is centered on the DIAMETER framework and protocol suite
for both provisioning and accounting. Early observations indicate
that DIAMETER has several characteristics that are desirable for
consideration in fulfilling these accounting requirements. The high
point characteristics are that it:

Has a model that supports either direct aggregation to home
provider 3rd party brokering.

Has well developed security and trust relationships.

Supports standardized, extensible accounting record format.

Is generally extensible via object oriented techniques.

The general model of extending DIAMETER is to define required
extensions to the protocol much like one would do to an abstract
base class in C++ via base class and subclassing.

Although its a bit premature to fully assess the suitability of
DIAMETER to meet these requirements, early observations indicate
that it sets forth a reasonable framework from which to develop a
base model for this effort.

Early observations have also identified the following issues with
the model that will likely create a need for the following
extensions to the base framework:

1. DIAMETER works on a request-by-request basis like pay-per-view.
While this model is okay for some applications, it will have to
be extended to support cases where a CDN pays at a larger
granularity (e.g., by a million content hits) and then resells
to its users or another CDN. This would apply to cases where a
CDN subscribes to a peered billing organization or pays for
distribution in a peering CDN. Existing DIAMETER mechanisms
could be used for pay-per-view content inside a CDN but may need
a higher level protocol across CDNs for aggregate content
programming. This protocol SHOULD co-exist with DIAMETER message
proxying. It can borrow message routing models from DIAMETER
(e.g. realm-based routing).

2. DIAMETER uses end-to-end security. This may not work well across

Gilletti, et. al. Expires March 2, 2001 [Page 15]

Internet-Draft CDNP.AAA September 2000

CDN boundaries. As previously discussed, it may be necessary to
be flexible about the definition of the "end" to be the CDN
boundary. This will be consistent with the need for CDNs to
serve as a content provisioning entity and makes it possible to
aggregate request traffic.

3. DIAMETER needs to be extended with AVPs specific to web-based
billable events.

More detailed analysis needs to be undertaken before these
conclusions can be validated.

Gilletti, et. al. Expires March 2, 2001 [Page 16]

Internet-Draft CDNP.AAA September 2000

10. Security Considerations

This document assumes that the solutions suggested within this
document will be compliant with the trust model given in RFC 2904[1].

Gilletti, et. al. Expires March 2, 2001 [Page 17]

Internet-Draft CDNP.AAA September 2000

11. Conclusion

There is a considerable amount of work remaining in defining the
accounting requirements and relationships. As such, the authors
welcome additional input from interested parties.

Gilletti, et. al. Expires March 2, 2001 [Page 18]

Internet-Draft CDNP.AAA September 2000

12. Acknowledgements

The authors acknowledge the contributions and comments of Brad Cain
(Mirror Image), Mark Day (Cisco), Fred Douglis (AT&T), John Martin
(Network Appliance), Doug Potter (Cisco), Oliver Spatscheck (AT&T),
Gary Tomlinson (Entera), and Jay Guha (Apogee Networks).

Gilletti, et. al. Expires March 2, 2001 [Page 19]

Internet-Draft CDNP.AAA September 2000

References

[1] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L., Gross,
G., de Bruijn, B., de Laat, C., Holdrege, M. and D. Spence,
"AAA Authorization Framework", RFC 2904, August 2000,
<ftp://ftp.isi.edu/in-notes/rfc2904.txt>.

[2] Aboba, B., Arkko, J. and D. Harrington, "Introduction to
Accounting Management", RFC 2975, October 2000,
<ftp://ftp.isi.edu/in-notes/rfc2975.txt>.

[3] Glass, S., Hiller, T., Jacobs, S. and C. Perkins, "Mobile IP
Authentication, Authorization, and Accounting Requirements",
RFC 2977, October 2000,
<ftp://ftp.isi.edu/in-notes/rfc2977.txt>.

[4] Day, M., Cain, B. and G. Tomlinson, "A Model for CDN Peering",
draft-day-cdnp-model-03.txt, (work in progress), November 2000,
<http://www.ietf.org/internet-drafts/draft-day-cdnp-model-03.txt>
.

[5] Day, M. and D. Gilletti, "CDN Peering Scenarios",
draft-day-cdnp-scenarios-02.txt, (work in progress), November
2000,
<http://www.ietf.org/internet-drafts/draft-day-cdnp-scenarios-02.txt>
.

[6] Green, M., Cain, B. and G. Tomlinson, "CDN Peering
Architectural Overview", draft-green-cdnp-framework-00.txt,
(work in progress), September 2000,
<http://www.ietf.org/internet-drafts/draft-green-cdnp-gen-arch-02.txt>

[7] IPDR NDM 2.0 'Network Data Management - Usage for IP Services'
<http://www.ipdr.org>
.

Gilletti, et. al. Expires March 2, 2001 [Page 20]

Internet-Draft CDNP.AAA September 2000

Authors' Addresses

Don Gilletti
Entera, Inc.
40971 Encyclopedia Circle
Fremont, CA 94538
US

Phone: +1 510 770 5281
EMail: don@entera.com

Raj Nair
Cisco Systems
50 Nagog Park
Acton, MA 01720
US

Phone: +1 978 206 3029
EMail: rnair@cisco.com

John Scharber
Entera, Inc.
40971 Encyclopedia Circle
Fremont, CA 94538
US

Phone: +1 510 770 5201
EMail: john@entera.com

Jay Guha
Apogee Networks
Park 80 West, Plaza II,
Saddle Brook, NJ
Tel: +1 201 368 8800
Email: jayg@apogeenet.com

Gilletti, et. al. Expires March 2, 2001 [Page 21]
Internet-Draft CDNP.AAA September 2000

Full Copyright Statement

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

Funding for the RFC editor function is currently provided by the
Internet Society.

Gilletti, et. al. Expires March 2, 2001 [Page 22]

Prev by Date: Re: Proposed charter, please comment
Next by Date: Re: Proposed charter, please comment
Prev by thread: Re: Authorized and Authenticated requests for routing and distribution ??
Next by thread: comments on draft-ietf-cain-request-routing-req-00.txt
Index(es):
- Date
- Thread