[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Requirements for Content Distribution
Stephen,
great summary of the discussion. I think one reason for the
disagreements is that we are discussing the how rather than the
why. As you outlined the requirements for a protocol below I don't
think we agree yet on the requirements the request routing,
distribution and accounting system will impose on this protocol.
For example, the request routing protocol has to know which
CDNs are participating. This is something which has to come
out of the protocol you outline below. However, we haven't
really stated all the expectations the request routing protocol
has on this exchange. The same is true for the distribution
and the accounting system.
I think if we state the expectation of those three systems more clearly a lot
of your comments will be answered. As Mark pointed out there is an effort
under way to have such documents available by the end of the week.
Oliver
Stephen Thomas writes:
>
> Here's a first cut at organizing the discussion into a internet draft.
> There are lots of holes left to fill and much discussion remaining, but I
> thought it worthwhile to try to take a first shot. Comments, flames,
> questions, etc. are encouraged. Comments, flames, questions, etc. with
> suggested text for the draft are strongly encouraged.
>
> The text below has the pagination stripped out for easier reading and
> commenting via email. The attachment has the pagination intact for ease of
> printing.
>
> Stephen
>
>
>
>
> <Working Group Name> S. Thomas
> Internet Draft TransNexus, Inc.
> Document: <draft-wgname-distreqs-xx.txt> January 2001
> Category: Informational
>
>
> Requirements for Content Distribution
>
>
> Status of this Memo
>
> This document is an Internet-Draft and is in full conformance with
> all provisions of Section 10 of RFC2026 [1].
>
> 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.
>
>
> 1. Abstract
>
> [In its current state, this document includes many editorial notes
> and comments. Such notes and comments are intended to highlight
> areas where more details are necessary, or where the editor feels
> that the group is far from consensus. Given the preliminary nature
> of this draft, it should not be assumed that un-commented aspects of
> the document do represent consensus; rather, those aspects appear to
> the editor to be nearer consensus. All editorial notes and comments
> are enclosed in square brackets such as this.]
>
> This document summarizes the requirements for the content
> distribution characteristics of CDN internetworking. For content
> distribution, CDNs agree on the exchange of content. Content
> distribution (in this limited definition) does not consider how user
> agents are directed to rendezvous with the distributed content, nor
> how CDNs exchange accounting information related to the access of
> distributed content.
>
> Content distribution assumes an architecture in which one CDN has,
> or has access to, content, and another CDN has, or has access to,
> surrogates on which that content may distributed. The first CDN is
> referred to below as the "Content Source," while the second is
> referred to as the "Content Destination." Note that the original
> content provider is a degenerate case of a CDN content source.
>
> The requirements assume a three-phase approach to content
> distribution; however, not all of these phases must necessarily be
> supported by communication protocols in all implementations. The
> first phase is Destination Capabilities Exchange. During this phase,
> the CDN content destination identifies the capabilities of its CDN
> distribution services. In the second phase, the CDN content source
> requests the use of some (or all) of those services. In the third
> phase, the CDN content destination acknowledges (either positively
> or negatively) a requested content distribution.
>
>
> 2. Conventions used in this document
>
> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
> this document are to be interpreted as described in RFC-2119 [2].
>
>
> 3. Content Distribution Architecture
>
> The architecture for content distribution presumes that even the
> most complex communication arrangements may be defined as a simple
> interaction between a content destination and a content source. The
> following figure, for example, shows a relationship between four
> different administrative authorities. CDN A operates a network of
> surrogates, and "CDN D"(actually the original content provider) has
> content to be distributed. CDN A communicates with CDN B, who
> communications with CDN C, who, in turn, communicates with CDN D.
>
> +------------+ +-----------+ +-----------+ +------------+
> | CDN A | | CDN B | | CDN C | | "CDN D" |
> |(surrogates)|<->| (agent |<->| (agent |<->| (content |
> | | | for A) | | for D) | | provider) |
> +------------+ +-----------+ +-----------+ +------------+
>
> CONTENT DST <-> CONTENT SRC
> CONTENT DST <-> CONTENT SRC
> CONTENT DST <-> CONTENT SRC
>
>
> In each case, one of the parties in the communications has the role
> of content destination, while the other party is the content source.
> Note that a particular CDN's role may change, depending on the party
> with whom it is communicating. CDN B, for example, is a content
> source when communicating with CDN A, but a content destination when
> communicating with CDN C.
>
> [Ed: I dont think weve ever explicitly talked about this model. It
> seems general enough to me to be reasonable, but other opinions are
> solicited.]
>
>
> 4. Content Distribution Process
>
> At a high level, the content distribution process proceeds in three
> phases. The following sections discuss each phase in more detail. As
> an overview, the communicating parties have the following
> responsibilities in each phase.
>
> Phase I Destination Capabilities Exchange. In this phase the
> content destination identifies the capabilities of its distribution
> service. Note that this phase may not necessarily require a
> communications protocol, as it may be handled off-line (e.g. as a
> part of contractual negotiations between the parties). [Ed: There
> seems to be fairly polarized opinions in the group on this issue.
> Some have argued that this phase should be accomplished completely
> off-line, while others have identified a need to have support for
> this phase in a real-time communications protocol. At this point,
> the approach is to define it as a part of the distribution process
> so that it can be made an optional part of any communication
> protocols.]
>
> Phase II Distribution Request. In this phase the content source
> asks the content destination to distribute its content.
>
> Phase III Distribution Confirmation. In this, the final
> distribution phase, the content destination confirms its acceptance
> (or denial) of the distribution request. Note that this phase does
> not provide any information about whether the distributed content
> has been accessed by user agents; such information exchange is the
> responsibility of CDN accounting. [Ed. Although there has been some
> discussion as to whether this phase is necessary, the editor feels
> that such questions were due mainly to a misunderstanding of the
> purpose of the confirmation. Corrections to this assumptions are
> solicited.]
>
>
> 5. Phase I - Destination Capabilities Exchange
>
> In the destination capabilities exchange, the content destination
> identifies the capabilities of its CDN service. Those capabilities
> may be defined as combinations of one or more of the following
> attributes [Ed: in no particular order]:
>
> Footprint: The areas served by the CDN, expressed as one or more
> CIDR IP address prefixes. [Ed: There has been the suggestion
> to use a generic attribute for footprint instead of IP address
> prefixes, but the editor has not (yet?) sensed much support
> for this proposal.] [Ed: It has been noted by many that IP
> address prefixes do not necessarily have a strong correlation
> to geographic areas, and, in some cases, it may be more
> desirable to express footprint as geographic areas; however,
> the editor is not aware of any concrete proposal to express
> geographic areas.] [Ed: The editor does not sense a consensus
> on whether or not it is necessary for a CDN that advertises a
> particular footprint to actually control surrogates on that
> subnet, or whether it is sufficient for the CDN to simply be
> willing to respond to requests from the indicated subnet.]
>
> Content Type: The type of content (e.g. static Web pages,
> streaming media, etc.) that the CDN is willing to distribute.
> [Ed: Presumably, this is expressed as an IANA-registered media
> type, but this has not been discussed on the list.]
>
> Capacity: The storage capacity that the CDN can provide. [Ed:
> Some discussion as to whether this is useful, but, so long as
> it is optional, is there a problem including it?]
>
> Bandwidth: The bandwidth available from the CDN. [Ed: Some
> discussion as to whether this is useful, but, so long as it is
> optional, is there a problem including it?]
>
> Distribution Method: The distribution methods that the CDN
> supports; one or more of push, pull, and on-demand.
>
> Private Extensions: Additional metrics that the communicating
> parties may agree to use, but are not part of the IETF
> standard.
>
> [Ed: Cost has also been proposed as an attribute but the editor
> feels that it cannot be reasonably accommodated in a standard;
> contrary opinions are solicited.]
>
> [Ed: The following has not been the subject of list discussion, so
> the editor may be assuming to much to include it at this point;
> however, it is presented in the spirit of fostering discussion.]
>
> Destination capabilities are expressed as a combination of the above
> attributes. So, for example, a CDN might advertise the following
> capabilities:
>
> 172.16.0.0/16; text/html,image/gif; 100 GB; 1 Gbit/s; pull
> 10.1.2.0/24; text/html; 200 GB; 100 Mbit/s; push:URL
> 10.1.2.0/24; video/quicktime; 0 GB; 256 Mbit/s; on-demand
>
> Such a list indicates that the CDN is willing to distribute up to
> 100 GB of static web content (either HTML pages or GIF images) to
> the 172.16.x.x subnet, to which it has 1 Gbit/s connectivity; the
> CDN will pre-fetch (pull) any such content. In addition, the CDN is
> willing to distribute up to 200 GB of HTML pages to the 10.1.2.x
> subnet, to which it has 100 Mbit/s of connectivity; the CDN requests
> that such content be pushed by the content provider to the indicated
> URL. Finally, the CDN is also willing to distribute Quicktime videos
> on-demand to the 10.1.2.x subnet; the CDN can provide up to 256
> Mbit/s of bandwidth for such content. In this last case, the content
> will be pulled from the content provider on-demand, and not stored
> in the CDN's caches. [Ed: This last example intends to represent
> streaming media.]
>
> Note that this phase need not always be accomplished by a real-time
> communication protocol. In some implementations, it may be
> sufficient for the parties to establish the destination's
> capabilities off-line.
>
>
> 6. Phase II Distribution Request
>
> In the second phase of content distribution, the content source
> requests distribution of its content. It describes that content with
> one or more of the following attributes [Ed: in no particular
> order]:
>
> URI: The uniform resource identifier for the content. [Ed: The
> editor would prefer further discussion on whether this
> attribute must uniquely identify an atomic unit of content or
> whether it can more generally specify a URI path. Allowing
> paths may significantly reduce the size of any protocol
> transfers, but, there are some attributes (e.g. size, content
> type) that do not apply as cleanly to paths, and some
> distribution methods (e.g. pull) cannot be easily accommodate
> paths.] [Ed: The suggestion has also been made to specify a
> "hash" rather than a URI, but the editor lacks sufficient
> understanding of that approach to document it.]
>
> Authoritative Source: Unique identity of the authoritative source
> for the content.
>
> Content ID: A unique identifier for this specific content, so
> that future references (e.g. to modify the content or to
> withdraw it from distribution) may be resolved. This value can
> also be used to avoid loops. [Ed: a "path" attribute has also
> been proposed as a way to avoid loops, but the editor feels
> such an attribute is unnecessary; contrary opinions are
> solicited.]
>
> Distribution Method: Push, pull, on-demand, or withdraw. How the
> content destination should retrieve the content. Withdraw is a
> special case that indicates a content destination should cease
> distribution of previously accepted content.
>
> Size: Size of the content. [Ed: No consensus that this is
> required, but any problems making it optional?]
>
> Time Frame: The period of time for which the content source
> requests distribution. [Ed: No consensus that this is
> required, but any problems making it optional?]
>
> [Ed: Next Hop has also been proposed as an attribute, but the
> editor lacks sufficient understanding to describe it; clue
> injections are solicited.]
>
> [Ed: Metric has also been proposed as an attribute, but the
> editor lacks sufficient understanding to describe it; clue
> injections are solicited.]
>
>
> 7. Phase III Distribution Confirmation
>
> In the final phase, the content destination accepts or rejects the
> distribution request. [Ed: There has some been some discussion about
> partial acceptance, e.g. only for a limited time or only a limited
> capacity, but the editor does not (yet?) sense a consensus that such
> a response is practical or useful.]
>
>
> 8. Security Considerations
>
> To be provided.
>
>
> 9. References
>
>
> 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
> 9, RFC 2026, October 1996.
>
> 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement
> Levels", BCP 14, RFC 2119, March 1997
>
>
>
> 10. Acknowledgments
>
> To be provided.
>
>
> 11. Author's Addresses
>
> Stephen Thomas
> TransNexus, Inc.
> 1140 Hammond Drive, Building E
> Suite 5250
> Atlanta, GA 30328
> Phone: +1 770 671 1888
> Email: stephen.thomas@transnexus.com
>
>
> Full Copyright Statement
>
> "Copyright (C) The Internet Society (date). All Rights Reserved.
> 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
>
> <Working Group Name> S. Thomas
> Internet Draft TransNexus, Inc.
> Document: <draft-wgname-distreqs-xx.txt> January 2001
> Category: Informational
>
>
> Requirements for Content Distribution
>
>
> Status of this Memo
>
> This document is an Internet-Draft and is in full conformance with
> all provisions of Section 10 of RFC2026 [1].
>
> 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.
>
>
> 1. Abstract
>
> [In its current state, this document includes many editorial notes
> and comments. Such notes and comments are intended to highlight
> areas where more details are necessary, or where the editor feels
> that the group is far from consensus. Given the preliminary nature
> of this draft, it should not be assumed that un-commented aspects of
> the document do represent consensus; rather, those aspects appear to
> the editor to be nearer consensus. All editorial notes and comments
> are enclosed in square brackets such as this.]
>
> This document summarizes the requirements for the content
> distribution characteristics of CDN internetworking. For content
> distribution, CDNs agree on the exchange of content. Content
> distribution (in this limited definition) does not consider how user
> agents are directed to rendezvous with the distributed content, nor
> how CDNs exchange accounting information related to the access of
> distributed content.
>
> Content distribution assumes an architecture in which one CDN has,
> or has access to, content, and another CDN has, or has access to,
> surrogates on which that content may distributed. The first CDN is
> referred to below as the "Content Source," while the second is
> referred to as the "Content Destination." Note that the original
> content provider is a degenerate case of a CDN content source.
>
>
> Thomas Informational Expires July 2001 1
>
> Requirements for Content Distribution January 2001
>
>
> The requirements assume a three-phase approach to content
> distribution; however, not all of these phases must necessarily be
> supported by communication protocols in all implementations. The
> first phase is Destination Capabilities Exchange. During this phase,
> the CDN content destination identifies the capabilities of its CDN
> distribution services. In the second phase, the CDN content source
> requests the use of some (or all) of those services. In the third
> phase, the CDN content destination acknowledges (either positively
> or negatively) a requested content distribution.
>
>
> 2. Conventions used in this document
>
> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
> this document are to be interpreted as described in RFC-2119 [2].
>
>
> 3. Content Distribution Architecture
>
> The architecture for content distribution presumes that even the
> most complex communication arrangements may be defined as a simple
> interaction between a content destination and a content source. The
> following figure, for example, shows a relationship between four
> different administrative authorities. CDN A operates a network of
> surrogates, and "CDN D"(actually the original content provider) has
> content to be distributed. CDN A communicates with CDN B, who
> communications with CDN C, who, in turn, communicates with CDN D.
>
> +------------+ +-----------+ +-----------+ +------------+
> | CDN A | | CDN B | | CDN C | | "CDN D" |
> |(surrogates)|<->| (agent |<->| (agent |<->| (content |
> | | | for A) | | for D) | | provider) |
> +------------+ +-----------+ +-----------+ +------------+
>
> CONTENT DST <-> CONTENT SRC
> CONTENT DST <-> CONTENT SRC
> CONTENT DST <-> CONTENT SRC
>
>
> In each case, one of the parties in the communications has the role
> of content destination, while the other party is the content source.
> Note that a particular CDN's role may change, depending on the party
> with whom it is communicating. CDN B, for example, is a content
> source when communicating with CDN A, but a content destination when
> communicating with CDN C.
>
> [Ed: I dont think weve ever explicitly talked about this model. It
> seems general enough to me to be reasonable, but other opinions are
> solicited.]
>
>
> 4. Content Distribution Process
>
> Thomas Informational Expires July 2001 2
>
> Requirements for Content Distribution January 2001
>
>
>
> At a high level, the content distribution process proceeds in three
> phases. The following sections discuss each phase in more detail. As
> an overview, the communicating parties have the following
> responsibilities in each phase.
>
> Phase I Destination Capabilities Exchange. In this phase the
> content destination identifies the capabilities of its distribution
> service. Note that this phase may not necessarily require a
> communications protocol, as it may be handled off-line (e.g. as a
> part of contractual negotiations between the parties). [Ed: There
> seems to be fairly polarized opinions in the group on this issue.
> Some have argued that this phase should be accomplished completely
> off-line, while others have identified a need to have support for
> this phase in a real-time communications protocol. At this point,
> the approach is to define it as a part of the distribution process
> so that it can be made an optional part of any communication
> protocols.]
>
> Phase II Distribution Request. In this phase the content source
> asks the content destination to distribute its content.
>
> Phase III Distribution Confirmation. In this, the final
> distribution phase, the content destination confirms its acceptance
> (or denial) of the distribution request. Note that this phase does
> not provide any information about whether the distributed content
> has been accessed by user agents; such information exchange is the
> responsibility of CDN accounting. [Ed. Although there has been some
> discussion as to whether this phase is necessary, the editor feels
> that such questions were due mainly to a misunderstanding of the
> purpose of the confirmation. Corrections to this assumptions are
> solicited.]
>
>
> 5. Phase I - Destination Capabilities Exchange
>
> In the destination capabilities exchange, the content destination
> identifies the capabilities of its CDN service. Those capabilities
> may be defined as combinations of one or more of the following
> attributes [Ed: in no particular order]:
>
> Footprint: The areas served by the CDN, expressed as one or more
> CIDR IP address prefixes. [Ed: There has been the suggestion
> to use a generic attribute for footprint instead of IP address
> prefixes, but the editor has not (yet?) sensed much support
> for this proposal.] [Ed: It has been noted by many that IP
> address prefixes do not necessarily have a strong correlation
> to geographic areas, and, in some cases, it may be more
> desirable to express footprint as geographic areas; however,
> the editor is not aware of any concrete proposal to express
> geographic areas.] [Ed: The editor does not sense a consensus
> on whether or not it is necessary for a CDN that advertises a
> particular footprint to actually control surrogates on that
>
> Thomas Informational Expires July 2001 3
>
> Requirements for Content Distribution January 2001
>
>
> subnet, or whether it is sufficient for the CDN to simply be
> willing to respond to requests from the indicated subnet.]
>
> Content Type: The type of content (e.g. static Web pages,
> streaming media, etc.) that the CDN is willing to distribute.
> [Ed: Presumably, this is expressed as an IANA-registered media
> type, but this has not been discussed on the list.]
>
> Capacity: The storage capacity that the CDN can provide. [Ed:
> Some discussion as to whether this is useful, but, so long as
> it is optional, is there a problem including it?]
>
> Bandwidth: The bandwidth available from the CDN. [Ed: Some
> discussion as to whether this is useful, but, so long as it is
> optional, is there a problem including it?]
>
> Distribution Method: The distribution methods that the CDN
> supports; one or more of push, pull, and on-demand.
>
> Private Extensions: Additional metrics that the communicating
> parties may agree to use, but are not part of the IETF
> standard.
>
> [Ed: Cost has also been proposed as an attribute but the editor
> feels that it cannot be reasonably accommodated in a standard;
> contrary opinions are solicited.]
>
> [Ed: The following has not been the subject of list discussion, so
> the editor may be assuming to much to include it at this point;
> however, it is presented in the spirit of fostering discussion.]
>
> Destination capabilities are expressed as a combination of the above
> attributes. So, for example, a CDN might advertise the following
> capabilities:
>
> 172.16.0.0/16; text/html,image/gif; 100 GB; 1 Gbit/s; pull
> 10.1.2.0/24; text/html; 200 GB; 100 Mbit/s; push:URL
> 10.1.2.0/24; video/quicktime; 0 GB; 256 Mbit/s; on-demand
>
> Such a list indicates that the CDN is willing to distribute up to
> 100 GB of static web content (either HTML pages or GIF images) to
> the 172.16.x.x subnet, to which it has 1 Gbit/s connectivity; the
> CDN will pre-fetch (pull) any such content. In addition, the CDN is
> willing to distribute up to 200 GB of HTML pages to the 10.1.2.x
> subnet, to which it has 100 Mbit/s of connectivity; the CDN requests
> that such content be pushed by the content provider to the indicated
> URL. Finally, the CDN is also willing to distribute Quicktime videos
> on-demand to the 10.1.2.x subnet; the CDN can provide up to 256
> Mbit/s of bandwidth for such content. In this last case, the content
> will be pulled from the content provider on-demand, and not stored
> in the CDN's caches. [Ed: This last example intends to represent
> streaming media.]
>
>
> Thomas Informational Expires July 2001 4
>
> Requirements for Content Distribution January 2001
>
>
> Note that this phase need not always be accomplished by a real-time
> communication protocol. In some implementations, it may be
> sufficient for the parties to establish the destination's
> capabilities off-line.
>
>
> 6. Phase II Distribution Request
>
> In the second phase of content distribution, the content source
> requests distribution of its content. It describes that content with
> one or more of the following attributes [Ed: in no particular
> order]:
>
> URI: The uniform resource identifier for the content. [Ed: The
> editor would prefer further discussion on whether this
> attribute must uniquely identify an atomic unit of content or
> whether it can more generally specify a URI path. Allowing
> paths may significantly reduce the size of any protocol
> transfers, but, there are some attributes (e.g. size, content
> type) that do not apply as cleanly to paths, and some
> distribution methods (e.g. pull) cannot be easily accommodate
> paths.] [Ed: The suggestion has also been made to specify a
> "hash" rather than a URI, but the editor lacks sufficient
> understanding of that approach to document it.]
>
> Authoritative Source: Unique identity of the authoritative source
> for the content.
>
> Content ID: A unique identifier for this specific content, so
> that future references (e.g. to modify the content or to
> withdraw it from distribution) may be resolved. This value can
> also be used to avoid loops. [Ed: a "path" attribute has also
> been proposed as a way to avoid loops, but the editor feels
> such an attribute is unnecessary; contrary opinions are
> solicited.]
>
> Distribution Method: Push, pull, on-demand, or withdraw. How the
> content destination should retrieve the content. Withdraw is a
> special case that indicates a content destination should cease
> distribution of previously accepted content.
>
> Size: Size of the content. [Ed: No consensus that this is
> required, but any problems making it optional?]
>
> Time Frame: The period of time for which the content source
> requests distribution. [Ed: No consensus that this is
> required, but any problems making it optional?]
>
> [Ed: Next Hop has also been proposed as an attribute, but the
> editor lacks sufficient understanding to describe it; clue
> injections are solicited.]
>
>
>
> Thomas Informational Expires July 2001 5
>
> Requirements for Content Distribution January 2001
>
>
> [Ed: Metric has also been proposed as an attribute, but the
> editor lacks sufficient understanding to describe it; clue
> injections are solicited.]
>
>
> 7. Phase III Distribution Confirmation
>
> In the final phase, the content destination accepts or rejects the
> distribution request. [Ed: There has some been some discussion about
> partial acceptance, e.g. only for a limited time or only a limited
> capacity, but the editor does not (yet?) sense a consensus that such
> a response is practical or useful.]
>
>
> 8. Security Considerations
>
> To be provided.
>
>
> 9. References
>
>
> 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
> 9, RFC 2026, October 1996.
>
> 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement
> Levels", BCP 14, RFC 2119, March 1997
>
>
>
> 10. Acknowledgments
>
> To be provided.
>
>
> 11. Author's Addresses
>
> Stephen Thomas
> TransNexus, Inc.
> 1140 Hammond Drive, Building E
> Suite 5250
> Atlanta, GA 30328
> Phone: +1 770 671 1888
> Email: stephen.thomas@transnexus.com
>
>
>
>
>
>
>
>
>
>
> Thomas Informational Expires July 2001 6
>
> Requirements for Content Distribution January 2001
>
>
>
> Full Copyright Statement
>
> "Copyright (C) The Internet Society (date). All Rights Reserved.
> 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
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Thomas Informational Expires July 2001 7
>