idnits 2.17.1 draft-andersson-mpls-tp-process-03.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 (June 30, 2009) is 5413 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC4379' is defined on line 613, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 5317 -- Obsolete informational reference (is this intentional?): RFC 4379 (Obsoleted by RFC 8029) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Andersson 3 Internet-Draft Ericsson Inc 4 Intended status: Standards Track D. Ward 5 Expires: January 1, 2010 Cisco Systems 6 M. Betts 7 Huaweil 8 June 30, 2009 10 Joint IETF and ITU-T Multi-Protocol Label Switching (MPLS) Transport 11 Profile process 12 draft-andersson-mpls-tp-process-03.txt 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on January 1, 2010. 37 Copyright Notice 39 Copyright (c) 2009 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents in effect on the date of 44 publication of this document (http://trustee.ietf.org/license-info). 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. 48 Abstract 50 The decision to develop a Multiprotocol Label Switching (MPLS) 51 Transport Profile in cooperation between IETF and ITU-T does not 52 fully define and document processes for development of the required 53 RFCs. 55 This document complements the processes documented in the JWT 56 decision with a few separate elements; it: 58 o provides an adaptation of the IETF working group process, 60 o identifies the expected participation in the process by the ITU-T, 62 o clarifies the decision rules regarding MPLS-TP documents. 64 This document is not intended to specify any ITU-T process; to the 65 extent necessary ITU-T activities will be done according to ITU-T 66 process/rules. 68 Nor is this document is intended to specify the IETF working group 69 process, it is limited to the temporary adaptations of that process 70 that is the result of that IETF and ITU-T accepted the proposal in 71 the JWT report to jointly develop the MPLS Transport Profile. In 72 general it may be said that these adaptations are introduced to 73 ensure a good and consistent document review across the two 74 organizations. 76 Table of Contents 78 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 79 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 80 1.1.1. IETF terms and abbreviations . . . . . . . . . . . . . 5 81 1.1.2. ITU-T terms and abbreviations . . . . . . . . . . . . 5 82 2. Adaptation of the IETF working group process . . . . . . . . . 7 83 2.1. Adaptation of the IETF working group process . . . . . . . 7 84 2.2. The IETF MPLS-TP process . . . . . . . . . . . . . . . . . 8 85 2.2.1. Developing a MPLS-TP document . . . . . . . . . . . . 9 86 3. Expectations on ITU-T participation in the process . . . . . . 14 87 3.1. Becoming a MEAD team document . . . . . . . . . . . . . . 14 88 3.2. Comments on MEAD team documents by participants in the 89 ITU-T . . . . . . . . . . . . . . . . . . . . . . . . . . 14 90 3.3. Poll for working group documents . . . . . . . . . . . . . 14 91 3.4. Responding to an IETF Working Group Last Call . . . . . . 15 92 4. Specific guidelines that apply to work on MPLS-TP in the 93 ITU-T . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 94 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 17 95 6. Security considerations . . . . . . . . . . . . . . . . . . . 18 96 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 97 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 98 8.1. Normative References . . . . . . . . . . . . . . . . . . . 20 99 8.2. Informative references . . . . . . . . . . . . . . . . . . 20 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 102 1. Introduction 104 When IETF and ITU-T entered into the agreement to develop MPLS-TP, 105 the JWT agreement included the decision that the MPLS-TP documents 106 should be developed "according to IETF processes". It was also 107 assumed that there would be close cooperation in reviewing these IETF 108 documents. The JWT decision is documented in RFC 5317 [RFC5317]. 110 However, the process for this close cooperative review was mostly 111 left to be decided as the documents evolved. The ITU-T committed to 112 responding promptly to IETF working group last calls, this may 113 require the development of the response via correspondence. 115 Nor is this document is intended to specify the IETF working group 116 process, it is limited to the temporary adaptations of that process 117 that is the result of that IETF and ITU-T accepted the proposal in 118 the JWT report to jointly develop the MPLS Transport Profile. In 119 general it may be said that these adaptations are introduced to 120 ensure a good and consistent document review across the two 121 organizations. 123 This document complements the process as documented in the JWT 124 decision with a few separate elements; it: 126 o Provides an adaptation of the IETF working group process, with 127 respect to the role of the teams (MPLS Interoperability Design 128 Team (MEAD Team), the Joint Working Team (JWT) and the ITU-T 129 MPLS-TP ad hoc team) that has been set up to facilitate the 130 development of MPLS-TP; see Section 2. 132 o Identifies the expected participation by the ITU-T in the document 133 development process; see Section 3. 135 o Clarifies decision rules regarding MPLS-TP documents; see 136 Section 4. 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in RFC 2119 [RFC2119]. 142 1.1. Terminology 144 This section includes a number of terms and abbreviations that are 145 used in this document. The section is split into two subsection; 146 IETF terms and ITU-T terms. 148 1.1.1. IETF terms and abbreviations 150 o JWT - Joint Working Team, a team with participants with experience 151 from standards development in the IETF and the ITU-T. 153 Note: The JWT is not part of either the IETF or ITU-T, but a group 154 that has been set up to facilitate cooperation on MPLS-TP between 155 the two organizations. 157 o JWT documents - the set of documents envisioned in the 158 documentation of the JWT decision, see RFC 5317 [RFC5317]. 160 o MEAD team - MPLS Interoperability Design Team, a temporary team 161 with participants with experience from standards development for 162 MPLS and transport networks. The MEAD team is chartered to 163 coordinate the development of MPLS-TP within the IETF and to 164 coordinate the on MPLS-TP cooperation with the ITU-T. 166 o MPLS-TP documents - the following sets of documents are counted as 167 MPLS-TP documents: 169 * Internet Drafts that are coordinated by the MEAD team. 171 * Individual Internet Drafts that addresses the MPLS-TP problem 172 space. 174 * Working group Internet Drafts that addresses the MPLS-TP 175 problem space. 177 * Internet Drafts that are considered for publication by the IESG 178 and that addresses the MPLS-TP problem space. 180 * Internet Drafts that are approved for publication by the IESG 181 and that addresses the MPLS-TP problem space. 183 * Published RFCs that addresses the MPLS-TP problem space. 185 * ITU-T Recommendations and draft Recommendations in various 186 stages of development that addresses the MPLS-TP problem space. 188 Documents that originates from the IRTF RFC stream is NOT considered 189 as MPLS-TP documents. 191 1.1.2. ITU-T terms and abbreviations 193 o Ad Hoc on MPLS-TP - A team established by SG 15 of ITU-T to 194 coordinate the work on MPLS-TP within the ITU-T and to act as a 195 focal point for communication with the IETF. 197 o Contribution - a contribution is a document that is submitted to 198 the ITU-T to advance work on the development of a Recommendation 199 or to propose the development of a new Recommendation. 201 o Recommendation - a Recommendation is the ITU-T standards document. 203 2. Adaptation of the IETF working group process 205 The IETF working group processes as defined in RFC 2026 [RFC2026] are 206 for the purpose of the MPLS-TP updated as follows. 208 The IETF works according to a 'rough consensus' model, where working 209 group chairs determine the consensus after discussions on the mailing 210 lists. This is applicable to the MPLS-TP work also. The 211 mpls-tp@ietf.org is the mailing list used to find out consensus and 212 consensus is determined by the MEAD team chair. After a document has 213 become a working group document the consensus is decided by the WG 214 chairs and the MEAD team chair jointly. 216 A most important part of this process is the information exchange 217 between the IETF and ITU-T. This information exchange consists of 218 two equally important pieces: 220 o informal information exchange 222 this is done primarily by E-Mail to the relevant mailing lists. 223 Information sent from IETF, IETF areas and working groups, or from 224 the IETF MEAD team are sent to and areas and the 225 ahmpls-tp@lists.itu.int mailing list. Information sent from ITU-T 226 to the IETF should e sent to the MEAD team (mead@ietf.org) and/or 227 the mpls-tp@ietf.org mailing list. 229 o formal information exchange 231 In addition to E-Mail, a formal information exchange is 232 accomplished by liaison correspondence between the two 233 organisations. Exchange of liaisons makes it possible to follow 234 the request/response exchange between the organisations in more 235 detail. 237 2.1. Adaptation of the IETF working group process 239 The flow chart below describes the adaption of the working group 240 process 241 ............. ............. 242 : Ind Docs :------+ : JWT docs : 243 ............. | ............. 244 | | | 245 | ind-00 (1) | ind-00 (2) | ind-00 (3) 246 | | | 247 v | v 248 +-----------+ | +----------------+ (4) +-------+ 249 | WG proc | +------->| MEAD team proc |<----->| ITU-T | 250 | |-------+ +--| | +-------+ 251 +-----------+ | | +----------------+ (5) | 252 +-> ind-00, ind-01, etc | | ind-00, ind-01, etc <-+<-----+ 253 | | (6) +--+---+ (6) | | 254 +----------+ |(7) +-------------+ 255 review +----+ review 256 | 257 poll for wg doc -----------------+ 258 | | (7a) 259 v v 260 +-------------+ (8) +-------+ 261 +----------> | wg doc |<------------>| ITU-T | 262 | +-------------+ +-------+ 263 | | +-> wg-00, wg-01, etc | 264 | | | | (9) | (10) 265 | | +----------+<----------------+ 266 | (11) | review 267 | v 268 | +-----------------+ (12) +---------+ 269 (14b) | | wg last call |<----------->| ITU-T | 270 | +-----------------+ +---------+ 271 | | ^ | 272 | (13)| |(14a) | (15) 273 | v | | 274 | +---------+ | 275 +-------| ITU-T | | 276 +---------+ | 277 | 278 v 279 +-----------------+ 280 | req for publ | 281 +-----------------+ 283 2.2. The IETF MPLS-TP process 285 This section gives guidelines for how the flow chart above could be 286 traversed. 288 2.2.1. Developing a MPLS-TP document 290 Individual MPLS-TP documents may take different paths through the 291 this process, the numbers in the list below are mapped to the numbers 292 in the flow chart above. 294 Although the different paths through the flow chart are given as 295 'options' it is always possible for the MEAD team to step in and take 296 over the shepherding of a particular MPLS-TP Internet Draft . This 297 is done in cooperation between the MEAD team chair, the relevant 298 working group chairs and the document editors/authors. 300 1. They may be intended for and managed by a working group. 302 This means that the author, or authors, of such a document have 303 chosen to send the document to a working group instead of 304 running through the MEAD team. Normal IETF process will kick in 305 in such cases and working group chairs will agree to which 306 working group(s) such a document will be taken. 308 2. They may be coordinated by the MEAD team. 310 This means that the author, or authors, of such a document have 311 chosen to send the document to the MEAD team to be coordinated 312 with the rest of the MPLS-TP documents that is in the purview of 313 the MEAD team. 315 3. They may be originated by the MEAD team based on the JWT 316 decision. 318 In documentation of the work of the JWT, there is a proposed 319 document structure. The MEAD team used this structure to decide 320 on a set of documents that will, when completed, constitute the 321 MPLS-TP standard. This set of documents may change slightly, if 322 - e.g. - it becomes more appropriate to split a single document 323 into two or more, or if some new aspect of MPLS-TP needs to be 324 specified. 326 4. Everytime a document is accepted by the MEAD team into the set 327 of documents coordinated by the MEAD team a liaison is sent to 328 the ITU-T with a pointer to that document. At the same time a 329 note is sent to the MPLS-TP ad hoc team mailing list informing 330 the list that the document has become a MEAD team document. 332 The ITU-T may chose to respond to the liaison but is not 333 required to do so, see Section 3 and Section 4. 335 5. At any time, it is possible for the ITU-T SG and Question 336 participants to send review comments on MEAD team documents. It 337 is also possible for the MEAD team to ask for such reviews and 338 comments. 340 Any time such input or requests are sent between the two 341 organizations it SHALL be accompanied by a note from the MPLS-TP 342 ad hoc team chair(s) to the MEAD team mailing list, or from the 343 MEAD team chair to the MPLS-TP ad hoc team mailing list. This 344 is done to enhance the efficiency of the information exchange. 346 6. A working group or the MEAD team may issue requests for general 347 comments on MPLS-TP documents at any time, if it is deemed 348 appropriate to extend these requests to the MPLS-TP ad hoc team 349 this is done via a note according to entry (5) in this list. 351 7. If a MPLS-TP document seems mature enough to become a working 352 group document, a poll is done on the mpls-tp mailing list and 353 the appropriate working group mailing list (7), this request 354 will also be sent to the ITU-T as a liaison (7a) and a note will 355 also be sent to the MPLS-TP ad hoc team. 357 Which working group a document goes into is decided jointly 358 between the MEAD team, working group chairs of the potential 359 working groups and the document editors/authors. 361 If the document is accepted as a working group document the 362 working group takes over the revision control of the document. 364 The ITU-T is expected to respond to the liaison within in the 365 time indicated in the liaison, see Section 3 and Section 4. 367 8. Every time a MPLS-TP document is accepted as a working group 368 document by any IETF working group, a liaison is sent to the 369 ITU-T with a pointer to the document. At the same time, a note 370 is sent to the MPLS-TP ad hoc team mailing list informing the 371 list that the document has become a working group document. 373 9. Working group documents may be reviewed in several steps, every 374 time such a review is initiated the MPLS-TP ad hoc team is 375 notified (10). 377 Note that most comments leading to updates of working group 378 documents are a result of spontaneous individual reviews and 379 comments from the individual participants in the MPLS-TP effort. 381 10. Every time a review is initiated by a working group the 382 appropriate ITU-T SGs and Questions will be notified by E-Mail 383 to the MPLS-TP ad hoc team. 385 Optionally the request for review may be accompanied by a 386 liaison to formalize the request. 388 The MPLS-TP ad hoc team is responsible for ensuring that any 389 e-mail requests are copied/forwarded to the relevant SGs and 390 Questions. 392 11. When a document is deemed mature enough, a working group last 393 call is initiated. At this time the action describe under item 394 12 in this list MUST be executed. 396 12. Procedures to be followed when a working group last call is 397 initiated. 399 * A liaison containing a request for participation in the 400 working group last call will be sent to the appropriate ITU-T 401 SGs and Questions. 403 * A notification that the working group last call is taking 404 place will be provided to the MPLS-TP ad hoc team via E-Mail 405 sent to the MPLS-TP mailing list. 407 * ITU-T is REQUIRED to respond to the liaison within the time 408 indicated. The MPLS-TP ad hoc team is expected to verify 409 that all the SGs and Questions within the ITU-T that need to 410 respond to the working group last call are aware that it has 411 been issued. 413 13. When all last call comments are addressed and/or responded to, 414 the document will be sent to the ITU-T, asking if the document 415 is ready to be sent to the IESG with a request for publication. 416 The response sought from ITU-T is either an acknowledgment that 417 the document is ready to publish or a response that there is 418 further work that needs to be done. 420 Note: WG last call may be re-iterated, for the entire document 421 or limited to only verify the updates made because of an earlier 422 working group last call. 424 14. The ITU-T has one week to respond (yes or no) to the question 425 posed in (13). 427 The answer can be either "yes - go ahead" (14a), in which case 428 the Working Group will request publication; or ... 430 ... it can be "no - more work is needed" (14b), in which case it 431 will go back into the normal working group process to identify 432 what is needed. 434 15. When the ITU-T gives the final acknowledgement (14a), a request 435 for publication will be sent to the IESG (15). 437 The document that is sent to the ITU-T in step (13) and which 438 generates a positivie response from ITU-T (14a) is sent 439 unchanged, save for editorial changes, to the IESG with a 440 request for publication (15) as a RFC. 442 Once this request for publication is sent, the last point in 443 this process where it is acceptable to allow ITU-T influence in 444 the development of a document is passed. After this point, the 445 document will be handled as any other IETF document. 447 2.2.1.1. Naming conventions for MPLS-TP Internet Drafts 449 To make it easier to search in the IETF Internet Draft repositories 450 the the following guidelines should be followed for the MPLS-TP 451 Internet Draft filenames. 453 o All MPLS-TP Internet Draft should include the sequence "mpls-tp" 454 in the filename. 456 o Individual MPLS-TP Internet Draft should be named according to 457 this format: 459 draft-name-mpls-tp-topic-??.txt 461 "name" is the last name of the main editor, or an acronym 462 indicating the last names of the set of editors. 464 "topic" indicates the content of the draft, e.g. "oam-framework". 466 "??" indictes a two digit version number, starting with "00". 468 o MPLS working group documents should be named according to this 469 format: 471 draft-ietf-mpls-tp-topic-??.txt 473 o MPLS-TP documents from other working groups shouldbe named 474 according to this format: 476 draft-ietf-wg-name-mpls-tp-topic-??.txt 478 "wg-name" is the acronym for any working group chartered to do 479 MPLS-TP work, e.g. pwe3 or ccamp. 481 3. Expectations on ITU-T participation in the process 483 The IETF and ITU-T processes for the development of the MPLS-TP 484 standards interconnect at the following point in the flow chart 485 above: (4), (5), (7a), (8), (10) and (12). This section briefly 486 describes what is expected to happen on the ITU-T side at the 487 interaction points. 489 3.1. Becoming a MEAD team document 491 (4) is a point at which the MEAD team communicates to the ITU-T that 492 a document is considered to be accepted for coordination by the MEAD 493 team. 495 The ITU-T is expected to respond to the communication with a simple 496 ACK or NAK, however a non-response is counted as an ACK. 498 An ACK means that ITU-T accepts that the document has become a MEAD 499 team document, a NAK means that ITU-T has issues that needs to be 500 resolved before the document is allowed to progress. 502 3.2. Comments on MEAD team documents by participants in the ITU-T 504 (5) and (10) offer possibilities for ITU-T, or people active in the 505 ITU-T, to send un-triggered comments on MEAD team or working group 506 documents. Such comments shall be sent to the mpls-tp list and for 507 working group documents also to the appropriate working group mailing 508 list. Comments received in this way will be treated in the same way 509 any as other individual comments received on the IETF documents. 511 3.3. Poll for working group documents 513 (7a) is the point at which an IETF working group informs the ITU-T 514 that a poll to progress a document to an IETF working group document 515 has been started. 517 It is not necessary, or required, for the ITU-T to respond to this 518 message. If the ITU-T has serious concerns these should be provided 519 via a liaison statement. If the ITU-T has no serious concerns it is 520 allowed and encouraged that individual participants provide comments. 521 Such responses shall be sent to the appropriate working group and 522 mpls-tp mailing lists and represent the view of the person sending 523 the mail. 525 An Internet Draft is ready to become a working group draft if it 526 meets at least the three criteria below. 528 o it is within the charter of the working group 530 o it addresses a problem that needs to be solved 532 o it is a good enough start toward solving this problem 534 Responses to polls checking if a document is ready to become a 535 working group document should be limited to considering if the 536 document meets those three criteria. 538 3.4. Responding to an IETF Working Group Last Call 540 (12) is the point in the process where ITU-T is made aware of that an 541 IETF working group last call has been started. The working group 542 last call is issued when a working group document is getting close to 543 being ready for publication. The intention is to make sure that 544 there are no important pieces missing and that technical details are 545 correct. 547 According to the JWT decision ITU-T is required to respond to a 548 working group last call within the time set in announcing the working 549 group last call. 551 The chair of an IETF working group that starts a working group last 552 call will send a liaison to the ITU-T announcing the working group 553 last call. A message will also be sent to the MPLS-TP ad hoc team. 554 The IETF will make a best effort attempt to target the SGs and 555 Questions that should be involved in responding to the working group 556 last call. However, the ITU-T has to make sure that the appropriate 557 entities within the ITU-T participate in responding to the working 558 group last call. The ITU-T MPLS-TP ad hoc team coordinates the 559 development of the ITU-T response to the working group last call. 561 4. Specific guidelines that apply to work on MPLS-TP in the ITU-T 563 These guidelines apply to progressing work on MPLS-TP in the ITU-T. 565 Any member of the ITU-T may send a MPLS-TP contribution to a ITU-T 566 Study Group or Question. 568 Before the ITU-T initiates any new work (i.e. items not previously 569 identified by the JWT) based on such contributions the ITU-T shall 570 send a liaison to the IETF. The message will go to the MEAD team, 571 and the team is responsible for creating a consolidated IETF 572 response. 574 The IETF is expected to respond to the information that a new 575 MPLS-TP work item has been proposed with an ACK or NAK. 577 If the response is a NAK that work item is held until the issues 578 is resolved. 580 5. IANA considerations 582 There are no requests for IANA allocation of code points in this 583 document. 585 6. Security considerations 587 This document defines a process adaptation for the cooperation 588 between IETF and ITU-T and thus does not introduce any new security 589 considerations. 591 7. Acknowledgments 593 Thanks to Eric Gray who helped with grammar and useful comments. 594 Thanks to Tom Petch who spent time trying to sort out what I wanted 595 to say and has sent comments that helped clarify the document. 597 8. References 599 8.1. Normative References 601 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 602 3", BCP 9, RFC 2026, October 1996. 604 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 605 Requirement Levels", BCP 14, RFC 2119, March 1997. 607 [RFC5317] Bryant, S. and L. Andersson, "Joint Working Team (JWT) 608 Report on MPLS Architectural Considerations for a 609 Transport Profile", RFC 5317, February 2009. 611 8.2. Informative references 613 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 614 Label Switched (MPLS) Data Plane Failures", RFC 4379, 615 February 2006. 617 Authors' Addresses 619 Loa Andersson 620 Ericsson Inc 622 Email: loa.andersson@ericsson.com 624 David Ward 625 Cisco Systems 627 Email: dward@cisco.com 629 Malcolm Betts 630 Huaweil 632 Email: malcolm.betts@huawei.com