SIPPING WG R.G. Crespo Internet-Draft UTL L. Logrippo Intended Status: Experimental UQO Expires April 15, 2009 October 15, 2008 Distributed Resolution of Feature Interactions for Internet Applications Status of this Memo 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 This Internet-Draff will expire on April 15, 2009. 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 specifies the architecture of a distributed feature mana- ger that proposes the resolution of feature interactions. The resolu- tion may be done locally, or with cooperation between different nodes. The resolution method is left to the implementation. In this document Crespo & Logrippo Expires April 2009 [Page 1] Resolution of Feature Interactions October 15, 2008 we provide an example of one resolution method, based on feature interdiction, as described by a set of deontic formulas. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. FI major problems . . . . . . . . . . . . . . . . . . . . 3 1.2. FI classification . . . . . . . . . . . . . . . . . . . . 4 1.3. Conventions of this document . . . . . . . . . . . . . . . 4 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Protocol specification . . . . . . . . . . . . . . . . . . . . 5 3.1. Feature representation . . . . . . . . . . . . . . . . . . 6 3.2. Candidate message format . . . . . . . . . . . . . . . . . 7 3.2.1. Header part . . . . . . . . . . . . . . . . . . . . 7 3.2.2. Information part . . . . . . . . . . . . . . . . . 8 3.3. Advice message format . . . . . . . . . . . . . . . . . . 8 3.4. Request message format . . . . . . . . . . . . . . . . . . 9 3.5. Reply message format . . . . . . . . . . . . . . . . . . . 9 4. Feature resolution . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Constraint relationships . . . . . . . . . . . . . . . . . 10 4.1.1. Local constraints . . . . . . . . . . . . . . . . . 11 4.1.2. Chain constraints . . . . . . . . . . . . . . . . . 11 4.1.3. Point-to-point constraints . . . . . . . . . . . . 11 4.2. Losing information . . . . . . . . . . . . . . . . . . . . 11 4.3. Features represented by multiple actions . . . . . . . . . 11 4.4. Final selection . . . . . . . . . . . . . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 12 6.1. Registries for messages between LA and LIRAdv . . . . . . 12 6.2. Registries for messages between LIRAdv and RIRAdv . . . . 13 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 1. Introduction The purpose of this draft is to document a method to resolve feature interactions, which may occur in Internet applications. The method is based on the use of a feature manager, designated as Interaction Resolver Advisor (IRAdv). IRAdvs may cooperate to resolve particular interactions. This document focuses on the interaction between the applications and the IRAdvs, and between IRAdvs. The implementation of the IRAdvs is left unspecified, although we describe one possible implementation based on a set of interdiction formulas. Crespo & Logrippo Expires April 2009 [Page 2] Resolution of Feature Interactions October 15, 2008 Internet applications provide sets of basic services. For example, the Email protocol provides two basic services: sending a message to another user and reading a message from another user. Internet applications have been enhanced with many features, defined as units of functionality existing in a system and perceived as having self-contained roles. For example, ForwardMessage and AutoResponder are popular Email features. ForwardMessage forwards all incoming Email messages to another user. AutoResponder reads the incoming messages and sends automatically a notification message to the Email originators, for example notifying them that the recipient is absent on vacation. The combination of features, which work fine alone, may result in undesired behaviors and this problem is known as feature interaction, or FI for short. For example, 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. Thereafter, 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 goal of the AutoResponder feature, which is to notify the originator that Carl is away. The Email server of Bob, when it receives the notification message, forwards it back to Carl. The Email server of Carl detects a loop, another undesired behavior, and discards the notification message. In this draft, we adopt SMTP definitions [2] for originator and recipient. FIs may occur for a single user: for example, ForwardMessage and ReadMessage basic services interact (if a message arrives, should it be forward to another user, or should it be stored in the Email server?). FIs may involve several users, such as the one between the ForwardMessage and AutoResponder features. FIs may occur within a single application node, such as the one between the AutoResponder and FilterMessage. FIs may also occur among different application nodes, an example is mutual ForwardMessage features. The FI problem, first identified in circuit-switched networks, has been studied in many Internet applications, such as Email [3], VoIP [4], WWW [5] and networked home appliances [6]. 1.1. FI major problems Three basic problems have been studied: avoidance, detection and Crespo & Logrippo Expires April 2009 [Page 3] Resolution of Feature Interactions October 15, 2008 resolution. * Avoidance means to intervene at protocol or design stages to prevent FIs, before features are executed. The distributed nature of the Internet, with multi-vendor and multi-provider environments, and the end user capability to program and tailor features, make it impossible to rely on avoidance. * Detection aims at the identification of FIs, with suitable methods. A review of several existing methods of FI detection is given in [7]. * In the resolution, actions are exercised over already detected FIs. Three approaches have been explored for FI run-time resolution: one phase, two phase and negotiation. The one phase approach uses feature managers to decide which feature is executed, according to tables or trees. Although simple, the one phase approach requires knowledge about low-level details, suffers from the scalability problem, and reveals problems in the resolution of multiple user FIs. In the two phase approach, the feature is executed in an isolated environment and actions are taken in case of FI. The isolated environment is impractical in the Internet. The distributed character of the Internet makes direct negotiation the most suitable approach. In this draft, we specify an Interaction Resolver Adviser (IRAdv), which is * scalable, i.e., such that increasing the number of Internet applications and increasing the number of subscribed features does not degrade significantly the resolution performance, * accepts partial resolution, i.e., it will work even if some nodes do not reply to requests sent by other IRAdvs - because they may be down or because IRAdvs have not been installed, * independent of the feature implementation, and * unique for all Internet applications. 1.2. FI classification Several taxonomies have been produced to classify different types of FI. Here we adopt the classification of [9], where FIs are Crespo & Logrippo Expires April 2009 [Page 4] Resolution of Feature Interactions October 15, 2008 classified by the nature of the interaction, as well as by the cause of the interaction. We are especially concerned with the nature of the interactions, according to the number of parties involved in the interactions (single or multiple), the number of network components involved in the interactions (single or multiple), and the kind of features involved in the interactions (custom or system). 1.3. Conventions of this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL", are to be interpreted as described in RFC 2119 [1] and indicate requirement levels for compliant implementations. 1.4 Terminology FI: Feature interaction FIRP: Feature Interaction Resolution Protocol IETF: Internet Engineering Task Force IRAdv: Interaction Resolver Adviser LIRAdv: Local Interaction Resolver Adviser RIRAdv: Remote Interaction Resolver Adviser WWW: World Wide Web 2. Architecture The architecture model that we propose for a distributed resolution of FIs is depicted in figure 1. The architecture model adopts the client-server model. Crespo & Logrippo Expires April 2009 [Page 5] Resolution of Feature Interactions October 15, 2008 +---------------------------------+ | Application | | | | +-----------+ + ----------+ | | | Feature 1 | ... | Feature N | | | +-----------+ +-----------+ | | | +---------------------------------+ ^ | | | Candidates | | | | +-------+ +-------+ | +->| | Request | | | | IRAdv |-------->| IRAdv | +------| |<--------| | Advice | | Reply | | | | | | +-------+ +-------+ Figure 1 Architecture model When an application has a request for a service, incoming or outgo- ing, the application may identify more than one feature as candidate for service execution. The application asks IRAdv for advice on which feature the application should execute that will not generate inconsistent behaviors. IRAdvs may request other IRAdvs for additional information. Their reply will assist the requesting IRAdv to identity the advice, to be returned to the application. 3. FIRP specification This section provides the detailed description of the FIRP-Feature Interaction Resolution Protocol. The entities are the Local Applica- tion (LA), the Local IRAdv (LIRAdv) and the Remote IRAdv (RIRAdv). The protocol between the Application (the client) and the Local IRAdv (the server) is depicted in figure 2. * First, upon the arrival of an incoming message or the generation of an outgoing message, the application sends to the LIRAdv a set of feature candidates for execution, together with the application status. * LIRAdv may request other RIRAdv for a certain kind of permission to execute the feature. In this case, RIRAdv returns a Reply. With Crespo & Logrippo Expires April 2009 [Page 6] Resolution of Feature Interactions October 15, 2008 consideration of this reply, LIRAdv selects the feature which, when executed by LA, does not generate FIs. * Finally, LIRAdv advises LA on which feature it must execute. LA LIRAdv RIRAdv | | | +----------------------+ | | |Feature identification| | | +----------------------+ | | | Candidates | | |------------------>| | | (Features,Status) | | | | Request | | |------------->| | | (Permission) | | | Reply | | |<-------------| | | (Permission) | | +-----------------+ | | |Feature selection| | | +-----------------+ | | Advice | | |<------------------| | | (Feature) | | Figure 2 Resolution procedure The location of IRAdvs is a matter of implementation: each applica- tion node may have installed one IRAdv, or one IRAdv may serve sev- eral application nodes. In both cases, when receiving requests from other IRAdvs, the remote IRAdvs should have access to information from the application nodes that they are serving. 3.1 Feature representation The number of features in a system may be large. For example, about eight hundred features are known in telephone systems [8]. Short lists of 17 telecommunication features, easily adapted to VoIP [9], and the specification of 10 Email features [3] are available in the literature. Hence, there is a need to identify a compact representa- tion of features, to avoid a large matrix of relationships in the FI resolver. Compact feature representations have been proposed in [10] and [11]. We adopt here the feature representation of [10], with a set of basic Crespo & Logrippo Expires April 2009 [Page 7] Resolution of Feature Interactions October 15, 2008 and abstract actions that a feature can execute. Actions are depicted in table 1. All actions have one parameter that may be * _init, the node that started the message, * _dest, the node to whom the message should be delivered (that may be changed later, for example as the result of a forward), * _self, the node currently processing the message. Table 1 Feature basic actions +-----------------+------------------------------------------------+ | Name | Purpose | +-----------------+------------------------------------------------+ |Accept(_init) | The node accepts the message | +-----------------+------------------------------------------------+ |Deny(_init) | The node rejects the message | +-----------------+------------------------------------------------+ |Display(_init) | The node displays the originator and waits for | | | the recipient to confirm message acceptance | +-----------------+------------------------------------------------+ |Emergency(_init) | The node must accept the message, with highest | | | priority | +-----------------+------------------------------------------------+ |Forward(_dest) | The node redirects the message to another node | +-----------------+------------------------------------------------+ |Send(_dest) | The node initiates a message to another node | +-----------------+------------------------------------------------+ |Wait(_init) | The node puts the message on hold, for later | | | processing | +-----------------+------------------------------------------------+ Two different features may be represented by the same basic actions. For example, the VoIP CFA-Call Forward Always and CFB-Call Forward if Busy features are both represented by the Forward action when the user is busy. One feature may be represented by more than one action. For example, the Email AutoResponder feature is represented by the join of actions Accept and Send. 3.2 Candidate message format When an application has a request for a service, incoming or outgo- ing, more than one feature may be selected as candidate for service execution. Then, the application sends to the IRAdv attached to its Crespo & Logrippo Expires April 2009 [Page 8] Resolution of Feature Interactions October 15, 2008 node a message with a structure divided in two parts: * Header part, containing information about the message and the involved parties, * Information part, containing specific information about each selected feature. 3.2.1. Header part The header part is divided into five fields: AP, Initial-Addr, Chain- Addr, AS and CD. * ApplicationPort field (AP) indicates which application requires advice. AP value is the port number attached to the associated application protocol, as registered by IANA. For example, Email applications follow the SMTP protocol [2] and communicate through port 25. * Initial Address (Initial-Addr) field contains the address of the user that has initiated the message. The Initial-Addr is set by the originator application, and must remain unchanged until the message is last processed. Actions with _init parameter bind their value to Initial-Addr value. * Chain Address field (Chain-Addr) contains the list of IP addresses of all nodes that have processed the message, including the originator. This field can be useful to detect message loop- ing. The originator node starts an empty Chain-Addr field. All successive nodes, including the originator, append their IP addresses to the Chain-Addr field. * ApplicationStatus field (AS) provides information about the application status. The structure and the meaning of the application status depend on the implementation of the application and of the IRAdv. An example of application status is the predicate loop(_self) which is true if the processing node finds its own IP address in the Chain-Addr value. * ConfirmDirective field (CD) indicates the kind of confirmation to be asked of the originator node. CD field is intended for the implementation of access control policies, such as parental con- trol. In this document we do not focus on security issues, such as authorisation and data integrity. Crespo & Logrippo Expires April 2009 [Page 9] Resolution of Feature Interactions October 15, 2008 Table 2 depicts the possible values for the CD field. Table 2 ConfirmDirective field values +------------+----------------------------------------------------+ | Value | Purpose | +------------+----------------------------------------------------+ |None | Message may be processed without originator | | | knowledge | +------------+----------------------------------------------------+ |AllNodes | All nodes must ask, from the originator, | | | permission to process the message | +------------+----------------------------------------------------+ |Destination | Only the final destination node must ask, from the | | | originator, permission to process the message | +------------+----------------------------------------------------+ CD-value should be transmitted with the message. Section 4.2 dis- cusses the case when, for some reason, the CD-value is unavailable. 3.2.2. Information part The information part is divided into two fields: FC and Act. * FeatureCode field (FC) is an unique identifier of the feature candidate for execution. The purpose of the FC field is to link features to the actions that represent them. * Action field (Act) is a list of action codes, that represent the features identified in the FC field. Each action code must be followed by the IP addresses of the action parameters. The Action parameters, listed in table 1, are: _init, _dest and _self. 3.3. Advice message format Local IRAdv returns to the application the feature code that it should execute. In case of failure in FI resolution, IRAdv must return to the application the special code NO_ADVICE. 3.4. Request message format When an IRAdv receives a candidate message, it may be necessary for resolution of FIs to ask another IRAdv for permission to execute the Crespo & Logrippo Expires April 2009 [Page 10] Resolution of Feature Interactions October 15, 2008 feature. The information exchange is sent through a request message, which is linked to the candidate message. Every request message contains five fields: FC, AP, CC, Initial-Addr and Destination-Addr. * FeatureCode field (FC) is a unique identifier for the feature. The FeatureCode value is equal to the value in the corresponding field in the linked Candidate message. * ApplicationPort field (AP) indicates the application concerned by the request. The AP value must be equal to the value in the corre- sponding field in the candidate message. * ConfirmationCode field (CC) indicates the kind of permission required, or its result. Table 3 depicts the possible values for the CC field. Table 3 ConfirmationCode values +--------------------+------------------------------------------+ | Value | Purpose | +--------------------+------------------------------------------+ |Delivery_request | Request permission to accept the message | +--------------------+------------------------------------------+ |Delivery_acceptable | Message may be delivered | +--------------------+------------------------------------------+ |Delivery_denied | Message must not be delivered | +--------------------+------------------------------------------+ For the Request message, the only acceptable value of the CC field is Delivery_request * Initial Address field (Initial-Addr) contains the address of the user that initiates, or has initiated, the message. The Initial- Addr value is equal to the same field in the linked Candidate mes- sage. * Destination Address field (Destination-Addr) contains the address of the intended destination partner. The Destination-Addr value is equal to the value in the corresponding field in the linked Candi- date message. 3.5. Reply message format The Reply message format is equal to the Request message format. The only difference between Request and Replay messages is the CC value. Crespo & Logrippo Expires April 2009 [Page 11] Resolution of Feature Interactions October 15, 2008 For Reply message, the CC value may only be equal to Delivery_accept- able or Delivery_denied IRAdvs must be aware that other IRAdvs may not reply to their requests. For example, remote nodes may be temporarily down, or may not have IRAdv installed. If the local IRAdv does not receive a reply to a request, it may produce a different advice. This problem is discussed in section 4.2 4. Feature resolution The method for selecting feature candidates that would not produce FIs is left to the implementation. Here we describe the implementation presented in [10], based on two steps: * In the first step, the filtering phase, a set of constraint for- mulas is evaluated over the actions that each feature candidate represents. This step is described in sections 4.1 to 4.3. The filtering phase is implemented with support of a set of con- straint formulas. If satisfied, a constraint formula marks some actions as interdicted. The result of the first step is the elimi- nation of a subset of feature candidates for execution. The remain- ing feature candidates are submitted to the second step. * In the second step, the selection phase, one feature is selected for execution advice. This step is described in section 4.4 4.1. Constraint relationships Constraint relationships are formulas expressed in the first-order predicate language, extended with the interdiction operator I. Logi- cal connectives are listed in table 4 Crespo & Logrippo Expires April 2009 [Page 12] Resolution of Feature Interactions October 15, 2008 Table 4 Logical connectives +-----------+--------+---------------------+ |Connective | Arity | Meaning | +-----------+--------+---------------------+ | AND | Binary | Formula conjunction | +-----------+--------+---------------------+ | OR | Binary | Formula disjunction | +-----------+--------+---------------------+ | IMPLY | Binary | Formula implication | +-----------+--------+---------------------+ | NOT | Unary | Formula negation | +-----------+--------+---------------------+ | I | Unary | Action removal | +-----------+--------+---------------------+ The operator precedence, which may be overridden by the use of par- entesis, is as follows * Highest precedence for unary operators. * Intermediate precedence for conjunction and disjunctive opera- tors. * Lowest precedence for the implication operator. The form of the formula is Requests AND Conditions IMPLY Restrictions * The Requests part is a conjunction of actions, representing fea- tures selected by the application as candidates for execution. * The Conditions part identifies the values that the application status, or message status, may have to hold. By default, this part is considered to be true. * The Restrictions part identifies the single action, or the join of actions, whose execution is forbidden. In this part we use the Interdiction unary connective, where I act means that action act cannot be executed. There are three different types of constraint formulas which apply to different layouts of the nodes that participate in the resolution. We call these local, chain and point-to-point constraints. Crespo & Logrippo Expires April 2009 [Page 13] Resolution of Feature Interactions October 15, 2008 4.1.1. Local constraints Local constraints are directed to the resolution of single user FIs. For example, the formula that gives a Deny action a priority greater than the Accept action is Accept(_init) AND Deny(_init) IMPLY I Accept(_init) 4.1.2. Chain constraints Chain constraints are oriented to the resolution of multiple FIs, with no request for permission from another IRAdv. For example, the formula that forbids a message to enter a loop through Forward actions is Forward(_dest) AND loop(_self) IMPLY I Forward(_dest) 4.1.3. Point-to-point constraints Chain constraints are directed to the resolution of multiple user FIs, with request for permission from another IRAdv. For example, the formula that resolves ReadMail and FilterDestination FI is Accept(_init) AND NOT permission(_init) IMPLY I Accept(_init) 4.2. Losing information Because IRAdvs may not work properly in all intervening nodes, in some cases a reply may not be returned. IRAdv must always return an advice to the application, therefore a default value for the reply must be considered. The default value may depend on the recipient application. For example, the content of some WWW pages may require an explicit confirmation from the originator and the default reply value for permission(_init) request would be false. 4.3. Features represented by multiple actions Actions of different features are connected in the Request and Inter- diction parts by the AND logical operator. The join predicate is needed because some features can be represented by several actions, and we do not want actions to be transferred from one feature representation to another. If A,B and C are actions, join(A,B) AND C is equivalent to C AND join(A,B) or to C AND Crespo & Logrippo Expires April 2009 [Page 14] Resolution of Feature Interactions October 15, 2008 join(B,A), but not to A AND join(B,C). For example, to interdict AutoResponder feature to send a reply to the postmaster, the formula is join(Accept(_init),Send(_dest)) AND _dest=postMaster IMPLY I Send(postMaster) The fact that several action may be joined in a features raises the question of what will happen if only some actions in a feature are interdicted. We have identified three different approaches for fea- ture interdiction: maximization, conditional and survival. * The interdiction maximization approach interdicts a feature even if only one of the actions that represents it in the join is inter- dicted. * The conditional interdiction approach interdicts an action join if some of the actions that are joined are interdicted, but not all, and there are actions outside the join that are not inter- dicted. * The survival maximization approach interdicts an action join only when all of the actions that are joined are interdicted. 4.4. Final selection The set submitted to the selection phase represent the features that do not generate FI. IRAdv implementation can adopt any algorithm capable of selecting the feature to be presented to the application. If necessary, feature parameters may be updated. An algorithm could mark all candidate features for elimination. This problem is not addressed here. 5. Security Considerations There are several security considerations associated with this pro- posal. Feature interaction results in unexpected behaviors. The unexpected behaviors may include access to confidential information. The FI resolution is targeted to avoid such unexpected behaviors but, itself, may raise security concerns. Information exchange between IRAdvs must be properly authenticated. data Moreover, data corruption must be avoided by adopting integrity mechanisms. Crespo & Logrippo Expires April 2009 [Page 15] Resolution of Feature Interactions October 15, 2008 6. IANA Considerations To allow the development of FI resolvers, as specified in this docu- ment, by different developers, registries must be assigned for a num- ber of message fields. The message fields, defined by the FIRP proto- col, are explained in section 3 of this document. Also, IRAdv pro- vides a service through a contact port, to be defined by IANA. 6.1. Registries for messages between LA e LIRAdv The messages sent by LA to LIRAdv are specified in section 3.2 of this document. The messages sent by LIRAdv to LA are specified in section 3.3 of this document. * Feature basic actions, such as listed in table 1. * Application status, to which the application assigned a true value. * ConfirmDirective values, as listed in table 2. * Registry value for NO_ADVICE, for the case when LIRAdv is unable to select one feature for execution. 6.2. Registries for messages between LIRAdv and RIRAdv Registries must be assigned to a number of fields for the messages exchanged between the LIRAdv and the RIRAdv. Such messages are speci- fied in sections 3.4 and 3.5 of this document. * ConfirmationCode values, as listed in table 3. 7. 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. 8. References 8.1 Normative references [1] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, BCP 14, RFC 2119, March 1997. 8.2 Informative references [2] J. Klensin, Simple Mail Transfer Protocol, RFC 5321, October Crespo & Logrippo Expires April 2009 [Page 16] Resolution of Feature Interactions October 15, 2008 2008. [3] R. Hall, Feature Interactions in Electronic Mail, 5th Intl Work- shop on Feature Interactions in Telecommunication and Software Sys- tems, pp. 232-246, September 1998. [4] J. Lennox, H. Schulzrinne, Feature Interactions in Internet Tele- phony, 6th Intl Workshop on Feature Interactions in Telecommunica- tion and Software Systems, pp. 38-50, May 1998. [5] M. Weiss, Feature Interactions in Web Services, 7th Intl Workshop on Feature Interactions in Telecommunication and Software Systems, pp. 149-156, 2003. [6] M. Nakamura, Y. Igaki, K.-i. Matsumoto, Feature Interactions in Integrated Services of Networked Home Appliances, 8th Intl Confer- ence on Feature Interactions in Telecommunications and Software Systems, pp. 236-251, 2005. [7] M. Calder, M. Kolberg, E. Magill, S. Reiff-Marganiec, Feature interaction: a critical review and considered forecast, Computer Networks, Vol. 41, No. 1, pp. 115-141, January 2003. [8] K.P. Pomakis, J.M. Atleem Reachability analysis of feature inter- actions: a progress report, ACM SIGSOFT Intl Symposium on Software Testing and Analysis, pp. 216-223, January 1996. [9] E.J. Cameron, N. Griffeth, Y.-J. Lin, M.E. Nilson, W.K. Schnure, Feature interaction benchmark for IN and beyond, Intl Workshop on Feature Interactions in Telecommunications Systems, pp. 1-23, 1994. [10] 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. [11] A.F. Layouni, L. Logrippo, J.T. Turner, Conflict Detection in Call Control Using First-Order Logic Model Checking, 9th Intl Con- ference on Feature Interactions in Software and Communications Sys- tems, September 2007. Author's Addresses Rui Gustavo Crespo Electrical and Computer Engineering Department Technical University of Lisbon Av. Rovisco Pais, 1049-001 Lisboa Portugal Crespo & Logrippo Expires April 2009 [Page 17] Resolution of Feature Interactions October 15, 2008 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 2009 [Page 18] Resolution of Feature Interactions October 15, 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 2009 [Page 19]