SIPPING WG R.G. Crespo Internet-Draft UTL L. Logrippo Intended Status: Informational UQO Expires April 14, 2009 October 14, 2008 Feature Interactions Problem Statement 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]