draft-ietf-ieprep-domain-req-01.txt   draft-ietf-ieprep-domain-req-02.txt 
Internet Engineering Task Force Ken Carlberg Internet Engineering Task Force Ken Carlberg
June 9, 2004 Sept 21, 2004
ETS Requirements for a Single Administrative Domain Emergency Telecommunications Services (ETS) Requirements
<draft-ietf-ieprep-domain-req-01.txt> for a Single Administrative Domain
<draft-ietf-ieprep-domain-req-02.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 [rfc3668].
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
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
skipping to change at page 1, line 36 skipping to change at page 1, line 37
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
For potential updates to the above required-text see: For potential updates to the above required-text see:
http://www.ietf.org/ietf/1id-guidelines.txt http://www.ietf.org/ietf/1id-guidelines.txt
Abstract Abstract
This document presents a list of requirements in support of Emergency This document presents a list of requirements in support of Emergency
Telecommunications Service (ETS) within a single administrative Telecommunications Service (ETS) within a single administrative
domain. This document is an extension of the General Requirements of domain. This document is an extension of the General Requirements of
[2] and focuses on a more specific set of administrative constraints [rfc3689] and focuses on a more specific set of administrative
and scope. Solutions to these requirements are not presented in this constraints and scope. Solutions to these requirements are not
document. presented in this document.
1. Introduction 1. Introduction
The objective of this document is to define a set of requirements The objective of this document is to define a set of requirements
that support ETS within a single domain. There have been a number of that support ETS within a single domain. There have been a number of
discussions in the IEPREP mailing list, as well as working group discussions in the IEPREP mailing list, as well as working group
meetings, that have questioned the utility of a given mechanism to meetings, that have questioned the utility of a given mechanism to
support ETS. Many have advocated overprovisioning, while others have support ETS. Many have advocated overprovisioning, while others have
favored specific schemas to provide a quantifiable measure of favored specific schemas to provide a quantifiable measure of
service. One constant in these discussions is that the service. One constant in these discussions is that the
skipping to change at page 3, line 13 skipping to change at page 3, line 14
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
meant to be a baseline followed (if necessary) by more specific meant to be a baseline followed (if necessary) by more specific
requirements that pertain to a more narrow scope. requirements that pertain to a more narrow scope.
The requirements presented below in Section 3 are representative of The requirements presented below in Section 3 are representative of
the more narrow scope of a single adminstrative domain. As in the the more narrow scope of a single adminstrative domain. As in the
case of [2], the requirements articulated in this document represent case of [rfc3689], the requirements articulated in this document
aspects to be taken into consideration when solutions are being represent aspects to be taken into consideration when solutions are
designed, specified, and deployed. Key words such as "MUST", "MUST being designed, specified, and deployed. Key words such as "MUST",
NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in [3]. interpreted as described in [rfc2119].
2. Scope 2. Scope
IETF standards that cover the resources within an administrative IETF standards that cover the resources within an administrative
domain are within the scope of this document. This includes domain are within the scope of this document. This includes
gateways, routers, servers, etc., that are located and administered gateways, routers, servers, etc., that are located and administered
within the domain. This document also does not restrict itself to a within the domain. This document also does not restrict itself to a
specific type of application such as Voice over IP. specific type of application such as Voice over IP.
QoS mechanisms are also within the scope of this document. These QoS mechanisms are also within the scope of this document. These
skipping to change at page 4, line 44 skipping to change at page 4, line 45
application layer, SHOULD be used when networks cannot be application layer, SHOULD be used when networks cannot be
overprovisioned to satisfy high bursts of traffic load. Examples can overprovisioned to satisfy high bursts of traffic load. Examples can
involve bridging fiber networks to wireless subnetworks, or remote involve bridging fiber networks to wireless subnetworks, or remote
subnetworks connected over expensive bandwidth constrained wide area subnetworks connected over expensive bandwidth constrained wide area
links. links.
Note well. Over-provisioning is a normal cost-effective practice Note well. Over-provisioning is a normal cost-effective practice
amongst network administrators/engineers. The amount of amongst network administrators/engineers. The amount of
overprovisioning can be a topic of debate. More indepth discussion overprovisioning can be a topic of debate. More indepth discussion
on this topic is presented in the companion Framework document of on this topic is presented in the companion Framework document of
[4]. [frame].
3.4 Users 3.4 Users
Any application layer label mechanisms used to support ETS MUST be Any application layer label mechanisms used to support ETS MUST be
capable of supporting both the set of ETS and non-ETS (presumably, capable of supporting both the set of ETS and non-ETS (presumably,
normal) users. normal) users.
3.5 Policy 3.5 Policy
Policy MUST be used to determine the percentage of resources of a Policy MUST be used to determine the percentage of resources of a
skipping to change at page 6, line 47 skipping to change at page 6, line 47
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 7.1 Normative Reference
1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP [rfc3668] Bradner, S., "Intellectual Property Rights in IETF
9, RFC 2026, October 1996. technology", BCP 79, RFC 3668, February 2004
7.2 Informative References 7.2 Informative References
2 Carlberg, K., Atkinson, R., "General System Requirements for [rfc3689] Carlberg, K., Atkinson, R., "General Requirements for
Emergency Telecommunications Service", Internet Draft, Emergency Telecommunications Service", RFC3689
Work In Progress, September, 2002 Feb 2004
3 Bradner, S., "Key words for use in RFCs to Indicate Requirement [rfc2119] Bradner, S., "Key words for use in RFCs to Indicate
Levels", RFC 2119, March 1997. Requirement Levels", RFC 2119, March 1997.
4 Carlberg, K., "A Framework for Supporting ETS in Stub Domains", [frame] Carlberg, K., "A Framework for Supporting ETS in Stub
Internet Draft, Work in Progress, June 2003. Domains", Internet Draft, Work in Progress,
draft-ieprep-domain-frame-02.txt, June 2003.
8. Author's Addresses 8. IPR Disclosure Acknowledgement
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
9. Author's Addresses
Ken Carlberg Ken Carlberg
G11 G11
123a Versailles Circle 123a Versailles Circle
Baltimore, MD Baltimore, MD
USA USA
carlberg@g11.org.uk carlberg@g11.org.uk
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). This document is subject
This document and translations of it may be copied and furnished to to the rights, licenses and restrictions contained in BCP 78, and
others, and derivative works that comment on or otherwise explain it except as set forth therein, the authors retain all their rights.
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 Disclamer
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided as an This document and the information contained herein are provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OR INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 

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