SIPPING WG R.G. Crespo
Internet-Draft UTL
<draft-cl-sipping-fi-problem-00.txt> L. Logrippo
Intended Status: Informational UQO
Expires April 14, 2009 October 14, 2008
Feature Interactions Problem Statement
<draft-cl-sipping-fi-problem-00.txt>
Status of this Memo
Distribution of this memo is unlimited.
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 becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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.
Abstract
Internet applications have been enhanced with many features.
A feature may be defined as a unit of functionality in a system, having
a self-contained role.
However, the introduction and modification of features may result in
undesired behaviors, and this effect is known as feature interaction-
FI for short.
This document provides a description of the FI problem in Internet, the
main problems to be solved in the FI resolution, and compares some
solutions for FI identification and resolution explored that have been
discussed in the literature.
Crespo & Logrippo Expires April 14, 2009 [Page 1]
FI-Problem Statement October 14, 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions of this document . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. FI detection . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Taxonomies . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Representation schemes . . . . . . . . . . . . . . . . . . 5
2.3. Detection algorithms . . . . . . . . . . . . . . . . . . . 6
3. FI resolution . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Knowledge location . . . . . . . . . . . . . . . . . . . . 7
3.2. Models of relationships between features . . . . . . . . . 7
3.3. Resolution strategies . . . . . . . . . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Author Address . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . . . 12
1. Introduction
The purpose of this draft is to document the Feature Interaction (FI)
problem as it relates to Internet applications. It aims to introduce
the Internet community to the range of the current views and proposed
solutions in this reasearch area. This draft is meant to serve as an
introduction to a companion document Distributed Resolution of
Feature Interactions for Internet Applications, where a specific FI
resolution method is proposed.
The FI problem manifests itself in several distinct aspects, and
these will be classified and documented. There are also three
distinct, but compatible, means of addressing the problem with
multiple techniques within each of these means. These means and
techniques will also be documented.
Internet applications provide a set of basic services. For example,
the Email protocol [4] provides two basic functionalities: sending a
message to another user and reading a message from another user.
Internet applications have been enhanced with many features, each
defined as a unit of functionality existing in a system and each
perceived as having a self-contained role. For example,
ForwardMessage and AutoResponder are popular Email features.
ForwardMessage forwards all incoming Email messages to another user.
AutoResponder reads the incoming message and sends automatically a
notification message to the Email originator, e.g. the recipient is
absent on vacation and will read the message after return.
Crespo & Logrippo Expires April 14, 2009 [Page 2]
FI-Problem Statement October 14, 2008
In feature-based applications, interactions are necessary and
expected occurrences. On a given node, several features and basic
functionalities may be available. Usually a priority order is
implemented among them, with the basic functionalities having the
lowest priority. For example, when an incoming or outgoing message
is generated, which triggers both a feature and a basic
functionality, only the feature is executed.
Features, which work fine alone, may result in undesired behaviors
when interacting with another features, and this effect is known as
feature interaction (FI).
As an example of FI, suppose that Bob instructs the Email server to
execute the ForwardMessage feature, forwarding all messages to Carl.
A message that Alice sends to Bob is sent again to Carl. Suppose
also that Carl subscribes to the AutoResponder feature. The Email
server of Carl accepts Alice message and sends a notification message
to Bob, not to the message originator (Alice). This result goes
against the initial goal of AutoResponder feature, to notify the
originator that Carl is away. The Email server of Bob, when
receiving the notification message, forwards it back to Carl. The
Email server of Carl detects a loop, another undesired behavior, and
discards the notification message.
The FI detection problem, first identified in circuit-switched
networks [5], has been studied in many Internet applications, such as
Email [6], VoIP [7], WWW [8] and networked home appliances [9].
The increasing number of FIs, and the inconvenience they are causing,
has led industry and researchers to identify basic concepts in
feature handling. A Workshop series was created as a forum for
discussing this problem: the Feature Interaction Workshop (FIW),
which has now become the International Conference on Feature
Interaction (ICFI). This series has been going on since 1992 and its
proceedings have been regularly printed by IOS Press. Already at the
2nd International Workshop on Feature Interactions in
Telecommunication Systems three basic concepts were identified: FI
detection, FI avoidance and FI resolution.
* Detection aims at the identification of FIs, with suitable meth-
ods.
* Avoidance means to intervene at the protocol or design stages to
prevent FIs, before features are executed.
* In the resolution, actions are exercised at run time over already
detected FIs to mediate their undesired properties.
Crespo & Logrippo Expires April 14, 2009 [Page 3]
FI-Problem Statement October 14, 2008
The distributed nature of Internet, with multi-vendor and multi-
provider environments, and the end user capability to program and
tailor features, makes it impossible to rely on avoidance. In this
draft we list the main problems encountered in the detection and res-
olution tasks. For each problem, we compare solution approaches
explored so far.
1.1. Conventions of this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL", are to be inter-
preted as described in RFC 2119 [2] and indicate requirement levels
for compliant implementations.
1.2 Terminology
FI: Feature interaction
FOL: First order logic
IETF: Internet Engineering Task Force
IRAdv: Interaction Resolver Adviser
MUMC: Multiple User Multiple Component
MUSC: Multiple User Single Component
STR: State Transition Rule
SUMC: Single User Multiple Component
SUSC: Single User Single Component
TL: Temporal logics
VoIP: Voice over Internet
WWW: World Wide Web
2. FI detection
In the FI detection task two major issues have been studied, FI clas-
sification and FI detection. Algorithms have been designed to solve
these problems.
* FI classification, or taxonomy, groups FIs according to shared
characteristics.
* In FI detection algorithms, a scheme for representing features is
selected and an algorithm identifies feature pairs that are likely
to interact.
2.1. Taxonomies
Several taxonomies have been produced to classify different types of
FI. In the most commonly used benchmark of [10], FIs are classified
Crespo & Logrippo Expires April 14, 2009 [Page 4]
FI-Problem Statement October 14, 2008
by the nature of the interaction, as well by the cause of the inter-
action.
Concerning the nature of the interaction, three dimensions are iden-
tified:
* the number of users involved in the interaction (SU-single user
or MU-multiple user),
* the number of network components involved in the interaction (SC-
single component or MC-multiple component), and
* the kind of features involved in the interaction (custom or sys-
tem).
Causes of FI, listed in [10], are: violation of feature assumptions,
limited network support, and problems in distributed systems. This
list is not complete, and the emergence of new Internet applications
may generate other causes of FIs.
SUSC (Single User, Single Component) feature interactions can occur
when incompatible features are simultaneously in use by one single
user in a single node. As an example of SUSC feature interaction,
suppose that one party subscribes to the AutoResponder and FilterMes-
sage Email features. AutoResponder is described in section 1. Fil-
terMessage screens the message initiator and the message is read only
if the initiator does not belong to a screening list. If Bob sub-
scribes to AutoResponder and FilterMessage features, and Alice is
included to the screening list, her message will be rejected. How-
ever, AutoResponder may send to Alice a notification that Bob is
absent and this outcome is incoherent with the FilterMessage goal.
SUMC (Single User, Multiple Component) feature interactions occur
when features are deployed in different network components. As an
example of SUMC feature interaction, suppose that one party sub-
scribes to the AddressBook and FilterDestination Email features.
AddressBook considers the target address to be an alias, and replaces
it by a real address. FilterDestination screens the message destina-
tion and the message is sent only if the destination does not belong
to a screening list. However, it is possible that the original
address is in the screening list, but not the new one, and the mes-
sage is sent if the feature checks if the destination address is in
the list after translation.
MUSC (Multiple User, Single Component) feature interactions can occur
when several users are involved in several features executing on the
same node. As an example of MUSC feature interaction, suppose that
one party subscribes to the FilterDestination and ForwardMessage
Crespo & Logrippo Expires April 14, 2009 [Page 5]
FI-Problem Statement October 14, 2008
Email features. The FilterDestination is described in the SUMC exam-
ple, and ForwardMessage is described in section 1. Suppose that Bob
subscribes to the ForwardMessage feature, forwarding all incoming
message to Carol. Suppose also that Carol subscribes to FilterDesti-
nation feature, and includes Alice in the filtering list. If Alice
sends an Email message directly to Carol, FilterDestination rejects
the message. However, if Alice sends an Email message to Bob, the
message will be forwarded to Carol and received by her. This outcome
is inconsistent with the goal of the FilterDestination feature.
MUMC (Multiple User, Multiple Component) feature interactions occur
when several users are involved in features executing on different
nodes. As an example of MUSC feature interaction, consider that two
WWW sites [11] implement ForwardMessage to each other. A browser will
continuously change its display between the two sites.
Finally, CUSY feature interactions occur among customer features and
system features for operation, maintenance or administrative ser-
vices. As an example of CUSY feature interaction, consider a Web
analytic center that collects WWW statistics. For page access counts,
should the center consider the WWW site that implements ForwardMes-
sage to another site, or simply the final destination site?
2.2. Representation schemes
FI detection requires the representation of participating features in
some presentation scheme. Beyond FI detection, feature presentation
schemes are also essential for feature development.
Several scheme paradigms are available for feature representation. A
review of several existing presentation schemes is given in [12]. We
have:
* State machines, where the basic system and the features are rep-
resented as separate state machines, in which messages trigger
state changes. This approach is illustrated in [13].
* More sophisticated models capable of providing a global view of
the concurrent execution of different parts of a system and of sev-
eral features working in parallel. Three different such represen-
tations are available in the literature.
* Formally based, with mathematically described semantics.
Example of formal concurrent schemes used for feature represen-
tation are Petri-nets [14] and process algebras such as LOTOS
[15].
* Event based, centered on the events in which features may
Crespo & Logrippo Expires April 14, 2009 [Page 6]
FI-Problem Statement October 14, 2008
participate. In contrast to finite machine presentation
schemes, the internal states of the feature may be invisible
outside the system. Chisel [16] is one example of an event
based presentation scheme, and process algebras [15] are also
capable of representing systems in this way.
* Modeling languages, where state models and imperative lan-
guages are extended with concurrent primitives in order to rep-
resent protocols. Promela [17] is an example of a modeling lan-
guage.
* Logic based, where formal semantics and deduction rules are
available for property identification.
* Temporal Logic (TL) is a choice for logic based presentation
schemes. TL involves operators expressing modalities such as
henceforth and eventually. Varieties of TL adopted for feature
presentation schemes are Linear Temporal Logic [18], Branching
Time Temporal Logic, and Temporal Logic of Actions [19].
* Predicate logics use the concepts of pre-condition and post-
condition of actions. They may be adopted in cases where fea-
tures are triggered by one message, generate a limited number of
messages and the effects of messages are described by pre and
post conditions. The description of state transition rules in
[20] is an example of a presentation scheme based on predicate
logics.
* Informal presentation schemes. Because of their readability, such
schemes have been adopted to complement formal presentation
schemes. For example, Use Case Maps describes scenarios by depict-
ing casual relationships between responsibilities [15].
2.3. Detection algorithms
Research on FI detection as been focused on methods to check if a
pair of features are likely to interact. This can be done by using
one of the many static FI detection algorithms known in the litera-
ture. A review of several existing methods is given in [12]. FI
detection methods adopt property identification, behavior approaches
or both. Properties analyzed in FI detection include inconsistency,
realizability and satisfiability.
We highlight four methods of FI detection.
* Simulation, where execution traces are analyzed to check if unac-
ceptable behaviors may occur. Simulators have been implemented to
simulate feature representations in state machines [21] and
Crespo & Logrippo Expires April 14, 2009 [Page 7]
FI-Problem Statement October 14, 2008
concurrent languages, such as LOTOS [15]. The unacceptable behav-
iors detected by simulators include deadlock, non determinism and
the existence of unreachable states.
* Model checking unfolds the system requirements, described as a
model, into a transition system. The model checker searches for a
path where properties, usually expressed in some type of logic (FOL
or TL), are not satisfied. Model checkers have been implemented
over different model and property languages, such as SPIN [17] with
models expressed by the modeling language Promela and properties
expressed in LTL, and SVAL [22] with models expressed by state
transition rules and properties expressed in FOL.
Although simulation and model checking are conceptually similar,
there are some differences in the implementation. In model check-
ing, the state explosion problem is a major concern. Moreover, in
model checking the properties are expressed over the entire path
while in simulation the properties focus only on the current state.
* Theorem proving, where system properties are formally derived
from the combined feature specifications [23].
* Security based approach reverses the FI detection question to the
following: from one specific feature, what hypothetical features
could cause interaction? [24]
The identification of a hypothetical feature that causes interac-
tion, based on a STR representation of feature [20] requires to
specify the set of every possible predicate the system may satisfy,
the set of every possible message for which the feature may inter-
act, the restrictions that predicate and message parameters must
satisfy, and the inconsistencies revealing a feature interaction.
The hypothetical feature that causes interaction is generated by
inserting the inconsistency at the given feature post condition and
propagating back to the pre condition.
Although these four methods detect candidates for FI, users must
decide if such candidates represent undesirable interactions that
must be resolved. For example, the MUMC feature interaction consist-
ing of mutual ForwardMessage may be acceptable for WWW sites (for
example, to represent a clock) but totally unacceptable for Email.
3. FI resolution
After a message generation, or arrival, several potentially conflict-
ing features may be selected for execution. The FI conflict must be
resolved by deciding which feature can go ahead, possibly with change
of feature parameters.
Crespo & Logrippo Expires April 14, 2009 [Page 8]
FI-Problem Statement October 14, 2008
The implementation of the FI resolution task must solve three main
issues:
* Knowledge displacement, that defines where the control of feature
execution lies and where the FI resolver may collect application
and user statuses.
* What is the model of relationships between features.
* What is the method to resolve FIs between sets of feature candi-
date for execution.
3.1. Knowledge location
The distributed control of Internet implies that feature control must
be exercised solely on the nodes where they are executed.
The application status is expected to be known to the node that
selects the feature to execute, among a set of candidates. However,
more than one node may be involved in the interaction (consider the
case of MC interactions).
User status is expected to be known to the node to which the user is
attached. Yet, more than one user may be involved in an interaction
(consider the case of MU interactions).
Moreover, message transfer from one node to another implies a modifi-
cation of the processing environment for the message, as well as of
the number of features that are selected for message processing.
Therefore, FI resolution cannot be centralized. Node cooperation,
which implies location of the information source and information
exchange between nodes, is mandatory for a FI resolution on Internet
applications that satisfy customer expectations.
3.2. Models of relationships between features
Many models of relationships between features have been proposed.
These models may be classified according to the visibility of rela-
tionships between features.
Relationships between features may be expressed explicitly using
familiar data structures, such as tables [25,26] and trees [27].
Relationships may be implicit, for example expressed by logic formu-
las [28,29].
The relationships between features may not express directly the pos-
sible interactions between features. It is the method that identifies
Crespo & Logrippo Expires April 14, 2009 [Page 9]
FI-Problem Statement October 14, 2008
where FIs occur and, by looking at the relationships between the fea-
tures, the resolution method selects and adapts the features for exe-
cution.
3.3. Resolution strategies
Three approaches have been explored for FI run time resolution [12]:
one phase, two phase and negotiation.
* The one phase approach uses one feature manager to decide which
of several conflicting features is executed, according to data
structures such as tables or trees, or logical formulas.
The table may be used to specify a list of priorities [25], or the
feature manager decides the activation of an additional feature on
the basis of the resulting status of the first feature and the
relationships displayed in the table [26]. Because [25] uses a
stack to express priority relationships between features, relation-
ships between interactions may be modified as result of feature
execution.
Tables can be replaced by state trees, where the features suggest
possible responses and the feature manager rolls back in case of
rejection [25].
The one phase approach suffers from the difficulty of collecting
user status from nodes outside the node processing the message.
* The two phase approach, where the feature is executed in an iso-
lated environment and actions are taken in case of FI [30]. The
isolated environment is impractical in Internet.
* Negotiation approach
Several negotiation approaches have been proposed.
* In the arbitrated approach, the negotiator (frequently desig-
nated as Feature Manager), has the sole responsibility to find a
solution. Features are described as agents and interact with
each other, by posting their intentions to a common tuple space.
The replies, from other features, can be other intentions or
permission/interdiction directives. Negotiation policies
explored include deontic-based ones with obligations and goals
[28], constraint formulas [29], fuzzy policies [31] and rela-
tional assertions [32].
* Indirect negotiation [10], where a dedicated negotiator con-
trols the negotiation and proposes solutions based on
Crespo & Logrippo Expires April 14, 2009 [Page 10]
FI-Problem Statement October 14, 2008
experience. The dedicated negotiator uses a centralized infer-
ence machine to select the feature to be executed from the con-
straints expressed by agents.
* Direct negotiation, where agents negotiate directly without a
negotiator. Direct negotiation based on distributed artificial
intelligence techniques [33] consumes too much processing power
and communication bandwidth. To reduce performance constraints,
several alternatives of directed negotiation have been explored,
such as a prune and extract approach [34] where a solution space
is computed and undesired traces are removed.
Currently there is no evidence of advantages between arbitrated and
direct negotiation approaches.
4. Security Considerations
This document depicts the feature interaction problem and the main
problems to be solved in the FI resolution.
Although this document does not define any protocol, feature interac-
tion may result in unexpected behavior. The unexpected behaviors may
include access to confidential information. For example, consider
that Bob subscribes to DecryptMessage and ForwardMessage Email fea-
tures. Consider also that someone sends to Bob an Email using his
public key. Bob Email server may sucessfully decipher the message,
using his secret key. However, if ForwardMessage is executed after
the execution of DecryptMessage feature, the secret message will be
sent in clear.
5. IANA Considerations
None.
6. Acknowledgements
This document is based on discussions with Tom Gray of PineTel, and
Jacques Sincennes of the University of Ottawa, who contributed sig-
nificantly to the ideas presented here.
7. References
7.1 Normative references
[1] S. Bradner, Intellectual Property Rights in IETF Technology, BCP
79, RFC 3979, March 2005.
[2] S. Bradner, Key words for use in RFCs to Indicate Requirement
Crespo & Logrippo Expires April 14, 2009 [Page 11]
FI-Problem Statement October 14, 2008
Levels, BCP 14, RFC 2119, March 1997.
[3] S. Bradner, IETF Rights in Contributions, BCP 78, RFC 3778, March
2005.
6.2 Informative references
[4] J. Klensin, Simple Mail Transfer Protocol, RFC 5321, October
2008.
[5] T.F. Bowen, F.S. Dworak, C.H. Chow, N.D. Grifeth, G.E. Herman,
S.-J. Lin, The Feature Interaction problem in Telecommuni-
cation Systems, 7th Intl Conference on Software Engineer-
ing for Telecommunication Systems, pp. 59-62, July 1989.
[6] R. Hall, Feature Interactions in Electronic Mail, 6th Intl Work-
shop on Feature Interactions in Telecommunication and
Software Systems, pp. 67-82, May 1998.
[7] J. Lennox, H. Schulzrinne, Feature Interactions in Internet Tele-
phony, 6th Intl Workshop on Feature Interactions in
Telecommunication and Software Systems, pp. 38-50, May
1998.
[8] M. Weiss, Feature Interactions in Web Services, 7th Intl Workshop
on Feature Interactions in Telecommunication and Software
Systems, pp. 149-156, June 2003.
[9] M. Nakamura, Y. Igaki, K.-i. Matsumoto, Feature Interactions in
Integrated Services of Networked Home Appliances, 8th Intl
Conference on Feature Interactions in Telecommunications
and Software Systems, pp. 236-251, 2005.
[10] E.J. Cameron, N. Griffeth, Y.-J. Lin, M.E. Nilson, W.K. Schnure,
A feature interaction benchmark for IN and beyond, 2nd
Intl Conference on Feature Interactions in Telecommunica-
tions Systems, pp. 1-23, May 1994.
[11] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P.
Leach, T. Berners-Lee, Hypertext Transfer Protocol --
HTTP/1.1, RFC 2616, June 1999.
[12] M. Calder, M. Kolberg, E.H. Magill, S. Reiff-Marganiec, Feature
interaction: a critical review and considered forecast,
Computer Networks Vol 41 No 1, pp. 115-141, January 2003.
[13] D. Mery, J.P. Gibson, Telephone feature verification: Translat-
ing SDL to TLA+, 8th SDL forum, pp. 103-118, September
Crespo & Logrippo Expires April 14, 2009 [Page 12]
FI-Problem Statement October 14, 2008
1997.
[14] M. Nakamura, Y. Kakuda,T. Kikuno, Petri-net based detection
method for non-deterministic feature interactions and its
experimental evaluation, 3rd Intl Workshop on Feature
Interactions in Telecommunication Systems, pp. 138-152,
1995.
[15] D. Amyot, L. Charfi, N. Gorse, T. Gray, L. Logrippo, J. Sin-
cennes, B. Stepien, B.T. Ware, Feature description and
feature interaction analysis with Use Case Maps and LOTOS,
6th Intl Workshop on Feature Interactions in Telecommuni-
cation Systems, pp. 274-289, May 2000.
[16] A. Aho, S. Gallagher, N. Griffeth, C. Schell, D. Swayne, Sculp-
tor with Chisel: requirements engineering for communica-
tion services, 5th Intl Workshop on Feature Interactions
in Telecommunication and Software Systems, pp. 45-63,
September 1998.
[17] M. Calder, A. Miller, Using SPIN for feature interaction analy-
sis-a case study, 8th Intl SPIN Workshop on Model checking
software, pp. 143-162, 2001.
[18] A. Felty, K. Namjoshi, Feature specification and automatic con-
flict detection, ACM Transactions on Software Engineering
and Methodology, Vol. 12, No. 1, pp. 3-27, 2003.
[19] J. Blom, B. Jonsson, L. Kempe, Using Temporal Logic for Modular
Specification of Telephone Services, 2nd Intl Conference
on Feature Interactions in Telecommunications Systems, pp.
197-216, May 1994.
[20] Y. Hirakawa, T. Takenaka, Telecommunication service description
using state transition rules, 6th Intl Workshop on Soft-
ware Specification and Design, pp. 140-147, October 1991.
[21] K.P. Pomakis, J.M. Atlee, Reachability analysis of feature
interactions: a progress report, ACM SIGSOFT Intl Sympo-
sium on Software Testing and Analysis, pp. 216-223, Jan-
uary 1996.
[22] T. Yokogawa, T. Tsuchiya, M. Nakamure, T. Kikuno, Feature Inter-
action Detection by Bounded Model Checking, IEICE Transac-
tions on Information Systems, Vol. E86-D, No. 12, pp.
2579-2587, December 2003.
[23] A. Gammelgard, J.E. Kristensen, Interaction Detection, a Logical
Crespo & Logrippo Expires April 14, 2009 [Page 13]
FI-Problem Statement October 14, 2008
Approach, 2nd Intl Workshop on Feature Interactions in
Telecommunication Systems, pp. 178-196, May 1994.
[24] R.G. Crespo, Security Analysis of Features Interaction, 2nd Intl
Conference on Internet Technologies and Applications, pp
45-53, September 2007.
[25] S. Homayoon, H. Singh, Methods of Addressing the Interactions of
Intelligent Network Services with Embedded Switch Ser-
vices, IEEE Communications, Vol 26, No. 12, pp. 42-70,
December 1998.
[26] M. Cain, Managing Run-Time Interactions Between Call-Processing
Features, IEEE Communications, Vol 30, No. 2, pp. 44-50,
February 1992.
[27] D. Marples, E.H. Magill, The Use of Rollback to Prevent Incor-
rect Operation of Features in Intelligent Network based
Systems, 5th Intl Workshop on Feature Interactions in
Telecommunication and Software Systems, pp. 115-134,
September 1998.
[28] R.J.A. Buhr, D. Amyot, M. Elammari, D. Quesnel, T. Gray, S.
Mankovski, Feature-Interaction Visualization and Resolu-
tion in a Agent Environment, 5th Intl Workshop on Feature
Interactions in Telecommunication and Software Systems,
pp. 135-149, September 1998.
[29] R.G. Crespo, M. Carvalho, L. Logrippo, Distributed Resolution of
Feature Interactions for Internet Applications, Computer
Networks, Vol. 51, No. 2, pp. 382-397, February 2007.
[30] S. Tsang, E.H. Magill, Behaviour Based Run-Time Feature Interac-
tion Detection and Resolution Approaches for Intelligent
Networks, 4th Intl Conference on Feature Interactions in
Telecommunications Systems, pp. 244-270, 1997.
[31] M. Amer, T. Karmouch, T. Gray, S. Mankovski, Feature interaction
resolution using fuzzy policies, 6th Intl Workshop on Fea-
ture Interactions in Telecommunication Systems, pp. 45-63,
May 2000.
[32] J.D. Hay, J.M. Atlee, Composing Features and Resolving Interac-
tions, ACM Intl Symposium on Foundation of Software Engi-
neering, pp. 110-119, November 2003.
[33] H. Velthuijsen, Distributed Artificial Intelligence for Runtime
Feature-Interaction Resolution, IEEE Computer, Vol. 26,
Crespo & Logrippo Expires April 14, 2009 [Page 14]
FI-Problem Statement October 14, 2008
No. 8, pp. 48-55, August 1993.
[34] M. Calder, M. Kolberg, E.H. Magill, D. Marples, S. Reiff-Mar-
ganiec, Hybrid Solutions to the Feature Interaction Prob-
lem, 7th Intl Workshop on Feature Interactions in Telecom-
munication and Software Systems, pp. 295-312, June 2003.
Author Address
Rui Gustavo Crespo
Electrical and Computer Engineering Department
Technical University of Lisbon
Av. Rovisco Pais, 1049-001 Lisboa
Portugal
Phone: +351 - 21 8417 626
EMail: R.G.Crespo@comp.ist.utl.pt
Luigi Logrippo
Departement de Informatique et Ingenierie
Universite du Quebec en Outaouais
Case Postale 1250, Succ. B, Gatineau QC J8X 3X7
Canada
Phone: (819) 595-3900 x 1885
Email: luigi@uqo.ca
Crespo & Logrippo Expires April 14, 2009 [Page 15]
FI-Problem Statement October 14, 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it
represent that it has made any independent effort to identify any
such rights. Information on the procedures with respect to
rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to the
IETF at ietf-ipr@ietf.org.
Crespo & Logrippo Expires April 14, 2009 [Page 16]