idnits 2.17.1 draft-iab-mpls-tp-uncoord-harmful-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 (July 10, 2009) is 5404 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-10) exists of draft-ietf-mpls-tp-requirements-09 -- Obsolete informational reference (is this intentional?): RFC 1393 (Obsoleted by RFC 6814) -- Obsolete informational reference (is this intentional?): RFC 4379 (Obsoleted by RFC 8029) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Bryant, Ed. 3 Internet-Draft M. Morrow, Ed. 4 Intended status: Informational On behalf of the IAB 5 Expires: January 11, 2010 July 10, 2009 7 "Uncoordinated Protocol Development Considered Harmful" 8 draft-iab-mpls-tp-uncoord-harmful-01.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on January 11, 2010. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 This document identifies various types of damage that may occur 47 without formal coordination and joint development on protocols of 48 mutual interest between standards development organizations. The IAB 49 has selected T-MPLS as recent case study to describe hazard to both 50 the MPLS and Internet architecture as a result of uncoordinated 51 adaptation of a protocol. 53 This experience has resulted in a considerable improvement in the 54 relationship between the two organisations. In particular, this was 55 achieved via the establishment of the "Joint working team on MPLS-TP" 56 which was the first ever joint ITU/IETF group. In addition, the 57 leadership of the two organisations have agreed to improve inter- 58 organizational working practices so as to avoid conflict in future 59 between ITU-T Recommendations and IETF RFCs. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. Protocol Safety . . . . . . . . . . . . . . . . . . . . . . . 5 65 2.1. Importance of Invariants . . . . . . . . . . . . . . . . . 5 66 2.2. Importance of Correct Identification . . . . . . . . . . . 5 67 2.3. The Role of the Design Authority . . . . . . . . . . . . . 6 68 2.4. Ships in the Night . . . . . . . . . . . . . . . . . . . . 6 69 3. T-MPLS As a Case Study . . . . . . . . . . . . . . . . . . . . 7 70 3.1. Multiple Definitions of Label 14 . . . . . . . . . . . . . 7 71 3.2. Redefinition of TTL Semantics . . . . . . . . . . . . . . 8 72 3.3. Reservation of Additional Labels . . . . . . . . . . . . . 8 73 3.4. Redefinition of MPLS EXP Bits . . . . . . . . . . . . . . 9 74 3.5. The Consequences for the Network Operators . . . . . . . . 9 75 3.6. The Consequences for the SDOs . . . . . . . . . . . . . . 9 76 4. MPLS-TP As Best Practice . . . . . . . . . . . . . . . . . . . 10 77 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 11 78 6. Security considerations . . . . . . . . . . . . . . . . . . . 12 79 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 80 8. Generalization from this Case Study . . . . . . . . . . . . . 14 81 9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 15 82 10. Informative references . . . . . . . . . . . . . . . . . . . . 16 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 85 1. Introduction 87 The uncoordinated adaptation of a protocol, parameter, or code-point 88 by a standards development organization (SDO), either through the 89 allocation of a code-point without following the formal registration 90 procedures, or by unilaterally modifying the semantics of the 91 protocol or intended use of the code-point itself, poses a risk of 92 harm to the Internet [RFC4775]. 94 The purpose of this document is to describe the various types of 95 damages that may occur without formal coordination and joint 96 development on protocols of mutual interest between SDOs. In 97 particular, the IAB considers an essential principle of the protocol 98 development process that only one SDO maintains design authority for 99 a given protocol, with that SDO having ultimate authority over the 100 allocation of protocol parameter code-points; defining the intended 101 semantics, interpretation, and actions associated with those code- 102 points. 104 There is currently a joint IETF - ITU-T development effort underway, 105 known as MPLS Transport Profile (MPLS-TP), which is progressing 106 rapidly to extend MPLS in a way that is consistent with the MPLS 107 architecture, and fully satisfies the requirements of the transport 108 network provider [LS26]. By way of a case study we will refer to the 109 design and standardization process of the ITU-T protocol known as 110 Transport MPLS (T-MPLS). Development of T-MPLS was abandoned 111 [RFC5317] by ITU-T Study Group 15 due to inherent conflicts with the 112 IETF MPLS design and in particular with the Internet architecture. 113 These conflicts arose due to the lack of coordination with the IETF 114 as the design authority for MPLS. 116 The goal of this document is to demonstrate the importance of a 117 coordinated approach to successful collaboration between SDOs, and to 118 explain a model for inter-SDO collaborative protocol development that 119 is being used successfully by the ITU-T and IETF. 121 2. Protocol Safety 123 To understand the reasons why the IAB and the IETF regards 124 uncoordinated use of code-points and/or protocol modification as 125 posing a risk of harm to the Internet, it is necessary to recap some 126 important principles of protocol design in large scale networks such 127 as the Internet. Large scale networks represent significant economic 128 value. Any outage in a large scale network due to a protocol failure 129 will therefore result in significant commercial and political damage. 130 When two incompatible protocols, or forms of the same protocol, are 131 deployed without coordination, there is a serious risk that this may 132 be catastrophic to the stability or security of the network. 133 Furthermore, the scale and distributed nature of the Internet is such 134 that it is impossible to coordinate a network wide restart to rid the 135 network of the long- term consequences of the protocol 136 incompatibility. Therefore, the following issues are of critical 137 importance. 139 2.1. Importance of Invariants 141 Invariants are core properties that are consistent across the network 142 and do not change over extremely long time-scales. Protocol 143 designers use such invariants as axioms in designing protocols. A 144 protocol often places an absolute reliance on an invariant to resolve 145 a design corner case. One example of an invariance in IP that was 146 inherited in the design of MPLS is the invariant that a time to live 147 (TTL) value is monotonically decreased and that a packet with TTL<=1 148 will not be forwarded. This is a safety mechanism to mitigate the 149 damaging effects of packet forwarding loops. Another example is the 150 way that MPLS applies special semantics to the reserved label set 151 [RFC3032] (0..15), and the notion that a Label Switched Router (LSR) 152 is free to allocate labels with a value of 16 or greater for its own 153 use. 155 2.2. Importance of Correct Identification 157 A special type of invariant is the allocation of a code-point. A 158 code-point may be used to identify a packet type or a component 159 within a packet. Without these identifiers, a packet is an opaque 160 sequence of bits. A packet parser operates by first identifying the 161 code-point and then using the semantics associated with that code- 162 point to interpret other components within the packet. Once a code- 163 point is defined the interpretation of associated data and the 164 consequential actions becomes a protocol invariant. Subsequent 165 protocol development must adhere to those invariants. The semantics 166 for an allocated code point must never change. If a future 167 enhancement requires different semantics, interpretation, or action, 168 then a new code point must be obtained. 170 2.3. The Role of the Design Authority 172 A code-point such as an IEEE Ethertype is allocated to a design 173 authority such as the IETF. It is this design authority that 174 establishes how information identified by the code-point is to be 175 interpreted to associate appropriate invariants. Modification and 176 extension of a protocol requires great care. In particular it is 177 necessary to understand the exact nature of the invariants and the 178 consequences of modification. This may not always be the case when 179 protocols are modified by organizations without the experience of the 180 original designers, or the design authority expert pool. 181 Furthermore, since there can only safely be a single interpretation 182 of the information identified by a code-point, there must be a unique 183 authority responsible for authorizing and documenting the semantics 184 of the information and consequential protocol actions. 186 In the case of IP and MPLS technologies, the design authority is the 187 IETF. The IETF has an internal process for evolving and maintaining 188 the protocols for which it is the design authority. The IETF also 189 has change processes in place [RFC4929] to work with other SDOs that 190 require enhancements to its protocols and architectures. Similarly, 191 the ITU has design authority for Recommendation E.164 [E.164] and 192 allocates the relevant code points, even though the IETF has design 193 authority for the protocols ("ENUM") used to access E.164 numbers 194 through the Internet DNS [RFC3245]. 196 2.4. Ships in the Night 198 It may be tempting for a designer to assert that the protocol 199 extensions it proposes are safe even though it breaks the invariants 200 of the original protocol because these protocol variants will operate 201 as ships in the night. That is, these protocol variants will never 202 simultaneously exist in the same network domain and will never need 203 to inter-work. This is a fundamentally unsound assumption for a 204 number of reasons. First, it is infeasible to ensure that the two 205 instances will never be interconnected under any circumstances. 206 Second, even if the operators that deploy the protocols apply 207 appropriate due diligence to ensure that the two instances do not 208 conflict, it is infeasible to ensure that such conflicting protocols 209 will not be interconnected under fault conditions. 211 This assumption of ships in the night is particularly hazardous when 212 the instances of the protocol share the same identifying code-point. 213 This is because a system is unable to determine which variant of the 214 protocol it has received, and hence how to correctly interpret the 215 associated information or to determine what protocol actions may be 216 safely executed. 218 3. T-MPLS As a Case Study 220 In order to illustrate the issues that arise from uncoordinated 221 protocol development called out above we will use the ITU-T T-MPLS 222 protocol as a recent example. 224 3.1. Multiple Definitions of Label 14 226 To appreciate why the use of MPLS Reserved Label 14 by the T-MPLS 227 protocol represented a safety concern to the Internet, it is 228 important to understand the current standards that use MPLS Reserved 229 Label 14. 231 The governing standard on the use of MPLS Reserved Label 14 is 232 [RFC3429], "Assignment of the 'OAM Alert Label' for Multi-protocol 233 Label Switching Architecture (MPLS) Operation and Maintenance (OAM) 234 Functions". 236 Label 14 is assigned to a specific protocol, namely, ITU-T 237 Recommendation [Y.1711-2002]. 239 ITU-T Recommendation [Y.1711-2002] has been superseded by newer 240 versions, specifically: - [Y.1711-2004], [Y.1711cor1] and 241 [Y.1711am1]. 243 All three documents are currently in-force as ITU-T Recommendations. 245 The problem is that the changes made to Y.1711 were never reflected 246 in an update to RFC 3429 which only defines the protocol as specified 247 by the now superseded 2002 Recommendation. So for example, MPLS 248 equipment responding to an MPLS packet containing Label 14 would 249 expect to see the 2002 version of Y.1711 [Y.1711-2002] protocol and 250 would not recognize any of the new function codes specified in Y.1711 251 Amendment 1. This problem arises because Y.1711 does not have a 252 version field, and RFC 3429 offers no other method to disambiguate 253 non-interoperable versions of Y.1711. Having a version number in the 254 protocol permits an implementer to codify non-interoperability. 255 Furthermore, the IETF as the authority over Label 14 semantics has 256 the final say over maintaining the interoperability of the protocol 257 employing that code-point, unless the IETF explicitly delegates such 258 authority. 260 With regard to T-MPLS there was a lack of coordination between the 261 ITU-T and the IETF over the redefinition of the semantics of MPLS 262 label 14, which resulted in protocol definitions that conflicted with 263 the IETF MPLS Architecture. 265 The MPLS architecture [RFC3031], defines a swap operation as an 266 atomic function that replaces the top label in an MPLS label stack 267 with another label which provides context for the next hop LSR. 268 However the ITU-T Recommendations that specified the new OAM 269 functions defined by Label 14 redefined the label swap operation as a 270 POP, followed by a PUSH, thereby causing all LSRs to inspect the 271 label stack for the presence of Label 14 at each hop. This proposed 272 new behaviour conflicts with the IETF definition of a swap operation. 273 The behaviour proposed in these specifications would have had major 274 consequences for deployed hardware designs. The outcome would have 275 been that the equipments built according to the two different 276 specifications would have been incompatible. It is important that 277 the atomic procedure defined in [RFC3031] is kept unchanged. 279 3.2. Redefinition of TTL Semantics 281 The standard method of delivering an OAM message to an entity on a 282 label switched path (LSP) such that the OAM message fate shares with 283 the data traffic is to use TTL expiry. The IETF's Internet Protocol 284 (IP) utilizes this mechanism for traceroute [RFC1393], as does MPLS 285 ping [RFC4379]. 287 At one stage, the T-MPLS designers considered a multi-level OAM 288 design in which the OAM packet was steered to its target by a process 289 in which some nodes increased the TTL as they forwarded the OAM 290 packet to its next hop. TTL is a safety device in the IETF IP and 291 MPLS architecture that prevents a packet from continuously looping 292 under fault conditions. Thus the proposed extension to support an 293 enhanced OAM mechanism violated an MPLS design invariant specifically 294 introduced to ensure safe operation of the Internet by preventing 295 persistent forwarding loops. 297 3.3. Reservation of Additional Labels 299 The IETF MPLS protocol uses a small number of reserved labels 300 [RFC3032] as a mechanism to provide additional context and to trigger 301 some special processing operations in the forwarder. All other 302 labels used for forwarding use semantics defined by the forwarding 303 equivalence class (FEC). In an early implementation of T-MPLS the 304 designers determined that they needed some additional labels to alert 305 the forwarder that the packet needed special processing. Thus a 306 conflict was thereby introduced between the behaviour of an IETF MPLS 307 LSR, and LSRs that operate according to the specification in the 308 ITU-T Recommendation. Thus some LSRs would attribute special 309 semantics to labels 16..31, whist other LSRs would perform normal 310 forwarding on them. 312 3.4. Redefinition of MPLS EXP Bits 314 The early MPLS documents defined the form of the MPLS label stack 315 entry [RFC3032]. This includes a three-bit field called the "EXP 316 field". The exact use of this field was not defined by these 317 documents, except to state that it was to be "reserved for 318 experimental use". 320 Although the intended use of the EXP field was as a "Class of 321 Service" (CoS) field, it was not named a CoS field by these early 322 documents because the use of such a CoS field was not considered to 323 be sufficiently defined. Today a number of standards documents 324 define its usage as a CoS field [RFC3270], [RFC5129], and hardware is 325 deployed that assumes this exclusive usage. 327 The T-MPLS designers, unaware of the historic reason for the 328 "provisional" naming of this field assumed that they were available 329 for any experimental use and re-purposed them to indicate the 330 maintenance entity level (a hierarchical maintenance mechanism). 332 The intended use of the EXP field was subsequently carried in 333 [RFC5462], which reinforces this by formally changing the name to 334 Traffic Class (TC). 336 3.5. The Consequences for the Network Operators 338 Two consequences arose for the users of the T-MPLS protocol. 339 Firstly, those who have deployed T-MPLS in production networks have 340 exposed their network to hazards explicitly guaranteed by the IETF 341 MPLS protocol suite to not occur. 343 The second consequence was to delay the necessary enhancements to 344 MPLS to meet their needs [I-D.ietf-mpls-tp-requirements] as the IETF 345 and ITU-T executed a redevelopment of MPLS-based transport network 346 protocols. 348 3.6. The Consequences for the SDOs 350 The process of resolution required considerable resources and 351 introduced a great deal of conflict between the IETF and the ITU-T, 352 much of which was exposed to public scrutiny, to the detriment of 353 both organizations. In particular this conflict resolution process 354 consumed the very resources required to develop an optimal 355 architecture for MPLS in transport networks. 357 4. MPLS-TP As Best Practice 359 In order to bridge the gap between the two organizations, the IETF 360 and the ITU-T established a joint working team (JWT) to assess 361 whether it was possible to enhance existing MPLS standards to provide 362 a best in class solution for transport networks. The outcome of this 363 investigation is reported in [RFC5317]. 365 The JWT proposed a design that was acceptable to both SDOs. This has 366 lead to the creation of the MPLS-TP project. This is a joint project 367 in which the ITU-T experts work with the IETF on protocol development 368 tasks; and IETF members work within the ITU-T to understand 369 requirements, and to assist in the creation of the ITU-T 370 recommendations that describe MPLS-TP in which the technical 371 definition is provided through normative references to IETF RFCs. 373 5. IANA considerations 375 There are no requests for IANA allocation of code-points in this 376 document, nor are any other IANA actions required. 378 6. Security considerations 380 The uncoordinated development of protocols is poses a risk of harm to 381 the Internet and must not be permitted. The enhancement or 382 modification of a protocol can increase attack surfaces considerably 383 and may therefore compromise the security or stability of the 384 Internet. The IETF has a review process that combines cross area 385 review with specialist security review by experts familiar with the 386 development and deployment context of the Internet protocol suite. 387 In particular, because of the Internet infrastructure's reliance on 388 the IP and MPLS protocol suites, this security review process must be 389 exercised with considerable diligence. Failure to apply this review 390 process exposes the Internet to increased risk along both security 391 and stability vectors. 393 7. Acknowledgments 395 The authors wish to acknowledge Loa Andersson and the members of the 396 2009/2010 Internet Architecture Board. 398 8. Generalization from this Case Study 400 Although we have used T-MPLS as a case study, there are other ongoing 401 ITU-T projects and core IETF specifications that could be the subject 402 of either improved coordination or new conflicts, depending on 403 whether or not the principles outlined in this document are adhered 404 to by the IETF and ITU., Two current examples are: [Y.2015] , and 405 [Q.Flowsig] . New areas with potential for cooperation or conflict 406 are emerging from the work of ITU-T SG13 Question 7, "IPv6" for 407 example: [Y.ipv6split] and [Y.ipv6migration]. 409 9. Conclusion 411 It is important that all SDOs developing standards that effect the 412 operation of the Internet learn the lessons that arise from the 413 T-MPLS experience. Uncoordinated parallel work between SDOs creates 414 significant problems with potentially damaging operation impact to 415 those that deploy and use the Internet. SDOs need to work jointly on 416 new projects in such a way that the safety of the Internet is assured 417 and the expertise of the organizations concerned is applied 418 optimally. 420 10. Informative references 422 [E.164] ITU-T, "ITU Recommendation E.164: The international public 423 telecommunication numbering plan", February 2005. 425 [I-D.ietf-mpls-tp-requirements] 426 Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., 427 and S. Ueno, "MPLS-TP Requirements", 428 draft-ietf-mpls-tp-requirements-09 (work in progress), 429 June 2009. 431 [LS26] ITU-T Study Group 15, "Cooperation Between IETF and ITU-T 432 on the Development of MPLS-TP, Geneva, 1-12 December 2008, 433 https://datatracker.ietf.org/documents/LIAISON/ 434 file596.pdf". 436 [Q.Flowsig] 437 ITU-T Study Group 11, "ITU-T Study Group 11, Question 5, 438 Signalling protocols and procedures relating to flow state 439 aware access QoS control in an NGN; draft 440 Recommendation.". 442 [RFC1393] Malkin, G., "Traceroute Using an IP Option", RFC 1393, 443 January 1993. 445 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 446 Label Switching Architecture", RFC 3031, January 2001. 448 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 449 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 450 Encoding", RFC 3032, January 2001. 452 [RFC3245] Klensin, J. and IAB, "The History and Context of Telephone 453 Number Mapping (ENUM) Operational Decisions: Informational 454 Documents Contributed to ITU-T Study Group 2 (SG2)", 455 RFC 3245, March 2002. 457 [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, 458 P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi- 459 Protocol Label Switching (MPLS) Support of Differentiated 460 Services", RFC 3270, May 2002. 462 [RFC3429] Ohta, H., "Assignment of the 'OAM Alert Label' for 463 Multiprotocol Label Switching Architecture (MPLS) 464 Operation and Maintenance (OAM) Functions", RFC 3429, 465 November 2002. 467 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 468 Label Switched (MPLS) Data Plane Failures", RFC 4379, 469 February 2006. 471 [RFC4775] Bradner, S., Carpenter, B., and T. Narten, "Procedures for 472 Protocol Extensions and Variations", BCP 125, RFC 4775, 473 December 2006. 475 [RFC4929] Andersson, L. and A. Farrel, "Change Process for 476 Multiprotocol Label Switching (MPLS) and Generalized MPLS 477 (GMPLS) Protocols and Procedures", BCP 129, RFC 4929, 478 June 2007. 480 [RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion 481 Marking in MPLS", RFC 5129, January 2008. 483 [RFC5317] Bryant, S. and L. Andersson, "Joint Working Team (JWT) 484 Report on MPLS Architectural Considerations for a 485 Transport Profile", RFC 5317, February 2009. 487 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 488 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 489 Class" Field", RFC 5462, February 2009. 491 [Y.1711-2002] 492 ITU-T Study Group 13, "ITU-T Recommendation Y.1711 "OAM 493 mechanism for MPLS networks", November 2002". 495 [Y.1711-2004] 496 ITU-T Study Group 13, "ITU-T Recommendation Y.1711 "OAM 497 mechanism for MPLS networks", February 2004". 499 [Y.1711am1] 500 ITU-T Study Group 13, "ITU-T Recommendation Y.1711 501 Amendment 1, New Function Type Codes, October 2005.". 503 [Y.1711cor1] 504 ITU-T Study Group 13, "ITU-T Recommendation Y.1711 (2004) 505 corrigendum 1, February 2005.". 507 [Y.2015] ITU-T Study Group 13, "ITU-T Study Group 13, Question 5, 508 "General Requirements for ID/Locator Separation in NGN"". 510 [Y.ipv6migration] 511 ITU-T, "ITU draft Y.ipv6migration : Roadmap for IPv6 512 migration from NGN operators perspective", 2009. 514 [Y.ipv6split] 515 ITU-T, "ITU draft Y.ipv6split : Framework of ID/LOC 516 separation in IPv6-based NGN", 2009. 518 Authors' Addresses 520 Stewart Bryant (editor) 521 On behalf of the IAB 523 Phone: 524 Fax: 525 Email: stbryant@cisco.com 526 URI: 528 Monique Morrow (editor) 529 On behalf of the IAB 531 Phone: 532 Fax: 533 Email: mmorrow@cisco.com 534 URI: