idnits 2.17.1 draft-verdt-netmod-yang-semver-01.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 11, 2019) is 1657 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: 'RFC7895' is defined on line 609, but no explicit reference was found in the text == Unused Reference: 'RFC8525' is defined on line 617, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-netmod-yang-instance-file-format' is defined on line 629, but no explicit reference was found in the text == Outdated reference: A later version (-01) exists of draft-verdt-netmod-yang-module-versioning-00 ** Obsolete normative reference: RFC 7895 (Obsoleted by RFC 8525) == Outdated reference: A later version (-21) exists of draft-ietf-netmod-yang-instance-file-format-04 == Outdated reference: A later version (-03) exists of draft-rwilton-netmod-yang-packages-01 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Claise 3 Internet-Draft J. Clarke, Ed. 4 Intended status: Standards Track R. Rahman 5 Expires: April 13, 2020 R. Wilton, Ed. 6 Cisco Systems, Inc. 7 B. Lengyel 8 Ericsson 9 J. Sterne 10 Nokia 11 K. D'Souza 12 AT&T 13 October 11, 2019 15 YANG Semantic Versioning 16 draft-verdt-netmod-yang-semver-01 18 Abstract 20 This document specifies a scheme for applying a modified set of 21 semantic versioning rules to revisions of YANG modules. 22 Additionally, this document defines a revision label for this 23 modified semver scheme based on the specification in draft-verdt- 24 netmod-yang-module-versioning. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on April 13, 2020. 43 Copyright Notice 45 Copyright (c) 2019 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Terminology and Conventions . . . . . . . . . . . . . . . . . 3 62 3. YANG Semantic Versioning . . . . . . . . . . . . . . . . . . 3 63 3.1. YANG Semantic Versioning Pattern . . . . . . . . . . . . 3 64 3.2. Semantic Versioning Scheme for YANG Artifacts . . . . . . 4 65 3.2.1. Examples for YANG semantic version numbers . . . . . 6 66 3.3. YANG Semantic Version Update Rules . . . . . . . . . . . 7 67 3.4. Examples of the YANG Semver Label . . . . . . . . . . . . 8 68 3.4.1. Example Module Using YANG Semver . . . . . . . . . . 8 69 3.4.2. Example of Package Using YANG Semver . . . . . . . . 10 70 4. Import Module by Semantic Version . . . . . . . . . . . . . . 10 71 5. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 11 72 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 74 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 76 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 77 9.2. Informative References . . . . . . . . . . . . . . . . . 14 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 80 1. Introduction 82 [I-D.verdt-netmod-yang-module-versioning] puts forth a number of 83 concepts relating to modified rules for updating modules, a means to 84 signal when a new revision of a module has non-backwards-compatible 85 (NBC) changes compared to its previous revision, and a versioning 86 scheme that uses the revision history as a lineage for determining 87 from where a specific revision of a YANG module is derived. 88 Additionally, section 3.3 of 89 [I-D.verdt-netmod-yang-module-versioning] defines a revision label 90 which can be used as an overlay or alias to provide additional 91 context or an additional way to refer to a specific revision. 93 This document defines a labeling scheme that uses modified [semver] 94 rules for YANG artifacts (i.e., YANG modules and YANG packages 95 [I-D.rwilton-netmod-yang-packages]) as well as the revision label 96 definition for using this scheme. The goal of this is to add a human 97 readble version label that provides compatibility information for the 98 YANG artifact without one needing to compare or parse its body. The 99 label and rules defined herein represent the RECOMMENDED revision 100 label scheme for IETF YANG artifacts. 102 2. Terminology and Conventions 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 106 "OPTIONAL" in this document are to be interpreted as described in BCP 107 14 [RFC2119] [RFC8174] when, and only when, they appear in all 108 capitals, as shown here. 110 Additionally, this document uses the following terminology: 112 o YANG artifact: YANG modules, YANG packages 113 [I-D.rwilton-netmod-yang-packages], and YANG schema elements are 114 examples of YANG artifacts for the purposes of this document. 116 3. YANG Semantic Versioning 118 This section defines YANG Semantic Versioning, explains how it is 119 used with YANG artifacts, and the rules associated with changing a 120 artifact's semantic version number when its contents are updated. 122 3.1. YANG Semantic Versioning Pattern 124 YANG artifacts that employ semantic versioning MUST use a version 125 string (e.g., in revision-label or as a package version) that 126 corresponds to the following pattern: X.Y.Zv. Where: 128 o X, Y and Z are mandatory non-negative integers that are each less 129 than 32768 and MUST NOT contain leading zeroes 131 o The '.' is a literal period (ASCII character 0x2e) 133 o v is an optional single character modifier that MUST be either 'm' 134 or 'M' if it is specified 136 Additionally, [semver] defines two specific types of metadata that 137 may be appended to a semantic version string. Pre-release metadata 138 MAY be appended to a semver string after a trailing '-' character. 139 Build metadata MAY be appended after a trailing '+' character. If 140 both pre-release and build metadata are present, then build metadata 141 MUST follow pre-release metadata. These optional elements MUST be 142 ignored by YANG semver parsers, but are allowed in order to support 143 all of the [semver] rules. Thus, a version lineage that follows 144 strict [semver] rules is allowed for a YANG artifact. 146 Other version schemes MUST NOT use version strings that match this 147 same pattern. For example, they may choose to use leading characters 148 to distinguish themselves from YANG semver. 150 A YANG module is defined in this document which contains single 151 typedef that formally specifies this version pattern. 153 3.2. Semantic Versioning Scheme for YANG Artifacts 155 This document defines the YANG semantic versioning scheme that is 156 used for YANG artifacts that employ the semver label. The versioning 157 scheme has the following properties: 159 The YANG semantic versioning scheme is extended from version 2.0.0 160 of the semantic versioning scheme defined at semver.org [semver] 161 to cover the additional requirements for the management of YANG 162 artifact lifecyles that cannot be addressed using the semver.org 163 2.0.0 versioning scheme alone. 165 Unlike the [semver] versioning scheme, the YANG semantic 166 versioning scheme supports limited updates to older versions of 167 YANG artifacts, to allow for bug fixes and enhancements to 168 artifact versions that are not the latest. However, it does not 169 provide for the unlimited branching and updating of older 170 revisions which are documented by the general rules in 171 [I-D.verdt-netmod-yang-module-versioning]. 173 YANG artifacts that follow the [semver] versioning scheme are 174 fully compatible with implementations that understand the YANG 175 semantic versioning scheme defined in this document. 177 If updates are always restricted to the latest revision of the 178 artifact only, then the version numbers used by the YANG semantic 179 versioning scheme are exactly the same as those defined by the 180 [semver] versioning scheme. 182 Every YANG module versioned using the YANG semantic versioning scheme 183 specifies the module's semantic version number as the argument to the 184 'rev:revision-label' statement. 186 Because the rules put forth in 187 [I-D.verdt-netmod-yang-module-versioning] are designed to work well 188 with existing versions of YANG and allow for artifact authors to 189 migrate to this scheme, it is not expected that all revisions of a 190 given YANG artifact will have a semantic version label. For example, 191 the first revision of a module may have been produced before this 192 scheme was available. 194 YANG packages that make use of this semantic versioning scheme will 195 have their semantic version as the value of the "revision_label" 196 property. 198 As stated above, the YANG semver version number is expressed as a 199 string of the form: 'X.Y.Zv'; where X, Y, and Z each represent non- 200 negative integers smaller than 32768 without leading zeroes, and v 201 represents an optional single character suffix: 'm' or 'M'. 203 o 'X' is the MAJOR version. Changes in the major version number 204 indicate changes that are non-backwards-compatible to versions 205 with a lower major version number. 207 o 'Y' is the MINOR version. Changes in the minor version number 208 indicate changes that are backwards-compatible to versions with 209 the same major version number, but a lower minor version number 210 and no patch 'm' or 'M' modifier. 212 o 'Zv' is the PATCH version and modifier. Changes in the patch 213 version number can indicate editorial, backwards-compatible, or 214 non-backwards-compatible changes relative to versions with the 215 same major and minor version numbers, but lower patch version 216 number, depending on what form modifier 'v' takes: 218 * If the modifier letter is absent, the change represents an 219 editorial change. An editorial change is defined to be a 220 change in the YANG artifact's content that does not affect the 221 semantic meaning or functionality provided by the artifact in 222 any way. An example is correcting a spelling mistake in the 223 description of a leaf within a YANG module. Note: 224 restructuring how a module uses, or does not use, submodules is 225 treated as an editorial level change on the condition that 226 there is no change in the module's semantic behavior due to the 227 restructuring. 229 * If, however, the modifier letter is present, the meaning is 230 described below: 232 * 'm' - the change represents a backwards-compatible change 234 * 'M' - the change represents a non-backwards-compatible change 236 The YANG articact name and YANG semantic version number uniquely 237 identifies a revision of said artifact. There MUST NOT be multiple 238 instances of a YANG artifact definition with the same name and YANG 239 semantic version number but different content (and in the case of 240 modules, different revision dates). 242 There MUST NOT be multiple versions of a YANG artifact that have the 243 same MAJOR, MINOR and PATCH version numbers, but different patch 244 modifier letters. E.g., artifact version "1.2.3M" MUST NOT be 245 defined if artifact version "1.2.3" has already been defined. 247 3.2.1. Examples for YANG semantic version numbers 249 The following diagram and explanation illustrates how YANG semantic 250 version numbers work. 252 Example YANG semantic version numbers for an example artifact: 254 0.1.0 255 | 256 0.2.0 257 | 258 1.0.0 259 | \ 260 | 1.1.0 -> 1.1.1m -> 1.1.2M 261 | | 262 | 1.2.0 -> 1.2.1M -> 1.2.2M 263 | | 264 | 1.3.0 -> 1.3.1 265 | 266 2.0.0 267 | 268 3.0.0 269 \ 270 3.1.0 272 Assume the tree diagram above illustrates how an example YANG 273 module's version history might evolve. For example, the tree might 274 represent the following changes, listed in chronological order from 275 oldest revision to newest: 277 0.1.0 - first beta module version 279 0.2.0 - second beta module version (with NBC changes) 281 1.0.0 - first release (may have NBC changes from 0.2.0) 283 1.1.0 - added new functionality, leaf "foo" (BC) 285 1.2.0 - added new functionality, leaf "baz" (BC) 286 1.3.0 - improve existing functionality, added leaf "foo-64" (BC) 288 1.3.1 - improve description wording for "foo-64" (Editorial) 290 1.1.1m - backport "foo-64" leaf to 1.1.x to avoid implementing 291 "baz" from 1.2.0 (BC) 293 2.0.0 - change existing model for performance reasons, e.g. re-key 294 list (NBC) 296 1.1.2M - NBC point bug fix, not required in 2.0.0 due to model 297 changes (NBC) 299 3.0.0 - NBC bugfix, rename "baz" to "bar"; also add new BC leaf 300 "wibble"; (NBC) 302 1.2.1M - backport NBC fix, changing "baz" to "bar" 304 1.2.2M - backport "wibble". This is a BC change but "M" modifier 305 is sticky. 307 3.1.0 - introduce new leaf "wobble" (BC) 309 The partial ordering relationships based on the semantic versioning 310 numbers can be defined as follows: 312 1.0.0 < 1.1.0 < 1.2.0 < 1.3.0 < 2.0.0 < 3.0.0 < 3.1.0 314 1.0.0 < 1.1.0 < 1.1.1m < 1.1.2M 316 1.0.0 < 1.1.0 < 1.2.0 < 1.2.1M < 1.2.2M 318 There is no ordering relationship between 1.1.1M and either 1.2.0 or 319 1.2.1M, except that they share the common ancestor of 1.1.0. 321 Looking at the version number alone, the module definition in 2.0.0 322 does not necessarily contain the contents of 1.3.0. However, the 323 module revision history in 2.0.0 may well indicate that it was edited 324 from module version 1.3.0. 326 3.3. YANG Semantic Version Update Rules 328 When a new revision of an artifact is produced, then the following 329 rules define how the YANG semantic version number for the new 330 artifact revision is calculated, based on the changes between the two 331 artifact revisions, and the YANG semantic version number of the base 332 artifact revision from which the changes are derived: 334 1. If an artifact is being updated in a non-backwards-compatible 335 way, then the artifact version "X.Y.Z[m|M]" MUST be updated to 336 "X+1.0.0" unless that artifact version has already been defined 337 with different content, in which case the artifact version 338 "X.Y.Z+1M" MUST be used instead. 340 2. If an artifact is being updated in a backwards-compatible way, 341 then the next version number depends on the format of the current 342 version number: 344 i "X.Y.Z" - the artifact version MUST be updated to 345 "X.Y+1.0", unless that artifact version has already been 346 defined with different content, when the artifact version 347 MUST be updated to "X.Y.Z+1m" instead. 349 ii "X.Y.Zm" - the artifact version MUST be updated to 350 "X.Y.Z+1m". 352 iii "X.Y.ZM" - the artifact version MUST be updated to 353 "X.Y.Z+1M". 355 3. If an artifact is being updated in an editorial way, then the 356 next version number depends on the format of the current version 357 number: 359 i "X.Y.Z" - the artifact version MUST be updated to "X.Y.Z+1" 361 ii "X.Y.Zm" - the artifact version MUST be updated to 362 "X.Y.Z+1m". 364 iii "X.Y.ZM" - the artifact version MUST be updated to 365 "X.Y.Z+1M". 367 4. YANG artifact semantic version numbers beginning with 0, i.e 368 "0.X.Y" are regarded as beta definitions and need not follow the 369 rules above. Either the MINOR or PATCH version numbers may be 370 updated, regardless of whether the changes are non-backwards- 371 compatible, backwards-compatible, or editorial. 373 3.4. Examples of the YANG Semver Label 375 3.4.1. Example Module Using YANG Semver 377 Below is a sample YANG module that uses the YANG semver revision 378 label based on the rules defined in this document. 380 module yang-module-name { 381 namespace "name-space"; 382 prefix "prefix-name"; 384 import ietf-yang-revisions { prefix "rev"; } 386 description 387 "to be completed"; 389 revision 2018-02-28 { 390 description "Added leaf 'wobble'"; 391 rev:revision-label "3.1.0"; 392 } 394 revision 2017-12-31 { 395 description "Rename 'baz' to 'bar', added leaf 'wibble'"; 396 rev:revision-label "3.0.0"; 397 rev:nbc-changes; 398 } 400 revision 2017-10-30 { 401 description "Change the module structure"; 402 rev:revision-label "2.0.0"; 403 rev:nbc-changes; 404 } 406 revision 2017-08-30 { 407 description "Clarified description of 'foo-64' leaf"; 408 rev:revision-label "1.3.1"; 409 } 411 revision 2017-07-30 { 412 description "Added leaf foo-64"; 413 rev:revision-label "1.3.0"; 414 } 416 revision 2017-04-20 { 417 description "Add new functionality, leaf 'baz'"; 418 rev:revision-label "1.2.0"; 419 } 421 revision 2017-04-03 { 422 description "Add new functionality, leaf 'foo'"; 423 rev:revision-label "1.1.0"; 424 } 426 revision 2017-04-03 { 427 description "First release version."; 428 rev:revision-label "1.0.0"; 430 } 432 // Note: semver rules do not apply to 0.X.Y labels. 434 revision 2017-01-30 { 435 description "NBC changes to initial revision"; 436 semver:module-version "0.2.0"; 437 } 439 revision 2017-01-26 { 440 description "Initial module version"; 441 semver:module-version "0.1.0"; 442 } 444 //YANG module definition starts here 446 3.4.2. Example of Package Using YANG Semver 448 Below is an example YANG package that uses the semver revision label 449 based on the rules defined in this document. 451 { 452 "ietf-yang-instance-data:instance-data-set": { 453 "name": "example-yang-pkg", 454 "target-ptr": "TBD", 455 "timestamp": "2018-09-06T17:00:00Z", 456 "description": "Example IETF package definition", 457 "content-data": { 458 "ietf-yang-package:yang-package": { 459 "name": "example-yang-pkg", 460 "version": "1.3.1", 461 ... 462 } 464 4. Import Module by Semantic Version 466 [I-D.verdt-netmod-yang-module-versioning] allows for imports to be 467 done based on a module or a derived revision of a module. The 468 rev:revision-or-derived statement can specify either a revision date 469 or a revision label. When importing by semver, the YANG semver 470 revision label value MAY be used as an argument to rev:revision-or- 471 derived. In so, any module which has that semver label as its latest 472 revision label or has that label in its revision history can be used 473 to satisfy the import requirement. For example: 475 import example-module { 476 rev:revision-or-derived "3.0.0"; 477 } 479 Note: the import lookup does not stop when a non-backward-compatible 480 change is encountered. That is, if module B imports a module A at or 481 derived from version 2.0.0, resolving that import will pass through a 482 revision of module A with version 2.1.0M in order to determine if the 483 present instance of module A derives from 2.0.0. 485 5. YANG Module 487 This YANG module contains the typedef for the YANG semantic version. 489 file "ietf-yang-semver@2019-09-06.yang" 490 module ietf-yang-semver { 491 yang-version 1.1; 492 namespace "urn:ietf:params:xml:ns:yang:ietf-yang-semver"; 493 prefix yangver; 495 organization 496 "IETF NETMOD (Network Modeling) Working Group"; 497 contact 498 "WG Web: 499 WG List: 501 Author: Joe Clarke 502 "; 503 description 504 "This module provides type and grouping definitions for YANG 505 packages. 507 Copyright (c) 2019 IETF Trust and the persons identified as 508 authors of the code. All rights reserved. 510 Redistribution and use in source and binary forms, with or 511 without modification, is permitted pursuant to, and subject 512 to the license terms contained in, the Simplified BSD License 513 set forth in Section 4.c of the IETF Trust's Legal Provisions 514 Relating to IETF Documents 515 (http://trustee.ietf.org/license-info). 517 This version of this YANG module is part of RFC XXXX; see 518 the RFC itself for full legal notices."; 520 // RFC Ed.: update the date below with the date of RFC publication 521 // and remove this note. 522 // RFC Ed.: replace XXXX with actual RFC number and remove this 523 // note. 525 revision 2019-09-06 { 526 description 527 "Initial revision"; 528 reference 529 "RFC XXXX: YANG Semantic Versioning."; 530 } 532 /* 533 * Typedefs 534 */ 536 typedef version { 537 type string { 538 pattern '\d+[.]\d+[.]\d+[mM]?(-[\w\d.]+)?([+][\w\d\.]+)?'; 539 } 540 description 541 "Represents a YANG semantic version number. Note: 542 additional rules apply to the dot-separated numeric identifiers 543 which are spelled out in the reference for this typedef."; 544 reference 545 "RFC XXXX: YANG Semantic Versioning."; 546 } 547 } 548 550 6. Contributors 552 This document grew out of the YANG module versioning design team that 553 started after IETF 101. The design team consists of the following 554 members whom have worked on the YANG versioning project: 556 o Balazs Lengyel 558 o Benoit Claise 560 o Ebben Aries 562 o Jason Sterne 564 o Joe Clarke 566 o Juergen Schoenwaelder 568 o Mahesh Jethanandani 570 o Michael (Wangzitao) 572 o Qin Wu 573 o Reshad Rahman 575 o Rob Wilton 577 The initial revision of this document was refactored and built upon 578 [I-D.clacla-netmod-yang-model-update]. 580 Discussons on the use of Semver for YANG versioning has been held 581 with authors of the OpenConfig YANG models based on their own 582 [openconfigsemver]. We would like thank both Anees Shaikh and Rob 583 Shakir for their input into this problem space. 585 7. Security Considerations 587 The document does not define any new protocol or data model. There 588 are no security impacts. 590 8. IANA Considerations 592 None. 594 9. References 596 9.1. Normative References 598 [I-D.verdt-netmod-yang-module-versioning] 599 Claise, B., Clarke, J., Rahman, R., Wilton, R., Lengyel, 600 B., Sterne, J., and K. D'Souza, "Updated YANG Module 601 Revision Handling", draft-verdt-netmod-yang-module- 602 versioning-00 (work in progress), July 2019. 604 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 605 Requirement Levels", BCP 14, RFC 2119, 606 DOI 10.17487/RFC2119, March 1997, 607 . 609 [RFC7895] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module 610 Library", RFC 7895, DOI 10.17487/RFC7895, June 2016, 611 . 613 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 614 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 615 May 2017, . 617 [RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K., 618 and R. Wilton, "YANG Library", RFC 8525, 619 DOI 10.17487/RFC8525, March 2019, 620 . 622 9.2. Informative References 624 [I-D.clacla-netmod-yang-model-update] 625 Claise, B., Clarke, J., Lengyel, B., and K. D'Souza, "New 626 YANG Module Update Procedure", draft-clacla-netmod-yang- 627 model-update-06 (work in progress), July 2018. 629 [I-D.ietf-netmod-yang-instance-file-format] 630 Lengyel, B. and B. Claise, "YANG Instance Data File 631 Format", draft-ietf-netmod-yang-instance-file-format-04 632 (work in progress), August 2019. 634 [I-D.rwilton-netmod-yang-packages] 635 Wilton, R., "YANG Packages", draft-rwilton-netmod-yang- 636 packages-01 (work in progress), March 2019. 638 [openconfigsemver] 639 "Semantic Versioning for Openconfig Models", 640 . 642 [semver] "Semantic Versioning 2.0.0", . 644 Authors' Addresses 646 Benoit Claise 647 Cisco Systems, Inc. 648 De Kleetlaan 6a b1 649 1831 Diegem 650 Belgium 652 Phone: +32 2 704 5622 653 Email: bclaise@cisco.com 655 Joe Clarke (editor) 656 Cisco Systems, Inc. 657 7200-12 Kit Creek Rd 658 Research Triangle Park, North Carolina 659 United States of America 661 Phone: +1-919-392-2867 662 Email: jclarke@cisco.com 664 Reshad Rahman 665 Cisco Systems, Inc. 667 Email: rrahman@cisco.com 668 Robert Wilton (editor) 669 Cisco Systems, Inc. 671 Email: rwilton@cisco.com 673 Balazs Lengyel 674 Ericsson 675 Magyar Tudosok Korutja 676 1117 Budapest 677 Hungary 679 Phone: +36-70-330-7909 680 Email: balazs.lengyel@ericsson.com 682 Jason Sterne 683 Nokia 685 Email: jason.sterne@nokia.com 687 Kevin D'Souza 688 AT&T 689 200 S. Laurel Ave 690 Middletown, NJ 691 United States of America 693 Email: kd6913@att.com