draft-ietf-ieprep-domain-req-03.txt   draft-ietf-ieprep-domain-req-04.txt 
Internet Engineering Task Force Ken Carlberg Internet Engineering Task Force Ken Carlberg
Oct 19, 2004 Feb 4, 2005
Emergency Telecommunications Services (ETS) Requirements Emergency Telecommunications Services (ETS) Requirements
for a Single Administrative Domain for a Single Administrative Domain
<draft-ietf-ieprep-domain-req-03.txt> <draft-ietf-ieprep-domain-req-04.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 subject to all provisions
all provisions of Section 10 of [rfc3668]. of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
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
groups may also distribute working documents as Internet-Drafts. other 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
http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft http://www.ietf.org/ietf/1id-abstracts.txt.
Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
For potential updates to the above required-text see:
http://www.ietf.org/ietf/1id-guidelines.txt
IPR Disclosure Acknowledgement
By submitting this Internet-Draft, I certify that any applicable The list of Internet-Draft Shadow Directories can be accessed at
patent or other IPR claims of which I am aware have been disclosed, http://www.ietf.org/shadow.html.
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
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
[rfc3689] and focuses on a more specific set of administrative [rfc3689] and focuses on a more specific set of administrative
constraints and scope. Solutions to these requirements are not constraints and scope. Solutions to these requirements are not
presented in this 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 over-provisioning, while others
favored specific schemas to provide a quantifiable measure of have 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
administrative control of the resources plays a significant role in administrative control of the resources plays a significant role in
the effectiveness of any proposed solution. Specifically, if one the effectiveness of any proposed solution. Specifically, if one
administers a set of resources, a wide variety of approaches can be administers a set of resources, a wide variety of approaches can be
deployed upon that set. However, once the approach crosses an deployed upon that set. However, once the approach crosses an
administrative boundary, its effectiveness comes into question, and administrative boundary, its effectiveness comes into question, and
at a minimum requires cooperation and trust from other administrative at a minimum requires cooperation and trust from other administrative
domains. To avoid this question, we constrain our scenario to the domains. To avoid this question, we constrain our scenario to the
resources within a single domain. resources within a single domain.
skipping to change at page 3, line 21 skipping to change at page 3, line 18
[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
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 administrative domain. As in the
case of [rfc3689], the requirements articulated in this document case of [rfc3689], the requirements articulated in this document
represent aspects to be taken into consideration when solutions are represent aspects to be taken into consideration when solutions are
being designed, specified, and deployed. Key words such as "MUST", being designed, specified, and deployed. Key words such as "MUST",
"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 [rfc2119]. 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
skipping to change at page 3, line 47 skipping to change at page 3, line 44
QoS mechanisms are also within the scope of this document. These QoS mechanisms are also within the scope of this document. These
mechanisms may reside at the application, transport, or IP network mechanisms may reside at the application, transport, or IP network
layer. While QoS mechanisms may exist at the link/physical layer, layer. While QoS mechanisms may exist at the link/physical layer,
this document would only consider potential mappings of labels or this document would only consider potential mappings of labels or
code points. code points.
Finally, since this document focuses on a single administrative Finally, since this document focuses on a single administrative
domain, we do not make any further distinction between transit and domain, we do not make any further distinction between transit and
stub domains within this document. stub domains within this document.
2.1 Out of Scope: 2.1 Out of Scope
Resources owned or operated by other administrative authorities are Resources owned or operated by other administrative authorities are
outside the scope of this document. One example are SIP servers that outside the scope of this document. One example are SIP servers that
operate in other domains. Another example are access links operate in other domains. Another example are access links
connecting the stub domain and its provider. Controling only 1/2 of connecting the stub domain and its provider. Controlling only 1/2 of
a link (the egress traffic from the stub) is considered insufficient a link (the egress traffic from the stub) is considered insufficient
for including inter-domain access links as a subject for this for including inter-domain access links as a subject for this
document. document.
3. Requirements 3. Requirements
It must be understood that all of the following requirements pertain It must be understood that all of the following requirements pertain
to mechanisms chosen by a domain's administrative authority to to mechanisms chosen by a domain's administrative authority to
specifically support ETS. If that authority chooses not to support specifically support ETS. If that authority chooses not to support
ETS or if these mechanisms exist within the domain exclusively for a ETS or if these mechanisms exist within the domain exclusively for a
skipping to change at page 4, line 43 skipping to change at page 4, line 40
Proxies MAY set ETS labels on behalf of the source of a flow. This Proxies MAY set ETS labels on behalf of the source of a flow. This
may involve removing labels that have been set by upstream node(s). may involve removing labels that have been set by upstream node(s).
If proxies take such action, then the security measures discussed in If proxies take such action, then the security measures discussed in
[2] MUST be considered. More discussion about security in the single [2] MUST be considered. More discussion about security in the single
domain context is discussed in section 5. domain context is discussed in section 5.
3.3 QoS mechanisms 3.3 QoS mechanisms
Quality of Service (QoS) mechanisms, at either the network or Quality of Service (QoS) mechanisms, at either the network or
application layer, SHOULD be used when networks cannot be application layer, SHOULD be used when networks cannot be over-
overprovisioned to satisfy high bursts of traffic load. Examples can provisioned 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 over-
overprovisioning can be a topic of debate. More indepth discussion provisioning can be a topic of debate. More in-depth discussion on
on this topic is presented in the companion Framework document of this topic is presented in the companion Framework document of
[frame]. [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
skipping to change at page 6, line 14 skipping to change at page 6, line 11
also be considered under such stressed conditions. Further, a also be considered under such stressed conditions. Further, a
measure of degraded service may also be desirable to ensure a measure measure of degraded service may also be desirable to ensure a measure
of communication versus none. These services may be made available of communication versus none. These services may be made available
at the network or application layer. at the network or application layer.
4.2 Redundancy 4.2 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 administrators,
it can be assumed that administrative domains apply this approach in and it can be assumed that administrative domains apply this approach
various degrees to there own resources. in 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 review and follow the comments
comments & requirements about security presented in [2]. Having said and requirements about security presented in [rfc3689]. 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 can be problematic when domains The disparity in security policy can be problematic when domains
offer services other than best effort for ETS users. Therefore, any offer services other than best effort for ETS users. Therefore, any
support within a domain for ETS should be accompanied by a detailed support within a domain for ETS should be accompanied by a detailed
security policy for users and administrators. security policy for users and administrators.
Given the "SHOULD" statement in section 3.8 concerning MIBs, there
are a number of related security considerations that need to be
brought to attention to the reader. Specifically,
- Most current deployments of SNMP are of versions prior to
SNMPv3, even though there are well-known security
vulnerabilities in those versions of SNMP.
- SNMP versions prior to SNMPv3 cannot support cryptographic
security mechanisms. Hence, any use of SNMP prior to
version 3 to write or modify MIB objects do so in a
non-secure manner. As a result, it may be best to constrain
the use of these objects to read-only by MIB managers.
- Finally, any MIB defining writable objects should carefully
consider the security implications of an SNMP compromise on
the mechanism(s) being controlled by those writable MIB
objects.
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
initial version of this draft. previous versions of this draft.
7. References 7. References
7.1 Normative Reference 7.1 Normative Reference
[rfc3668] Bradner, S., "Intellectual Property Rights in IETF [rfc3668] Bradner, S., "Intellectual Property Rights in IETF
technology", BCP 79, RFC 3668, February 2004 technology", BCP 79, RFC 3668, February 2004
7.2 Informative References 7.2 Informative References
[rfc3689] Carlberg, K., Atkinson, R., "General Requirements for [rfc3689] Carlberg, K., Atkinson, R., "General Requirements for
Emergency Telecommunications Service", RFC3689 Emergency Telecommunications Service", RFC3689
Feb 2004 Feb 2004
[rfc2119] Bradner, S., "Key words for use in RFCs to Indicate [rfc2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997. Requirement Levels", RFC 2119, March 1997.
[frame] Carlberg, K., "A Framework for Supporting ETS in Stub [frame] Carlberg, K., "A Framework for Supporting ETS in Stub
Domains", Internet Draft, Work in Progress, Domains", Internet Draft, Work in Progress,
draft-ieprep-domain-frame-02.txt, June 2003. draft-ieprep-domain-frame-02.txt, June 2003.
 End of changes. 

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