One document matched: draft-baker-tsvwg-mlef-concerns-00.txt
Network Working Group F. Baker
Internet-Draft J. Polk
Expires: May 31, 2004 Cisco Systems
December 2003
MLEF Considered Harmful
draft-baker-tsvwg-mlef-concerns-00
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 May 31, 2004.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
The Defense Information Systems Agency of the United States
Department of Defense, with is contractors, has proposed a service
architecture for military (NATO and related agencies) telephone
systems. This is called the Assured Service, and is defined in two
documents: "Architecture for Assured Service Capabilities in Voice
over IP" and "Requirements for Assured Service Capabilities in Voice
over IP". Responding to these are four documents: "Reason Header
Field for the Session Initiation Protocol", "Extending the Session
Initiation Protocol Reason Header to account for Preemption Events",
"Communications Resource Priority for the Session Initiation
Protocol", and the "Multi-Level Expedited Forwarding Per Hop
Behavior" (MLEF PHB). MLEF, as currently defined, has serious
Baker & Polk Expires May 31, 2004 [Page 1]
Internet-Draft MLEF Considered Harmful December 2003
problems, which this draft seeks to discuss.
Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Multi-Level Preemption and Precedence . . . . . . . . . . . . 3
1.2 Multi-Level Expedited Forwarding . . . . . . . . . . . . . . . 5
2. The problem with MLEF . . . . . . . . . . . . . . . . . . . . 6
2.1 Codecs are not infinitely resilient to loss . . . . . . . . . 7
2.2 Issues with variable rate codecs . . . . . . . . . . . . . . . 7
2.3 Packet loss happens in emergency situations . . . . . . . . . 8
2.4 Packet loss happens in tactical situations . . . . . . . . . . 9
2.5 MLEF induced loss triggers congestive collapse . . . . . . . . 9
2.6 MLEF gives no preemption feedback notification . . . . . . . . 10
3. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 11
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . 18
Baker & Polk Expires May 31, 2004 [Page 2]
Internet-Draft MLEF Considered Harmful December 2003
1. Overview
The Defense Information Systems Agency of the United States
Department of Defense, with is contractors, has proposed a service
architecture for military (NATO and related agencies) telephone
systems. This is called the Assured Service, and is defined in two
documents: "Architecture for Assured Service Capabilities in Voice
over IP" [5] and "Requirements for Assured Service Capabilities in
Voice over IP" [6]. Responding to these are four documents: "Reason
Header Field for the Session Initiation Protocol" [3], "Extending the
Session Initiation Protocol Reason Header to account for Preemption
Events" [2], "Communications Resource Priority for the Session
Initiation Protocol" [4], and the "Multi-Level Expedited Forwarding
Per Hop Behavior" [7] (MLEF PHB). MLEF, as currently defined, has
serious problems, which this draft seeks to discuss.
1.1 Multi-Level Preemption and Precedence
Before doing so, however, let us discuss the problem that MLEF is
intended to solve and the architecture of the system. The Assured
Service is designed as an IP implementation of an existing ITU-T/
NATO/DoD telephone system architecture known as Multi-Level
Precedence and Preemption [12][13][14], or MLPP. MLPP is an
architecture for a prioritized call handling service such that in
times of emergency in the relevant NATO and DoD commands, the
relative importance of various kinds of communications is strictly
defined, allowing higher priority communication at the expense of
lower priority communications. These priorities, in descending order,
are:
Flash Override Override: used by the Commander in Chief, Secretary of
Defense, and Joint Chiefs of Staff, Commanders of combatant
commands when declaring the existence of a state of war.
Flash Override: used by Commander in Chief, Secretary of Defense, and
Joint Chiefs of Staff, Commanders of combatant commands when
declaring the existence of a state of war.
Flash: reserved generally for telephone calls pertaining to command
and control of military forces essential to defense and
retaliation, critical intelligence essential to national survival,
conduct of diplomatic negotiations critical to the arresting or
limiting of hostilities, dissemination of critical civil alert
information essential to national survival, continuity of federal
government functions essential to national survival, fulfillment
of critical internal security functions essential to national
survival, or catastrophic events of national or international
significance.
Baker & Polk Expires May 31, 2004 [Page 3]
Internet-Draft MLEF Considered Harmful December 2003
Immediate: reserved generally for telephone calls pertaining to
situations that gravely affect the security of national and allied
forces, reconstitution of forces in a post-attack period,
intelligence essential to national security, conduct of diplomatic
negotiations to reduce or limit the threat of war, implementation
of federal government actions essential to national survival,
situations that gravely affect the internal security of the
nation, Civil Defense actions, disasters or events of extensive
seriousness having an immediate and detrimental effect on the
welfare of the population, or vital information having an
immediate effect on aircraft, spacecraft, or missile operations.
Priority: reserved generally for telephone calls requiring
expeditious action by called parties and/or furnishing essential
information for the conduct of government operations.
Routine: designation applied to those official government
communications that require rapid transmission by telephonic means
but do not require preferential handling.
The rule, in MLPP, is that more important calls override less
important calls. MLPP is built as a proactive system in which callers
must assign one of the precedence levels listed above at call
initiation; this precedence level cannot be changed throughout that
call. If there is end to end capacity to place a call, any call may
be placed at any time. However, when any trunk (in the circuit world)
or interface (in an IP world) reaches utilization capacity, a choice
must be made as to which call continues. The system will seize the
trunks or bandwidth necessary to place the more important calls in
preference to less important calls by preempting an existing call (or
calls) of lower precedence to permit a higher precedence call to be
placed.
More than one call might properly be preempted if more trunks or
bandwidth is necessary for this higher precedence call. A video call
(perhaps of 384 KBPS, or 6 trunks) is a good example of this
situation. This is occurs when the called handset is in use (the
general calls the colonel, who at the time is talking with the
captain), or may be used to clear a circuit (all circuits are busy,
but a lower precedence call may be cleared to create room for the
higher precedence call). When preemption happens, each preempted
speaker will hear an audible tone indicating they have just been
preempted. In this example, the colonel and the captain will each
hear a audible tone indicating s/he must hang up; upon doing so, the
colonel will receive the incoming call from the general.
Baker & Polk Expires May 31, 2004 [Page 4]
Internet-Draft MLEF Considered Harmful December 2003
1.2 Multi-Level Expedited Forwarding
The Differentiated Services Architecture [9] defines a capability for
systems to identify traffic they originate or qualify using
Differentiated Services Code Points [8]. These DSCP values trigger
the application of a policy in the network called a Per Hop Behavior,
or PHB.
Multi-Level Expedited Forwarding (MLEF PHB) builds on the Expedited
Forwarding [11] PHB (EF). Like EF, it posits that sufficient
bandwidth is present to support the service, and therefore places
correctly marked traffic into a low jitter queue, with a form of
traffic policing at the ingress to the network. It differs from EF in
that it marks VoIP traffic with five separate code points
corresponding to the various MLPP precedence levels, which are
presumed to have different loss probabilities comparable to the
behavior of the Differentiated Services Assured Service [10] (AF).
The intended effect is to permit a higher precedence call to reduce
the service level of a lower precedence call by causing it to delay
and potentially drop packets. It assumes that the loss rate is in
fact nominal, or that the users of lower precedence calls will simply
go away when their call quality fades.
Baker & Polk Expires May 31, 2004 [Page 5]
Internet-Draft MLEF Considered Harmful December 2003
2. The problem with MLEF
The problem with MLEF, in a nutshell, is that it implements a
different service than MLPP, and that service has a very different
effect. The basic function of MLPP is to cause some number of lower
precedence calls to be dropped, or not started, so that
o higher precedence calls get placed, and
o the remaining lower precedence calls stay at good quality.
MLEF fails to achieve the second function. Instead, MLEF can create a
situation where all lower precedence calls become unintelligible,
thus destroying most of the usefulness of the communications system.
ETSI TIPHON [16] considers a MOS/PESQ score below 3.6 to be "poor"
and a MOS score below 3.1 to be "bad". The effect of MLEF is to
disrupt voice quality (reduce MOS/PESQ scores below 3.6 and at times
below 3.1) on all calls at routine precedence and potentially other
calls at the Priority or Immediate precedence, causing their users to
be unable to conduct their business or to do so with great
difficulty.
The logical expectation of a military caller, who understands the
behavior of MLPP, who cannot place a call or whose call is clearly
preempted is that he or she will do something different and retry
later. The logical expectation of a caller who experiences degraded
voice quality is not that they will hang up and go away, however. In
a time of crisis, the rational expectation is that they will attempt
to continue using the service, or will hang up and call again fairly
quickly, since they have no (MLPP-like) audible signal indicating
that their call was preempted by lack of available bandwidth, and
since they are operating in a time of adversity. For all lower
precedence calls, MLEF creates congestive collapse - 100% utilization
with zero effectiveness of communication for all calls of a certain
class.
Within MLEF, there is a belief that congestion occurrences will
always be brief in time; that it is better to have momentary
interruptions in service (similar to cell phone service) than out
right preemption events (where both parties are informed of the event
audibly). No accounting or analysis has been done to show that
congestion events in times military emergency will be milliseconds to
seconds long (analogous to cell phone quality service), verses
seconds to minutes (or even hours) long. The existence of the MLPP
service itself argues against this assumption; if congestion was
routinely momentary, then returning a fast busy and expecting the
calling party to call again would be sufficient.
Baker & Polk Expires May 31, 2004 [Page 6]
Internet-Draft MLEF Considered Harmful December 2003
It is possible that, in an MLEF world, the commander in chief might
give the order to "launch the fleet", but the fleet be unable to
place the order to "raise the anchor", as the latter order is given
by a more junior officer whose call precedence level may be
disrupted. It is reported that exactly such an occurrence once
happened in the Swedish Navy, with the result that a ship ordered to
immediately put to sea took its pier with it. More disastrous results
are possible, along with attendant loss of lives. This is not an
academic concern, and he who argues that it is not relevant argues
with mathematics, not opinion.
2.1 Codecs are not infinitely resilient to loss
The issue of concern results from the nature of real time traffic and
the effect of packet loss on known codecs.
One of the world's most common and well known codecs is G.711; it is
the codec used in standard circuit switch voice networks throughout
the PSTN. Numerous studies [15][16][17][18][19] exist depicting the
effect of traffic loss on G.711 in ATM and IP packet switched
environments. While they differ in the details of their findings,
they generally agree that a random packet loss rate on the order of
1-2% has a serious effect on voice quality, and higher packet loss
rates essentially place speech beyond comprehension by the human
listener. ETSI TIPHON [16] states that "the packet loss rate of 5%
seems to be almost the quality threshold (low boundary) of the
''poor' QoS class", which is to say the boundary between "poor, where
most users find it disruptive, and "bad", where all users find it
disruptive.
The resilience of G.729A and the Internet Low Bit Rate Codec [1]
(ILBC) have also been studied [20]. G.729A is another common VoIP
codec, which provides a lower amount of generated bandwidth and has
better resilience than G.711. ILBC generates a bandwidth between
G.729A and G.711, but includes with that traffic a variable quantity
of forward error correction data, which can be used in lossy
environments to further improve voice quality in the presence of
loss. However, like G.711, these codecs also have limits on their
resilience. In the presence of 15% loss, the ILBC reportedly loses
enough voice quality that it can be difficult to understand what it
said.
2.2 Issues with variable rate codecs
G.729A and ILBC are examples of codexs which increase their
throughput to carry forward error correction data when they are
experiencing loss, a behavior referred to as "protection coding".
This behavior - increasing offered load in situations where offered
Baker & Polk Expires May 31, 2004 [Page 7]
Internet-Draft MLEF Considered Harmful December 2003
load may be triggering the problem - has an additional characteristic
that will interact poorly with MLEF. Understand that this is not a
criticism of the codecs per se; as far as we know, the codecs are
fine codecs. But this characteristic has a serious side-effect.
ILBC generates on the order of 31.2 KBPS of traffic under normal
situations. However, in response to RTCP reports of a high level of
loss, it increases its Forward Error Correction, expanding the
bandwidth of the packets to meet acceptable voice quality to the
receiving end. This expanding bandwidth feature of iLBC is the result
of piggybacking additional copies of what it calls critical voice
samples in other packets of other voice samples (this is how the
bandwidth increases - the effective payload for a series of packets
increases by a factor of 2). ILBC with protection will increase its
bandwidth requirements from the no protection rate of 31.2 KBPS to
35.6 KBPS in times of a packet loss rate of 26%. ILBC further
increases its bandwidth requirement to 45.6 KBPS (to raise a PESQ-MOS
value from 2.38 to 3.0) in times where 30% of packets are lost.
Thus, in any situation where a codec using protection coding
experiences difficulty due to lack of available bandwidth in an MLEF
service discipline, it can be expected to compound the difficulty.
2.3 Packet loss happens in emergency situations
While MLEF protects flows for highest priority calls, it worsens the
quality of service for all others.
Telephone systems are generally provisioned with enough bandwidth for
10% or less of their customers or potential users to simultaneously
place calls. In a small office with 250 persons in it, this means
that the ISDN access to the PSTN is often a single T-1 line, and for
larger offices a corresponding level of bandwidth is generally
available. If an Internet connection is enough bandwidth for 20 VoIP
sessions, the simultaneous placement of 20 calls represents a 100%
load that should be carried with at most nominal loss, but 21 calls
represents a ~5% overload, and ~5% data loss may be expected to be
distributed evenly over all calls; in other words, each call may be
expected to experience 5% loss. Thus, in such a case, the placement
of a single call may be the difference between 20 routine calls
operating normally and 21 calls operating with a seriously degraded
MOS score. In larger installations, corresponding ratios apply. In a
network which protects some calls from loss, there is no magic: the
total loss will be the same, and will be concentrated on those calls
least protected.
In emergency situations, especially in command and control centers
such as the US Pentagon, a situation where the center is under attack
Baker & Polk Expires May 31, 2004 [Page 8]
Internet-Draft MLEF Considered Harmful December 2003
or where the command is given to go to war can easily result in a
high percentage of the senior staff needing to place such calls.
Under such cases, even calls at the "Priority" or "Immediate"
precedence level would be adversely affected.
2.4 Packet loss happens in tactical situations
MLEF is being considered in tactical deployments such as WIN-T, and
faces the same kinds of concerns. In radio environments, and in
mobile networks, a certain level of loss is normal. However, due to
the heavy demands of encryption, bandwidth is usually limited. Any
tactical situation which would place a large number of soldiers on
the telephone simultaneously can be expected to result in congestive
loss.
2.5 MLEF induced loss triggers congestive collapse
The fundamental effect of non-negligible loss of traffic in a
precedence class, therefore, is the disruption of all calls in that
precedence class, especially if protection-based codecs are in use.
This is, definitively, congestive collapse - 100% utilization with
zero effectiveness of communication for all calls of a certain class.
When a call experiences congestion when MLEF is in use, the iLBC
codec (taking one example analyzed in [20]) will start replicating
voice samples to include in other RTP payload packets (increasing the
bandwidth required for just that one call. This will further congest
the network, causing iLBC to add more voice samples to other RTP
payloads in other packets, further congesting the network. If a
substantial number of calls in the same MLPP precedence level are
performing this same codec protection function, the network bandwidth
grows exponentially within that MLPP precedence level. This will
cause, as mentioned before, all calling parties within a MLPP level
to experience packet loss, disrupting or destroying the ability to
communicate, with no preemption indication to anyone party. Existing
behavior would be to hang up and try again (because MLPP domain
personnel are trained to recognize a preemption event and know that
the system is experiencing congestion due to some emergency. There is
no such indication, so it is reasonable to conclude that some or most
calling parties will merely hang up and try again. The problem at
this point is that MLEF does not (and cannot) provide feedback to
application layer multimedia signaling protocols to inform those
protocols that a new call attempt is not such a good idea; nor will
there be anything to prevent a new call from being set up to the
previous party (provided there is enough bandwidth available for
signaling packets within the network through some mechanism such as
CBWFQ. With the new call set up, and the network too congested to
transmit enough media packets end-to-end, no calls within that MLPP
Baker & Polk Expires May 31, 2004 [Page 9]
Internet-Draft MLEF Considered Harmful December 2003
level will function properly, and no one will receive the proper
feedback as to what is occurring.
2.6 MLEF gives no preemption feedback notification
One attribute of the current MLPP service is that when a user's call
is preempted, the user is told, via an audible signal, of the event.
In such a case, the user can be expected to find other tasks for a
period of time and try again later. However, that is not a typical
human response - especially the response of a human in an agitated
state of mind - in response to a noisy connection. The more typical
response is to hope that the circuit will improve as others vacate
their calls, or to hang up and call again in an attempt to "get
another circuit". As such, the MLEF PHB fails to signal to the user
that sufficient bandwidth is simply not available to support his
call, so that the user can be expected to respond to the situation in
a different way. There are three ways this can fail:
o If a call is placed when there is insufficient bandwidth, the
system does not give definitive feedback,
o If another call is started which consumes bandwidth, the bandwidth
for this call is reduced, but there is no signal indicating that
o If policy is changed during a call, resulting in the necessity to
drop one or more calls, there is no signal.
A measurement-based counterpart to the MLPP procedure has been
proposed, in which calls experiencing significant loss treat this as
a signal from the network and drop the call. But if all calls at a
precedence level are experiencing loss, many and perhaps all calls at
the precedence level would be dropped by this heuristic; if many
calls are vying for service, the effect would be rolling call
disruption - a set of calls would be established, additional calls
would be established disrupting that class of calls, many of the
disrupted calls would drop, and then more of the competing calls
would be established - only to be disrupted when the first set
redialed.
Baker & Polk Expires May 31, 2004 [Page 10]
Internet-Draft MLEF Considered Harmful December 2003
3. Recommendation
Considering the nature of real-time traffic and the effect of packet
loss on known codecs, it is clear that degradation of voice quality
in an MLEF environment for lower precedence calls will be severe.
Even the advances in codec technology do not fix the problem.
With all due respect to the engineers who have worked on designing
and developing the DISA Assured Service and MLEF, the authors cannot
in good conscience recommend its deployment as it stands. It will
protect the calls placed by senior officers and constitutional
officials, but it does not provide the same service that MLPP
provides to those who respond to their orders, and therefore
seriously impinges on the likelihood that those orders will be
correctly disseminated and carried out. Considering the environment
this proposed mechanism is for, the potential attractiveness for
other environments, and that the effects could and should compound
upon themselves, the worst case scenario includes loss of life due to
communications failure. Nothing done here should enhance this
possibility.
Baker & Polk Expires May 31, 2004 [Page 11]
Internet-Draft MLEF Considered Harmful December 2003
4. IANA Considerations
IANA is not called upon to do anything with this document.
If this document is published as an RFC, the RFC Editor should remove
this section during the process of publication.
Baker & Polk Expires May 31, 2004 [Page 12]
Internet-Draft MLEF Considered Harmful December 2003
5. Security Considerations
This document exposes a problem, but it proposes neither a protocol
nor a procedure. As such, it does not directly affect the security of
the Internet.
Baker & Polk Expires May 31, 2004 [Page 13]
Internet-Draft MLEF Considered Harmful December 2003
6. Acknowledgements
This document was developed with the knowledge and input of many
people, far too numerous to be mentioned by name. Key contributors of
thoughts include, however, Francois Le Faucheur, Haluk Keskiner, Mike
Tibodeau, Pete Babendreier, Rohan Mahy, Scott Bradner, Scott
Morrison, and Subha Dhesikan.
Baker & Polk Expires May 31, 2004 [Page 14]
Internet-Draft MLEF Considered Harmful December 2003
References
[1] Andersen, S., "Internet Low Bit Rate Codec",
draft-ietf-avt-ilbc-codec-03 (work in progress), October 2003.
[2] Polk, J., "Extending the Session Initiation Protocol Reason
Header to account for Preemption Events",
draft-polk-sipping-reason-header-for-preemption-00 (work in
progress), October 2003.
[3] Oran, D., Schulzrinne, H. and G. Camarillo, "The Reason Header
Field for the Session Initiation Protocol",
draft-ietf-sip-reason-01 (work in progress), May 2002.
[4] Schulzrinne, H. and J. Polk, "Communications Resource Priority
for the Session Initiation Protocol (SIP)",
draft-ietf-sip-resource-priority-01 (work in progress), July
2003.
[5] Pierce, M. and D. Choi, "Architecture for Assured Service
Capabilities in Voice over IP",
draft-pierce-ieprep-assured-service-arch-01 (work in progress),
June 2003.
[6] Pierce, M. and D. Choi, "Requirements for Assured Service
Capabilities in Voice over IP",
draft-pierce-ieprep-assured-service-req-01 (work in progress),
June 2003.
[7] Silverman, S., "Multi-Level Expedited Forwarding Per Hop
Behavior (MLEF PHB)", draft-silverman-diffserv-mlefphb-02 (work
in progress), July 2003.
[8] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of
the Differentiated Services Field (DS Field) in the IPv4 and
IPv6 Headers", RFC 2474, December 1998.
[9] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W.
Weiss, "An Architecture for Differentiated Services", RFC 2475,
December 1998.
[10] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, "Assured
Forwarding PHB Group", RFC 2597, June 1999.
[11] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J.,
Courtney, W., Davari, S., Firoiu, V. and D. Stiliadis, "An
Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March
2002.
Baker & Polk Expires May 31, 2004 [Page 15]
Internet-Draft MLEF Considered Harmful December 2003
[12] International Telecommunications Union, "Multilevel Precedence
and Preemption Service (MLPP)", ITU-T Recommendation I.255.3,
1990.
[13] American National Standards Institute, "Telecommunications -
Integrated Services Digital Network (ISDN) - Multi-Level
Precedence and Preemption (MLPP) Service Capability", ANSI
T1.619-1992 (R1999), 1992.
[14] American National Standards Institute, "MLPP Service Domain
Cause Value Changes", ANSI ANSI T1.619a-1994 (R1999), 1990.
[15] Viola Networks, "Netally VoIP Evaluator", January 2003, <http:/
/www.sygnusdata.co.uk/white_papers/viola/
netally_voip_sample_report_preliminary.pdf>.
[16] ETSI Tiphon, "ETSI Tiphon Temporary Document 64", July 1999,
<http://docbox.etsi.org/tiphon/tiphon/archives/1999/
05-9907-Amsterdam/14TD113.pdf>.
[17] Nortel Networks, "Packet Loss and Packet Loss Concealment",
2000, <http://www.nortelnetworks.com/products/01/succession/es/
collateral/tb_pktloss.pdf>.
[18] Clark, A., "Modeling the Effects of Burt Packet Loss and
Recency on Subjective Voice Quality", 2000, <http://
www.telchemy.com/references/tech_papers/iptel2001.pdf>.
[19] Cisco Systems, "Understanding Codecs: Complexity, Hardware
Support, MOS, and Negotiation", 2003, <http://www.cisco.com/en/
US/tech/tk652/tk701/
technologies_tech_note09186a00800b6710.shtml#mos>.
[20] Chen, M. and M. Murthi, "On The Performance Of ILBC Over
Networks With Bursty Packet Loss", July 2003.
Authors' Addresses
Fred Baker
Cisco Systems
1121 Via Del Rey
Santa Barbara, California 93117
USA
Phone: +1-408-526-4257
Fax: +1-413-473-2403
EMail: fred@cisco.com
Baker & Polk Expires May 31, 2004 [Page 16]
Internet-Draft MLEF Considered Harmful December 2003
James Polk
Cisco Systems
2200 East President George Bush Turnpike
Richardson, Texas 75082
USA
Phone: +1-469-255-5208
EMail: jmpolk@cisco.com
Baker & Polk Expires May 31, 2004 [Page 17]
Internet-Draft MLEF Considered Harmful December 2003
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2003). 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 languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
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
Baker & Polk Expires May 31, 2004 [Page 18]
Internet-Draft MLEF Considered Harmful December 2003
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Baker & Polk Expires May 31, 2004 [Page 19]
| PAFTECH AB 2003-2026 | 2026-04-23 20:16:39 |