draft-ietf-ieprep-domain-req-00.txt   draft-ietf-ieprep-domain-req-01.txt 
Internet Engineering Task Force Ken Carlberg Internet Engineering Task Force Ken Carlberg
December 28, 2003 June 9, 2004
ETS Requirements for a Single Administrative Domain ETS Requirements for a Single Administrative Domain
<draft-ietf-ieprep-domain-req-00.txt> <draft-ietf-ieprep-domain-req-01.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1]. all provisions of Section 10 of RFC2026 [1].
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
skipping to change at page 2, line 40 skipping to change at page 2, line 40
Administrative Domain: The collection of resources under the Administrative Domain: The collection of resources under the
control of a single administrative authority. This authority control of a single administrative authority. This authority
establishes the design and operation of a set of resources establishes the design and operation of a set of resources
(i.e., the network). (i.e., the network).
Transit Domain: This is an administrative domain used to forward Transit Domain: This is an administrative domain used to forward
traffic from one domain to another. An Internet Service Provider traffic from one domain to another. An Internet Service Provider
(ISP) is an example of a transit domain. (ISP) is an example of a transit domain.
Stub Domain: This is an administrative domain that is either the Stub Domain: This is an administrative domain that is either the
source or the destination of a flow. As a general rule, it does source or the destination of a flow of IP packets. As a general
not forward traffic that is destined for other domains. The odd rule, it does not forward traffic that is destined for other
exception to this statement is the case of Mobile IP and its domains. The odd exception to this statement is the case of
use of "dog-leg" routing to visiting hosts located in foreign Mobile IP and its use of "dog-leg" routing to visiting hosts
networks. An enterprise network is an example of a stub domain. located in foreign networks. An enterprise network is an example
of a stub domain.
1.1 Previous Work 1.1 Previous Work
A list of General Requirements for support of ETS is presented in A list of General Requirements for support of ETS is presented in
[2]. The document articulates requirements when considering the [2]. The document articulates requirements when considering the
broad case of supporting ETS over the Internet. Since that document broad case of supporting ETS over the Internet. Since that document
is not constrained to specific applications, administrative is not constrained to specific applications, administrative
boundaries, or scenarios, the requirements contained within it tend boundaries, or scenarios, the requirements contained within it tend
to be quite general in their description and scope. This follows the to be quite general in their description and scope. This follows the
philosophy behind its inception in that the General Requirements are philosophy behind its inception in that the General Requirements are
skipping to change at page 5, line 42 skipping to change at page 5, line 42
more specific set of requirements for a particular service may make a more specific set of requirements for a particular service may make a
statement about the following issues. statement about the following issues.
4.1 Alternative Services 4.1 Alternative Services
The form of the service provided to ETS users and articulated in the The form of the service provided to ETS users and articulated in the
form of policies may be realized in one of several forms. Better form of policies may be realized in one of several forms. Better
than best effort is probably the service that most ETS users would than best effort is probably the service that most ETS users would
expect when the communication system is stressed and overall quality expect when the communication system is stressed and overall quality
has degraded. However, the concept of best available service should has degraded. However, the concept of best available service should
also be considered under such conditions. Further, a measure of also be considered under such stressed conditions. Further, a
degraded service may also be desirable to ensure a measure of measure of degraded service may also be desirable to ensure a measure
communication versus none. These services may be made available at of communication versus none. These services may be made available
the network or application layer. at the network or application layer.
4.2 "Emergency" 4.2 "Emergency"
The ITU has migrated away from the term "emergency" and ETS because The ITU has migrated away from the term "emergency" and ETS because
of legal ramifications within the U.K. Apparantly, there is a legal of legal ramifications within the U.K. Apparantly, there is a legal
expectation when the term "emergency" is used as a service. Hence, expectation when the term "emergency" is used as a service. Hence,
the ITU is currently using the term Telecommunications for Disaster the ITU is currently using the term Telecommunications for Disaster
Relief (TDR). Legal issues such as this are outside the scope of Relief (TDR). Legal issues such as this are outside the scope of
this document and the IETF. However, to provide a bridge of this document and the IETF. However, to provide a bridge of
understanding, the reader can assume that ETS within the IETF is understanding, the reader can assume that ETS within the IETF is
synonymous with TDR in the ITU. synonymous with TDR in the ITU -- each involving authorized use of a
service that attempts to compensate for stressed conditions of
resources.
4.3 Redundancy 4.3 Redundancy
The issue of making network fault tolerant is important and yet not The issue of making network fault tolerant is important and yet not
one that can be easily articulated in terms of requirements. one that can be easily articulated in terms of requirements.
Redundancy in connectivity and nodes (be it routers or servers) is Redundancy in connectivity and nodes (be it routers or servers) is
probably the most common approach taken by network adminstrators, and probably the most common approach taken by network adminstrators, and
it can be assumed that administrative domains apply this approach in it can be assumed that administrative domains apply this approach in
various degrees to there own resources. various degrees to there own resources.
5. Security Considerations 5. Security Considerations
This document recommends that readers reviews and follows the This document recommends that readers reviews and follows the
comments & requirements about security presented in [2]. Having said comments & requirements about security presented in [2]. Having said
that, there tends to be many instances where intra-domain security is that, there tends to be many instances where intra-domain security is
held at a lower standard (i.e., less stringent) that inter-domain held at a lower standard (i.e., less stringent) that inter-domain
security. For example, while administrators may allow telnet service security. For example, while administrators may allow telnet service
between resources within an administrative domain, they would only between resources within an administrative domain, they would only
allow SSH access from other domains. allow SSH access from other domains.
The disparity in security policy The disparity in security policy can be problematic when domains
offer services other than best effort for ETS users. Therefore, any
support within a domain for ETS should be accompanied by a detailed
security policy for users and administrators.
6. Acknowledgements 6. Acknowledgements
Thanks to Ran Atkinson, James Polk, and Ian Brown for comments on an Thanks to Ran Atkinson, James Polk, and Ian Brown for comments on an
initial version of this draft. initial version of this draft.
7. References 7. References
7.1 Normative Reference
1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996. 9, RFC 2026, October 1996.
7.2 Informative References
2 Carlberg, K., Atkinson, R., "General System Requirements for 2 Carlberg, K., Atkinson, R., "General System Requirements for
Emergency Telecommunications Service", Internet Draft, Emergency Telecommunications Service", Internet Draft,
Work In Progress, September, 2002 Work In Progress, September, 2002
3 Bradner, S., "Key words for use in RFCs to Indicate Requirement 3 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997. Levels", RFC 2119, March 1997.
4 Carlberg, K., "A Framework for Supporting ETS in Stub Domains", 4 Carlberg, K., "A Framework for Supporting ETS in Stub Domains",
Internet Draft, Work in Progress, June 2003. Internet Draft, Work in Progress, June 2003.
8. Author's Addresses 8. Author's Addresses
Ken Carlberg Ken Carlberg
G11 G11
Gower Street 123a Versailles Circle
London, WC1E 6BT Baltimore, MD
United Kingdom USA
carlberg@g11.org.uk carlberg@g11.org.uk
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/