idnits 2.17.1 draft-iab-considerations-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 16 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 17 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2914' is mentioned on line 391, but not defined == Outdated reference: A later version (-04) exists of draft-floyd-tcp-reset-03 == Outdated reference: A later version (-05) exists of draft-klensin-dns-role-02 -- Obsolete informational reference (is this intentional?): RFC 2481 (Obsoleted by RFC 3168) -- Obsolete informational reference (is this intentional?): RFC 2598 (Obsoleted by RFC 3246) -- Obsolete informational reference (is this intentional?): RFC 3205 (Obsoleted by RFC 9205) == Outdated reference: A later version (-02) exists of draft-iab-unsaf-considerations-01 Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Floyd, Editor 3 INTERNET DRAFT 4 draft-iab-considerations-00.txt May, 2002 6 General Architectural and Policy Considerations 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet- Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 This document suggests general architectural and policy questions to 32 be addressed in our work in the IETF. We note that this document 33 contains questions to be addressed, as opposed to guidelines or 34 architectural principles to be followed. 36 1. Introduction 38 This document suggests general architectural and policy questions to 39 be addressed in our work in the IETF. This document contains 40 questions to be addressed, as opposed to guidelines or architectural 41 principles to be followed. This is somewhat similar to the "Security 42 Considerations" currently required in IETF documents [RFC2316]. 44 This document is motivated in part by concerns of a growing lack of 45 coherence in the overall Internet architecture. We have moved from a 46 world of a single, coherent architecture designed by a small group of 47 people, to a world of a complex, intricate architecture to address a 48 wide-spread and heterogeneous environment. Because individual pieces 49 of the architecture are often designed by sub-communities, with each 50 sub-community having its own set of interests, it is necessary to pay 51 increasing attention to how each piece fits into the larger picture, 52 and to consider how each piece is chosen. For example, it is 53 unavoidable that each of us is inclined to solve a problem at the 54 layer of the protocol stack and using the tools that we understand 55 the best; that does not necessarily mean that this is the most 56 appropriate layer or set of tools for solving this problem in the 57 long-term. 59 2. Relationship to "Architectural Principles of the Internet" 61 RFC 1958 [RFC1958] outlines some architectural principles of the 62 Internet, as "guidelines that have been found useful in the past, and 63 that may be useful to those designing new protocols or evaluating 64 such designs." An example guideline is that "it is also generally 65 felt that end-to-end functions can best be realized by end-to-end 66 protocols." Similarly, an example design issue from [RFC1958] is that 67 "heterogeneity is inevitable and must be supported by design." 69 In contrast, this document serves a slightly different purpose, by 70 suggesting additional architectural questions to be addressed. Thus, 71 one question suggested in this document is the following: "Is this 72 proposal the best long-term solution to the problem? If not, what 73 are the long-term costs of this solution, in terms of restrictions on 74 future development, if any?" This question could be translated to a 75 roughly equivalent architectural guideline, as follows: "Identify 76 whether the proposed protocol is a long-term solution or a short-term 77 solution, and identify the long-term costs and the exit strategy for 78 any short-term solutions." 80 In contrast, other questions are more open-ended, such as the 81 question about robustness: "How robust is the protocol, not just to 82 the failure of nodes, but also to compromised or malfunctioning 83 nodes, imperfect or defective implementations, etc?" As a community, 84 we are still learning about the degree of robustness that we are able 85 to build into our protocols, as well as the tools that are available 86 to ensure this robustness. Thus, there are not yet clear 87 architectural guidelines along the lines of "Ensure that your 88 protocol is robust against X, Y, and Z." 90 3. Questions. 92 In this section we list some questions to ask in designing protocols. 93 Each question is discussed in more depth in the rest of this paper. 94 We aren't suggesting that all protocol design efforts should be 95 required to explicitly answer all of these questions; some questions 96 will be more relevant to one document than to another. We also 97 aren't suggesting that this is a complete list of architectural 98 concerns. 100 Justifying the Solution: 102 * Why are you proposing this solution, instead of proposing something 103 else? 105 Interactions between Layers: 107 * Why are you proposing a solution at this layer of the protocol 108 stack, rather than at another layer? Are there solutions at other 109 layers of the protocol stack as well? 111 * Is this an appropriate layer in terms of correctness of function, 112 data integrity, performance, ease of deployment, the diagnosibility 113 of failures, and other concerns? 115 * What are the interactions between layers, if any? 117 Long-term vs. Short-term Solutions: 119 * Is this proposal the best long-term solution to the problem? 121 * If not, what are the long-term costs of this solution, in terms of 122 restrictions on future development, if any? What are the 123 requirements for the development of longer-term solutions? 125 Robustness: 127 * How robust is the protocol, not just to the failure of nodes, but 128 also to compromised or malfunctioning nodes, imperfect or defective 129 implementations, etc? 131 Tragedy of the Commons: 133 * Is performance still robust if everyone is using this protocol? 134 Are there other potential impacts of widespread deployment that need 135 to be considered? 137 Protecting Competing Interests: 139 * Does the protocol protect the interests of competing parties (e.g., 140 not only end-users, but also ISPs, router vendors, software vendors, 141 or other parties)? Is the design modularized to allow competing 142 interests to play out, while also isolating "tussles" and preventing 143 them from spilling out into unrelated areas? 145 Weighing Benefits against Costs: 147 * How do the architectural benefits of a proposed new protocol 148 compare against the architectural costs, if any? Have the 149 architectural costs been carefully considered? 151 * When adding features, have the potential costs of feature-creep and 152 the N-way interactions among options been considered, as well as the 153 potential benefits offered by each option? 155 The Whole Picture vs. Building Blocks: 157 * Have you considered the larger context, while appropriately 158 restricting your own design efforts to one part of the whole? 160 * Are there parts of the overall solution that will have to be 161 provided by other IETF Working Groups or by other standards bodies? 163 Designing for Choice: 165 * Is the protocol designed for choice, to allow different players to 166 express their preferences? 168 Preserving Evolvability? 170 * Does the protocol protect the interests of the future, by 171 preserving the evolvability of the Internet? Does the protocol 172 enable future developments? 174 Each of these questions is discussed in more depth in the rest of 175 this paper. 177 4. Justifying the Solution. 179 Question: Why are you proposing this solution, instead of proposing 180 something else? 182 4.1. Case study: Integrated and Differentiated Services. 184 A good part of the work of developing integrated and differentiated 185 services has been to understand the problem to be solved, and to come 186 to agreement on the architectural framework of the solution, and on 187 the nature of specific services. Thus, when integrated services was 188 being developed, the specification of the Controlled Load [RFC2211] 189 and Guaranteed [RFC2212] services each required justification of the 190 need for that particular service, of low loss and bounded delay 191 respectively. 193 Later, RFC 2475 on "An Architecture for Differentiated Services" 194 proposed a scalable, service differentiation architecture that 195 differs from the previously-defined architecture for integrated 196 services, the document also had to clearly justify the requirements 197 for this new architecture, and compare the proposed architecture to 198 other possible approaches [RFC2475]. Similarly, when the Assured 199 Forwarding [RFC2597] and Expedited Forwarding [RFC2598] Per-Hop 200 Behaviors of differentiated services were proposed, each service 201 required a justification of the need for that service in the 202 Internet. 204 5. Interactions between Layers. 206 Questions: Why are you proposing a solution at this layer of the 207 protocol stack, rather than at another layer? Are there solutions at 208 other layers of the protocol stack as well? 210 Is this an appropriate layer in terms of correctness of function, 211 data integrity, performance, ease of deployment, the diagnosibility 212 of failures, and other concerns? 214 What are the interactions between layers, if any? 216 5.1. Case study: Endpoint Congestion Management. 218 The goal of the Congestion Manager in Endpoint Congestion Management 219 is to allow multiple concurrent flows with the same source and 220 destination address to share congestion control state [RFC3124]. 221 There has been a history of proposals for multiplexing flows at 222 different levels of the protocol stack; proposals have included 223 adding multiplexing at the HTTP (WebMux) and TCP (TCP Control Blocks) 224 layers, as well as below TCP (the Congestion Manager) [Multiplexing]. 226 However, the 1989 article on "Layered Multiplexing Considered 227 Harmful" suggests that "the extensive duplication of multiplexing 228 functionality across the middle and upper layers is harmful and 229 should be avoided" [T89]. Thus, one of the key issues in providing 230 mechanisms for multiplexing flows is to determine which layer of the 231 protocol stack is most appropriate for providing this functionality. 232 The natural tendency of each researcher is generally to add 233 functionality at the layer that they know the best; this does not 234 necessarily result in the most appropriate overall architecture. 236 This is elaborated upon in the section below. 238 5.2. Discussion: The End-to-End Argument 240 The classic 1984 paper on "End-To-End Arguments In System Design" 241 [SRC84] begins a discussion of where to place functions among modules 242 by suggesting that "functions placed at low levels of a system may be 243 redundant or of little value when compared with the cost of providing 244 them at that low level. Examples discussed in the paper include bit 245 error recovery, security using encryption, duplicate message 246 suppression, recovery from system crashes, and delivery 247 acknowledgement. Low level mechanisms to support these functions are 248 justified only as performance enhancements." We cite this not as a 249 rule that cannot be violated, but as a guide to some of the issues to 250 be considered in choosing the appropriate layer for a function. 252 5.3. Case study: Layering Applications on Top of HTTP. 254 There has been considerable interest in layering applications on top 255 of HTTP [RFC3205]. Reasons cited include compatibility with widely- 256 deployed browsers, the ability to reuse client and server libraries, 257 the ability to use existing security mechanisms, and the ability to 258 traverse firewalls. As RFC 3205 discusses, "the recent interest in 259 layering new protocols over HTTP has raised a number of questions 260 when such use is appropriate, and the proper way to use HTTP in 261 contexts where it is appropriate." Thus, RFC 3205 addresses not only 262 the benefits of layering applications on top of HTTP, but also 263 evaluates the additional complexity and overhead of layering an 264 application on top of HTTP, compared to the costs of introducing a 265 special-purpose protocol. 267 The web page on "References on Layering and the Internet 268 Architecture" has pointers to additional papers discussing general 269 layering issues in the Internet architecture [Layering]. 271 6. Long-term vs. Short-term Solutions 273 Questions: Is this proposal the best long-term solution to the 274 problem? 276 If not, what are the long-term costs of this solution, in terms of 277 restrictions on future development, if any? What are the 278 requirements for the development of longer-term solutions? 280 6.1. Case study: Traversing NATs. 282 In order to address problems with NAT middleboxes altering the 283 external address of endpoints, various proposals have been made for 284 mechanisms where an originating process attempts to determine the 285 address (and port) by which it is known on the other side of a NAT. 286 This would allow an originating process to be able to use address 287 data in the protocol exchange, or to advertise an external address 288 from which it will receive connections. 290 The IAB in [UNSAF] has outlined reasons why these proposals can be 291 considered at best as short-term fixes to specific problems, and the 292 specific issues to be carefully evaluated before standardizing such 293 proposals. These issues include the identification of the limited- 294 scope problem to be fixed, the description of an exit strategy for 295 the short-term solution, and the description of the longer-term 296 problems left unsolved by the short-term solution. 298 7. General Robustness Questions 300 Questions: How robust is the protocol, not just to the failure of 301 nodes, but also to compromised or malfunctioning nodes, imperfect or 302 defective implementations, etc? 304 Does the protocol take into account the realistic conditions of the 305 current or future Internet (e.g., packet drops and packet corruption; 306 packet reordering; asymmetric routing; etc.)? 308 7.1. Discussion: Designing for Robustness. 310 Robustness has long been cited as one of the overriding goals of the 311 Internet architecture [Clark88]. The robustness issues discussed in 312 [Clark88] largely referred to the robustness of packet delivery even 313 in the presence of failed routers; today robustness concerns have 314 widened to include a goal of robust performance in the presence of a 315 wide range of failures, buggy code, and malicious actions. 317 As [ASSW02] argues, protocols need to be designed somewhat 318 defensively, to maximize robustness against inconsistencies and 319 errors. [ASSW02] discusses several approaches for increasing 320 robustness in protocols, such as verifying information whenever 321 possible; designing interfaces that are conceptually simple and 322 therefore less conducive to error; protecting resources against 323 attack or overuse; and identifying and exposing errors so that they 324 can be repaired. 326 Techniques for verifying information range from verifying that 327 acknowledgements in TCP acknowledge data that was actually sent, to 328 providing mechanisms for routers to verify information in routing 329 messages. 331 Techniques for protecting resources against attack range from 332 preventing "SYN flood" attacks by designing protocols that don't 333 allocate resources for a single SYN packet, to partitioning resources 334 (e.g., preventing one flow or aggregate from using all of the link 335 bandwidth). 337 7.2. Case Study: Explicit Congestion Notification (ECN). 339 The Internet is based on end-to-end congestion control, and 340 historically the Internet has used packet drops as the only method 341 for routers to indicate congestion to the end nodes. ECN [RFC3168] 342 is a recent addition to the IP architecture to allow routers to set a 343 bit in the IP packet header to inform end-nodes of congestion, 344 instead of dropping the packet. 346 The first, Experimental specification of ECN [RFC2481] contained an 347 extensive discussion of the dangers of a rogue or broken router 348 "erasing" information from the ECN field in the IP header, thus 349 preventing indications of congestion from reaching the end-nodes. To 350 add robustness, the standards-track specification [RFC3168] specified 351 an additional codepoint in the IP header's ECN field, to use for an 352 ECN "nonce". The development of the ECN nonce was motivated by 353 earlier research on specific robustness issues in TCP [SCWA99]. RFC 354 3168 explains that the addition of the codepoint "is motivated 355 primarily by the desire to allow mechanisms for the data sender to 356 verify that network elements are not erasing the CE codepoint, and 357 that data receivers are properly reporting to the sender the receipt 358 of packets with the CE codepoint set, as required by the transport 359 protocol." Supporting mechanisms for the ECN nonce are needed in the 360 transport protocol to ensure robustness of delivery of the ECN-based 361 congestion indication. 363 In contrast, a more difficult and less clear-cut robustness issue for 364 ECN concerns the differential treatment of packets in the network by 365 middleboxes, based on the TCP header's ECN flags in a TCP SYN packet 366 [F02]. The issue concerns "ECN-setup" SYN packets, that is, SYN 367 packets with ECN flags set in the TCP header to negotiate the use of 368 ECN between the two TCP end-hosts. There exist firewalls in the 369 network that drop "ECN-setup" SYN packets, others that send TCP Reset 370 messages, and yet others that zero ECN flags in TCP headers. None of 371 this was anticipated by the designers of ECN, and RFC 3168 added 372 optional mechanisms to permit the robust operation of TCP in the 373 presence of firewalls that drop "ECN-setup" SYN packets. However, 374 ECN is still not robust to all possible scenarios of middleboxes 375 zeroing ECN flags in the TCP header. Up until now, transport 376 protocols have been standardized independently from the mechanisms 377 used by middleboxes to control the use of these protocols, and it is 378 still not clear what degree of robustness is required from transport 379 protocols in the presence of the unauthorized modification of 380 transport headers in the network. These and similar issues are 381 discussed in more detail in [F02]. 383 8. Avoiding Tragedy of the Commons. 385 Question: Is performance still robust if everyone is using the new 386 protocol? Are there other potential impacts of widespread deployment 387 that need to be considered? 389 8.1. Case Study: End-to-end Congestion Control. 391 [RFC2914] discusses the potential for congestion collapse if flows 392 are not using end-to-end congestion control in a time of high 393 congestion. For example, if a new transport protocol was proposed 394 that did not use end-to-end congestion control, it might be easy to 395 show that a flow using the new transport protocol would perform quite 396 well as long as all of the competing flows in the network were using 397 end-to-end congestion control. To fully evaluate the new transport 398 protocol, it is necessary to look at performance when many flows are 399 competing, all using the new transport protocol. If all of the 400 competing flows were using the more aggressive transport protocol in 401 a time of high congestion, the result could be a tragedy of the 402 commons, with many links busy carrying packets that will only be 403 dropped downstream. 405 9. Balancing Competing Interests 407 Question: Does the protocol protect the interests of competing 408 parties (e.g., not only end-users, but also ISPs, router vendors, 409 software vendors, or other parties)? Is the design modularized to 410 allow competing interests to play out, while also isolating "tussles" 411 and preventing them from spilling out into unrelated areas? 413 9.1. Discussion: balancing competing interests 415 [CWSB02] discusses the role that competition between competing 416 interests plays in the evolution of the Internet, and takes the 417 position that the role of Internet protocols is to design the playing 418 field in this competition, rather than to pick the outcome. The IETF 419 has long taken the position that it can only design the protocols, 420 and that often two competing approaches will be developed, with the 421 marketplace left to decide between them [A02]. 423 An example cited in [CWSB02] of modularization in support of these 424 competing interests is the decision to use codepoints in the IP 425 header to select QoS, rather than binding QoS to other properties 426 such as port numbers. This separates the structural and economic 427 issues related to QoS from technical issues of protocols and port 428 numbers, and allows space for a wide range of structural and pricing 429 solutions to emerge. 431 10. Designing for Choice 433 Is the protocol designed for choice, to allow different players to 434 express their preferences? 436 10.1. Discussion: the importance of choice 438 [CWSB02] suggests that "the fundamental design goal of the Internet 439 is to hook computers together, and since computers are used for 440 unpredictable and evolving purposes, making sure that the users are 441 not constrained in what they can do is doing nothing more than 442 preserving the core design tenet of the Internet. In this context, 443 user empowerment is a basic building block, and should be embedded 444 into all mechanism whenever possible." 446 As an example of choice, "the design of the mail system allows the 447 user to select his SMTP server and his POP server" [CWSB02]. More 448 open-ended questions about choice concern the design of mechanisms 449 that would enable the user to choose the path at the level of 450 providers, or to allow users to choose third-party intermediaries 451 such as web caches, or providers for Open Pluggable Edge Services 452 (OPES). [CWSB02] also notes that the issue of choice itself reflects 453 competing interests. For example, ISPs would generally like to lock 454 in customers, while customers would like to preserve their ability to 455 change among providers. 457 11. Weighing architectural benefits against architectural costs. 459 Questions: How do the architectural benefits of a proposed new 460 protocol compare against the architectural costs, if any? Have the 461 architectural costs been carefully considered? 463 When adding features, have the potential costs of feature-creep and 464 the N-way interactions among options been considered, as well as the 465 potential benefits offered by each option? 467 11.1. Case Study: Performance-enhancing proxies (PEPs) 469 RFC 3135 [RFC3135] considers the relative costs and benefits of 470 placing performance-enhancing proxies (PEPs) in the middle of a 471 network to address link-related degradations. In the case of PEPs, 472 the potential costs include disabling the end-to-end use of IP layer 473 security mechanisms; introducing a new possible point of failure that 474 is not under the control of the end systems; adding increased 475 difficulty in diagnosing and dealing with failures; and introducing 476 possible complications with asymmetric routing or mobile hosts. RFC 477 3135 carefully considers these possible costs, the mitigations that 478 can be introduced, and the cases when the benefits of performance- 479 enhancing proxies to the user are likely to outweight the costs. 481 11.2. Case Study: Open Pluggable Edge Services (OPES) 483 One of the issues raised by middleboxes in the Internet involves the 484 end-to-end integrity of data. This is illustrated in the recent 485 question of chartering the Open Pluggable Edge Services (OPES) 486 Working Group. Open Pluggable Edge Services are services that would 487 be deployed as application-level intermediaries in the network, for 488 example, at a web proxy cache between the origin server and the 489 client. These intermediaries would transform or filter content, with 490 the explicit consent of either the content provider or the end user. 492 One of the architectural issues that arose in the process of 493 chartering the OPES Working Group concerned the end-to-end integrity 494 of data. As an example, it was suggested that ``OPES would reduce 495 both the integrity, and the perception of integrity, of 496 communications over the Internet, and would significantly increase 497 uncertainly about what might have been done to content as it moved 498 through the network'', and that therefore the risks of OPES 499 outweighed the benefits [CDT01]. 501 As one consequence of this debate, the IAB wrote a document on "IAB 502 Architectural and Policy Considerations for OPES", considering both 503 the potential architectural benefits and costs of OPES [RFC3238]. 504 This document did not recommend specific solutions or mandate 505 specific functional requirements, but instead included 506 recommendations of issues such as concerns about data integrity that 507 OPES solutions standardized in the IETF should be required to 508 address. 510 11.3. Case Study: Stresses on DNS. 512 As an example, over and over again, we find people wanting to 513 overload the DNS with new services and functions. In each case, we 514 may ask whether or not it is feasible to add a particular feature, 515 and often the answer is yes. What we rarely ask is the impact of all 516 this added functionality on the provision of the original service. 517 [K02] considers many of the newer demands being placed upon the DNS, 518 and [CA02] discusses the general dangers of functional overloading 519 and of unlimited protocol extensions. 521 12. Looking at the whole picture vs. making a building block. 523 For a complex protocol which interacts with protocols from other 524 standards bodies as well as from other IETF working groups, it can be 525 necessary to keep in mind the overall picture while, at the same 526 time, breaking out specific parts of the problem to be standardized 527 in particular working groups. 529 Question: Have you considered the larger context, while restricting 530 your own design efforts to one part of the whole? 532 Question: Are there parts of the overall solution that will have to 533 be provided by other IETF Working Groups or by other standards 534 bodies? 536 12.1. Case Study: The Session Initiation Protocol (SIP) 538 The Session Initiation Protocol (SIP) [RFC2543], for managing 539 connected, multimedia sessions, is an example of a complex protocol 540 that has been broken into pieces for standardization in other working 541 groups. SIP has also involved interaction with other standardization 542 bodies. 544 The basic SIP framework is being standardized by the SIP working 545 group. This working group has focused on the core functional 546 features of setting up, managing, and tearing down multimedia 547 sessions. Extensions are considered if they relate to these core 548 features. 550 The task of setting up a multimedia session also requires a 551 description of the desired multimedia session. This is provided by 552 the Session Description Protocol (SDP). SDP is a building block that 553 is supplied by the Multiparty Multimedia Session Control (MMUSIC) 554 working group. It is not standardized within the SIP working group. 556 Other working groups are involved in standardizing extensions to SIP 557 that fall outside of core functional features or applications. The 558 SIPPING working group is analyzing the requirements for SIP applied 559 to different tasks, and the SIMPLE working group is examining the 560 application of SIP to instant messaging and presence. The IPTEL 561 working group is defining a call processing language (CPL) that 562 interacts with SIP in various ways. These working groups occasionally 563 feed requirements back into the main SIP working group. 565 Finally, outside standardization groups have been very active in 566 providing the SIP working group with requirements. The Distributed 567 Call Signaling (DCS) group from the PacketCable Consortium, 3GPP, and 568 3GPP2 are all using SIP for various telephony-related applications, 569 and members of these groups have been involved in drafting 570 requirements for SIP. In addition, there are extensions of SIP which 571 are under consideration in these standardization bodies that are not 572 appropriate material for IETF, because they are not generally 573 applicable but only relate to the particular application of SIP being 574 developed by the standardization bodies. An example is particular 575 interactions with accounting and billing for mobile telephony. 577 13. Preserving evolvability? 579 Does the protocol protect the interests of the future, by preserving 580 the evolvability of the Internet? Does the protocol enable future 581 developments? 583 13.1. Discussion: evolvability. 585 There is an extensive literature and an ongoing discussion about the 586 evolvability, or lack of evolvability, of the Internet 587 infrastructure; the web page on "Papers on the Evolvability of the 588 Internet Infrastructure" has pointers to some of this literature 589 [Evolvability]. Issues range from the evolvability and overloading 590 of the DNS; the difficulties of the Internet in evolving to 591 incorporate multicast, QoS, or IPv6; the difficulties of routing in 592 meeting the demands of a changing and expanding Internet; and the 593 role of firewalls and other middleboxes in limiting evolvability. 595 [CWSB02] suggests that among all of the issues of evolvability, 596 "keeping the net open and transparent for new applications is the 597 most important goal." In the beginning, the relative transparency of 598 the infrastructure in transmitting packets from one end-node to 599 another was sufficient to ensure evolvability. However, this 600 transparency has become more murky over time, as cataloged in 601 [RFC3234]. [CWSB02] also realistically suggests the following 602 guideline: "Failures of transparency will occur - design what happens 603 then." Thus, maintaining evolvability also requires mechanisms for 604 allowing evolution in the face of a lack of transparency of the 605 infrastructure itself. 607 14. Conclusions 609 This document, in progress, suggests general architectural and policy 610 questions to be addressed in our work in the IETF. We would welcome 611 feedback on this document. Feedback could be send to the editor, 612 Sally Floyd, at floyd@icir.org. 614 15. Acknowledgements 616 This document has borrowed text freely from other IETF RFCs, and has 617 drawn on ideas from [ASSW02], [CWSB02], [M01] and elsewhere. This 618 document has developed from discussions in the IAB, and has drawn 619 from suggestions made at IAB Plenary sessions and on the ietf general 620 discussion mailing list. The case study on SIP was contributed by 621 James Kempf, and the case study on Stresses on DNS was contributed by 622 Karen Sollins. We have also benefited from discussions with Noel 623 Chiappa, Karen Sollins, John Wroclawski, and others. 625 16. Normative References 627 17. Informative References 629 [A02] Harald Alvestrand, "Re: How many standards or protocols...", 630 email to the ietf discussion mailing list, Message-id: 631 <598204031.1018942481@localhost>, April 16, 2002. 633 [ASSW02] T. Anderson, S. Shenker, I. Stoica, and D. Wetherall, 634 "Towards More Robust Internet Protocols", February 2002. [No public 635 URL yet.] 637 [CA02] B. Carpenter and R. Austein, "Recent Changes in the 638 Architectural Principles of the Internet", draft-iab-arch- 639 changes-00.txt, work in progress, February 2002. 641 [CDT01] Policy Concerns Raised by Proposed OPES Working Group 642 Efforts, email to the IESG, from the Center for Democracy & 643 Technology, August 3, 2001. URL "http://www.imc.org/ietf- 644 openproxy/mail-archive/msg00828.html". 646 [Clark88] David D. Clark, The Design Philosophy of the DARPA Internet 647 Protocols, SIGCOMM 1988. 649 [CWSB02] Clark, D., Wroslawski, J., Sollins, K., and Braden, R., 650 "Tussle in Cyberspace: Defining Tomorrow's Internet", draft, March 651 2002. To appear in SIGCOMM 2002. [No public URL yet.] 653 [F02] Floyd, S., "Inappropriate TCP Resets Considered Harmful", 654 draft-floyd-tcp-reset-03.txt, work in progress, April 2002. 656 [Evolvability] Floyd, S., "Papers on the Evolvability of the Internet 657 Infrastructure". Web Page, URL 658 "http://www.icir.org/floyd/evolution.html". 660 [K02] John C. Klensin, "Role of the Domain Name System", draft- 661 klensin-dns-role-02.txt, internet-draft, work in progress, February 662 2002. 664 [Layering] Floyd, S., "References on Layering and the Internet 665 Architecture", Web Page, URL "http://www.icir.org/floyd/layers.html". 667 [Multiplexing] S. Floyd, "Multiplexing, TCP, and UDP: Pointers to the 668 Discussion", Web Page, URL "http://www.icir.org/floyd/tcp_mux.html". 670 [M01] Tim Moors, A Critical Review of End-to-end Arguments in System 671 Design, 2001. URL "http://uluru.poly.edu/~tmoors/". 673 [RFC1958] B. Carpenter, "Architectural Principles of the Internet", 674 RFC 1958, June 1996. 676 [RFC2211] Wroclawski, J., "Specification of the Controlled Load 677 Quality of Service", RFC 2211, September 1997. 679 [RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification 680 of Guaranteed Quality of Service", RFC 2212, September 1997. 682 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. 683 and W. Weiss, "An Architecture for Differentiated Services", RFC 684 2475, December 1998. 686 [RFC2481] K. K. Ramakrishnan and S. Floyd, A Proposal to add Explicit 687 Congestion Notification (ECN) to IP, RFC 2481, January 1999. 689 [RFC2543] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, 690 "SIP: Session Initiation Protocol", RFC 25434, March 1999. 692 [RFC2597] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, 693 "Assured Forwarding PHB Group", RFC 2597. June 1999. 695 [RFC2598] Jacobson, V., Nichols, K. and K. Poduri, "An Expedited 696 Forwarding PHB", RFC 2598, June 1999. 698 [RFC2316] Bellovin, S., "Report of the IAB Security Architecture 699 Workshop", RFC 2316, April 1998. 701 [RFC3124] H. Balakrishnan and S. Seshan, "The Congestion Manager", 702 RFC 3124, June 2001. 704 [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G. and Z. 705 Shelby, "Performance Enhancing Proxies Intended to Mitigate Link- 706 Related Degradations", RFC 3135, June 2001. 708 [RFC3168] K.K. Ramakrishnan, S. Floyd, and D. Black, The Addition of 709 Explicit Congestion Notification (ECN) to IP, RFC 3168, Proposed 710 Standard, September 2001. 712 [RFC3205] K. Moore, "On the use of HTTP as a Substrate", RFC 3205, 713 February 2002. 715 [RFC3234] B. Carpenter and S. Brim, "Middleboxes: Taxonomy and 716 Issues", RFC 3234, February 2002. 718 [RFC3238] S. Floyd and L. Daigle, "IAB Architectural and Policy 719 Considerations for Open Pluggable Edge Services", RFC 3238, 720 Informational, January 2002. 722 [SCWA99] TCP Congestion Control with a Misbehaving Receiver, ACM 723 Computer Communications Review, October 1999. 725 [SRC84] J. Saltzer, D. Reed, and D. D. Clark, "End-To-End Arguments 726 In System Design", ACM Transactions on Computer Systems, V.2, N.4, p. 727 277-88. 1984. 729 [T89] D. Tennenhouse, "Layered Multiplexing Considered Harmful", 730 Protocols for High-Speed Networks, 1989. 732 [UNSAF] L. Daigle, "IAB Considerations for UNilateral Self-Address 733 Fixing (UNSAF)", draft-iab-unsaf-considerations-01.txt, internet- 734 draft, work in progress, February 2002. 736 18. Security Considerations 738 This document does not propose any new protocols, and therefore does 739 not involve any security considerations in that sense. However, 740 throughout this document there are discussions of the privacy and 741 integrity issues and the architectural requirements created by those 742 issues. 744 19. IANA Considerations 746 There are no IANA considerations regarding this document. 748 AUTHORS' ADDRESSES 750 Internet Architecture Board 751 EMail: iab@iab.org 753 IAB Membership at time this document was completed: 755 Harald Alvestrand 756 Ran Atkinson 757 Rob Austein 758 Fred Baker 759 Leslie Daigle 760 Steve Deering 761 Sally Floyd 762 Ted Hardie 763 Geoff Huston 764 Charlie Kaufman 765 James Kempf 766 Eric Rescorla 767 Mike St. Johns 769 This draft was created in May 2002.