idnits 2.17.1 draft-thaler-transition-principles-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 5, 2015) is 3125 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-09) exists of draft-iab-filtering-considerations-07 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Architecture Board D. Thaler 3 Internet-Draft Microsoft 4 Intended status: Informational October 5, 2015 5 Expires: April 7, 2016 7 Designing for Transition 8 draft-thaler-transition-principles-00.txt 10 Abstract 12 Over the many years since the introduction of the Internet Protocol, 13 we have seen a number of transitions, throughout the protocol stack, 14 from one protocol or technology to another. Many protocols and 15 technologies were not designed to enable smooth transition to 16 alternatives or to easily deploy extensions, and thus some 17 transitions, such as the introduction of IPv6, have been difficult. 18 This document attempts to summarize some basic principles to enable 19 future transitions, and also summarizes what makes for a good 20 transition plan. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 7, 2016. 39 Copyright Notice 41 Copyright (c) 2015 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Transition vs. Co-existence . . . . . . . . . . . . . . . . . 4 58 3. Translation/Adaptation Location . . . . . . . . . . . . . . . 4 59 4. Translation Plans . . . . . . . . . . . . . . . . . . . . . . 5 60 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 62 7. Informative References . . . . . . . . . . . . . . . . . . . 5 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 65 1. Introduction 67 A "transition" is "the process or period of changing from one state 68 or condition to another. There are several types of such 69 transitions, including both technical transitions (e.g., changing a 70 protocol or deploying an extension) and organizational transitions 71 (e.g., changing what organization manages the IETF web site, or the 72 RFC production center). This document focuses solely on technical 73 transitions, although some principles might apply to other types as 74 well. 76 There have been many IETF and IAB RFCs and IAB statements discussing 77 transitions of various sorts. Most are protocol-specific documents 78 about specific transitions. For example, some relevant ones in which 79 the IAB has been involved include: 81 o IAB RFC 3424 [RFC3424] recommended that any technology for so- 82 called "unilateral self-address fixing (UNSAF)" across NATs 83 include an exit strategy/plan to transition away from such a 84 mechanism. Since the IESG, not the IAB, approves IETF documents, 85 the IESG thus became the body to enforce (or not) such a 86 requirement. 88 o IAB RFC 4690 [RFC4690] gave recommendations around 89 internationalized domain names. It discussed issues around the 90 process of transitioning to new versions of Unicode, and this 91 resulted in the creation of the IETF Precis WG to address this 92 problem. 94 o The IAB statement on "Follow-up-work on NAT-PT" 95 [IabIpv6TransitionStatement] pointed out gaps at the time in 96 transitioning to IPv6, and this resulted in the rechartering of 97 the IETF Behave WG to solve this problem. 99 More recently, the IAB has done work on more generally applicable 100 principles, including two RFCs. 102 IAB RFC 5218 [RFC5218] on "What Makes for a Successful Protocol?" 103 studied specifically what factors contribute to, and detract from, 104 the success of a protocol and it made a number of recommendations. 105 It discussed two types of transitions: "initial success" (the 106 transition to the technology) and extensibility (the transition to 107 updated versions of it). The principles and recommendations in that 108 document are generally applicable to all technical transitions. Some 109 important principles included: 111 1. Incentive: Transition is easiest when the benefits come to those 112 bearing the costs. That is, the benefits should outweigh the 113 costs at *each* entity. Some successful cases did this by 114 providing incentives (e.g., tax breaks), or by reducing costs 115 (e.g., freely available source), or by imposing costs of not 116 transitioning (e.g., regulation), or even by narrowing the 117 scenarios of applicability to just the cases where benefits do 118 outweigh costs. 120 2. Incremental Deployability: Backwards compatibility makes 121 transition easier. Furthermore, transition is easiest when 122 changing only one entity still benefits that entity. In the 123 easiest case, the benefit immediately outweighs the cost and so 124 entities are naturally incented to transition. More commonly, 125 the benefits only outweigh the costs once a significant number of 126 other entities also transition. Unfortunately, in such cases, 127 the natural incentive is often to delay transitioning. 129 3. Total Cost: Don't underestimate the cost of things other than the 130 hardware/software itself. For example, operational tools and 131 processes, personnel training, business model (accounting/ 132 billing) dependencies, and legal (regulation, patents, etc.) 133 costs all add up. 135 4. Extensibility: Design for extensibility so that things can be 136 fixed up later. 138 IAB RFC 7305 [RFC7305] reported on a IAB workshop on Internet 139 Technology Adoption and Transition (ITAT). Like RFC 5218, this 140 workshop also discussed economic aspects of transition, not just 141 technical aspects. Some important observations included: 143 1. Early-Adopter Incentives: Part of Bitcoin's strategy was extra 144 incentives for early adopters. That is, providing a long-term 145 advantage to early adopters can help stimulate transition even 146 when the initial costs outweigh the initial benefit. 148 2. Policy Partners: Policy-making organizations of various sorts 149 (RIRs, ICANN, etc.) can be important partners in enabling and 150 facilitating transition. 152 The remainder of this document continues the discussion in those two 153 RFCs and provides some additional thoughts on the topic of transition 154 strategies and plans. 156 2. Transition vs. Co-existence 158 We need to distinguish between a strict "flag-day" style transition 159 where an old mechanism is immediately replaced with a new mechanism, 160 vs. a looser co-existence based approach where transition proceeds in 161 stages where a new mechanism is first added alongside an existing one 162 for some overlap period, and then the old mechanism is removed at a 163 later stage. 165 When a new mechanism is backwards compatible with an existing 166 mechanism, transition is easiest, and the difference between the two 167 types of transition is not particularly significant. However, when 168 no backwards compatibility exists (such as in the IPv4 to IPv6 169 transition), a transition plan must choose either a "flag day" or a 170 period of co-existence. When a large number of entities are 171 involved, a flag day becomes impractical. Coexistence, on the other 172 hand, involves additional costs of maintaining two separate 173 mechanisms during the overlap period which could be quite long. 174 Furthermore, the longer the overlap period, the more the old 175 mechanism might get further deployment and thus increase the overall 176 pain of transition. 178 Often the decision between a "flag day" and a sustained co-existence 179 period may be difficult, such as in the case of IDNA2008 [RFC5891] 180 [RFC5895] and Unicode TR46 [TR46]. 182 3. Translation/Adaptation Location 184 A translation or adaptation layer is often required if the old and 185 new mechanisms are not interoperable. Care must be taken when 186 determining where such a translator is best placed. 188 Requiring a translator in the middle of the path can hamper end-to- 189 end security and reliability. For example, see the discussion of 190 network-based filtering in [I-D.iab-filtering-considerations]. 192 On the other hand, requiring a translation layer within an endpoint 193 can be a resource issue in some cases, such as if the endpoint could 194 be a constrained node [RFC7228]. 196 Any transition strategy for a non-backward-compatible mechanism 197 should include a discussion of where it is placed and a rationale. 199 4. Translation Plans 201 A good transition plan includes at least the following components: 203 1. An explanation of incentives for each entity involved 205 2. A description of transition phases. For example, there might be 206 pilot, co-existence, deprecation, and removal phases, for a 207 transition from one technology to another incompatible one. 209 3. A proposed timeline 211 4. A way to effectively communicate the proposed plan to the 212 entities affected, and incorporate their feedback 214 5. Security Considerations 216 This document discusses attributes of protocol transitions. Some 217 types of transition can adversely affect security or privacy. For 218 example, requiring a translator in the middle of the path may hamper 219 end-to-end security and privacy, since it creates an attractive 220 target. For further discussion of some of these issues, see 221 Section 5 of [I-D.iab-filtering-considerations]. 223 6. IANA Considerations 225 This document requires no actions by the IANA. 227 7. Informative References 229 [I-D.iab-filtering-considerations] 230 Barnes, R., Cooper, A., Kolkman, O., and D. Thaler, 231 "Technical Considerations for Internet Service Blocking 232 and Filtering", draft-iab-filtering-considerations-07 233 (work in progress), July 2015. 235 [IabIpv6TransitionStatement] 236 IAB, "Follow-up work on NAT-PT", October 2007, 237 . 240 [RFC3424] Daigle, L., Ed. and IAB, "IAB Considerations for 241 UNilateral Self-Address Fixing (UNSAF) Across Network 242 Address Translation", RFC 3424, DOI 10.17487/RFC3424, 243 November 2002, . 245 [RFC4690] Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and 246 Recommendations for Internationalized Domain Names 247 (IDNs)", RFC 4690, DOI 10.17487/RFC4690, September 2006, 248 . 250 [RFC5218] Thaler, D. and B. Aboba, "What Makes For a Successful 251 Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008, 252 . 254 [RFC5891] Klensin, J., "Internationalized Domain Names in 255 Applications (IDNA): Protocol", RFC 5891, 256 DOI 10.17487/RFC5891, August 2010, 257 . 259 [RFC5895] Resnick, P. and P. Hoffman, "Mapping Characters for 260 Internationalized Domain Names in Applications (IDNA) 261 2008", RFC 5895, DOI 10.17487/RFC5895, September 2010, 262 . 264 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 265 Constrained-Node Networks", RFC 7228, 266 DOI 10.17487/RFC7228, May 2014, 267 . 269 [RFC7305] Lear, E., Ed., "Report from the IAB Workshop on Internet 270 Technology Adoption and Transition (ITAT)", RFC 7305, 271 DOI 10.17487/RFC7305, July 2014, 272 . 274 [TR46] Unicode Consortium, "Unicode IDNA Compatibility 275 Processing", June 2015, 276 . 278 Author's Address 280 Dave Thaler 281 Microsoft 282 One Microsoft Way 283 Redmond, WA 98052 284 US 286 Email: dthaler@microsoft.com