idnits 2.17.1 draft-wu-netmod-yang-xml-doc-conventions-04.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 : ---------------------------------------------------------------------------- ** There are 7 instances of too long lines in the document, the longest one being 13 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 515 has weird spacing: '...te that space...' -- The document date (June 11, 2018) is 2147 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC8340' is defined on line 444, but no explicit reference was found in the text == Unused Reference: 'XML' is defined on line 448, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'XML' Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Netmod Working Group Q. Wu 3 Internet-Draft Huawei 4 Intended status: Best Current Practice A. Farrel 5 Expires: December 13, 2018 Juniper Networks 6 B. Claise 7 Cisco Systems, Inc. 8 June 11, 2018 10 Documentation Conventions for lines wrapping and indentation in authored 11 work 12 draft-wu-netmod-yang-xml-doc-conventions-04 14 Abstract 16 Many documents that define YANG modules or YANG fragments also 17 include protocol message instance data examples. 19 IETF documentation has specific limits on line length (73 characters) 20 and some YANG fragment example or protocol message instance data 21 examples such as XML encoded YANG data node instance examples have to 22 include line wraps that would not normally be allowed according to 23 the XML representation rules of RFC7950 and RFC7952. 25 This document lays out documentation conventions that allow authored 26 work to be presented in IETF documentation when authored work such as 27 YANG fragment or protocol message instance data example would 28 otherwise exceed the maximum line length and provide consistent 29 representation of authored work within an Internet-Draft or RFC. 30 There are no implications in this document for YANG tools: this 31 document does not change the rules for presenting authored work in 32 data files or in the wire. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on December 13, 2018. 50 Copyright Notice 52 Copyright (c) 2018 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Conventions Used in this Document . . . . . . . . . . . . . . 3 69 2.1. Glossary of New Terms . . . . . . . . . . . . . . . . . . 4 70 3. Long line wrapping Example . . . . . . . . . . . . . . . . . 4 71 4. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 5. Line wrapping and indentation document convention . . . . . . 5 73 5.1. Long line wrapping . . . . . . . . . . . . . . . . . . . 6 74 5.2. Line unwrapping . . . . . . . . . . . . . . . . . . . . . 7 75 5.3. Auto indentation and dedentation . . . . . . . . . . . . 7 76 6. Limitation and complexity . . . . . . . . . . . . . . . . . . 8 77 6.1. Limitations . . . . . . . . . . . . . . . . . . . . . . . 8 78 6.2. Complexity . . . . . . . . . . . . . . . . . . . . . . . 9 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 80 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 81 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 82 10. Normative References . . . . . . . . . . . . . . . . . . . . 9 83 Appendix A. Representing XML and JSON Encodings of Metadata 84 Annotations . . . . . . . . . . . . . . . . . . . . 10 85 Appendix B. Auto-wrapping tool code . . . . . . . . . . . . . . 11 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 88 1. Introduction 90 When documenting authored work such as YANG fragments example of 91 example of YANG module represented in XML encoding it is possible 92 that the representation of these authored work will exceed the 93 available line length. Indentation may further aggravate this issue. 94 The line wrapping is needed for formatting purposes, however 95 different document author may take different ways to wrap line which 96 makes difficult to improve the readability and interoperability of 97 published YANG data models. 99 This document lays out documentation conventions that allow authored 100 work to be presented in IETF documentation when authored work such as 101 YANG fragment or protocol message instance data example would 102 otherwise exceed the maximum line length and provide consistent 103 representation of authored work within an Internet-Draft or RFC. 105 Document conventions defined in this document are not representative 106 of how the Authored work must be presented to a software component or 107 carried on the wire. There are no implications in this document for 108 YANG tools(e.g., libyang parser): this document does not change the 109 rules for presenting YANG models or for encoding YANG in data files 110 or in the wire. 112 2. Conventions Used in this Document 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 116 "OPTIONAL" in this document are to be interpreted as described in BCP 117 14 [RFC2119] [RFC8174] when, and only when, they appear in all 118 capitals, as shown here. 120 The following terms are defined in [RFC7950] and are not redefined 121 here: 123 o data node 125 o leaf 127 o leaf-list 129 o instance 131 The following term is defined in [RFC7951] and [RFC7952] and are not 132 redefined here: 134 o data node Instance 136 o data node identifier 138 The following terms are defined in [RFC8340]and 139 [I-D.ietf-netmod-rfc6087bis]. 141 2.1. Glossary of New Terms 143 Authored work: A set of text format work representing YANG 144 fragments, and protocol message instance data except YANG Tree 145 Diagrams. 147 Wrap: Convert authored work with long lines not fitting into an 148 Internet-Draft or RFC into authored work with split line fitting 149 into an Internet-Draft or RFC. 151 Unwrap: Re-Convert authored work with split line fitting into an 152 Internet-Draft or RFC back to valid authored work without split 153 line that can be consumed by a software component or carried on 154 the wire. 156 Indent: used to describe the distance, or number of blank spaces 157 used to separate a paragraph from the left or right margins. 159 Libyang parser: YANG tool and library for parsing and validating 160 YANG schemas and instance data. 162 3. Long line wrapping Example 164 An example of the documentation of a leaf node is shown in Figure 1. 165 The container node is called , any whitespace, 166 carriage returns, or line feeds between the subelements is insignificant, i.e., an implementation MAY insert 168 whitespace, carriage return, or line feed characters between 169 subelements. The leaf is called "long-leaf-node-label" and is 170 assigned the value "long-leaf-node-value". As can be seen in the 171 example, this fits on one line. However it would only take the 172 addition of a few more characters to the node label or value for the 173 example to overflow the 73 character limit if the line of leaf node 174 instance is indented (e.g., start below with a 175 whitespace offset of two characters. . 177 178 long-leaf-node-value 179 181 Figure 1: A Simple Leaf Node Example 183 For the sake of documentation purpose, the representation shown in 184 Figure 2 SHALL be considered as equivalent to that shown in Figure 1, 185 but when a document uses this convention it MUST also include the 186 text shown in Figure 3. Note that the first example representation 187 in figure 2 is more easily parsed by a human reader than the second 188 example in figure 2. 190 191 \ 192 long-leaf-node-value\ 193 194 195 Or 196 197 long-leaf-node-value 199 201 Figure 2: A Split Leaf Node Example 203 4. Objectives 205 In order to allow authored work to be presented in IETF documentation 206 when authored work such as YANG fragment or protocol message instance 207 data example would otherwise exceed the maximum line length and 208 provide consistent representation of the authored work within an 209 Internet-Draft or RFC, the following design criteria are used: 211 o Allow automatic wrapping line when any line presented in the 212 authored work of I-D or RFCs exceed the maximum line length. 214 o Allow automatic unwrapping line in the artwork when the artwork 215 needs to be presented to a software component or carried on the 216 wire. 218 5. Line wrapping and indentation document convention 220 When the representation of an authored work (e.g.,a leaf node 221 instance representation) in an example would result in a line being 222 longer than the maximum line length for an IETF document the long 223 line must be split and presented on more than one lines. The new 224 line may be indented, if necessary, so that it starts below the first 225 line with a whitespace offset of two characters, which improve 226 readability and interoperability of published YANG data models. 228 When these authored work with split lines needs to be fed into 229 software component or carried in the wire, these authored work with 230 split lines should be unwrapped and reversed into the valid authored 231 work with long line. If indentation is applied to authored work with 232 split lines, the indentation should be removed during unwrapped 233 process. 235 5.1. Long line wrapping 237 Long line wrapping most likely to happen when the authored work 238 example such as leaf node contains built-in type string or datetime 239 or container node and list node includes metadata attributes. 240 Indeed, if this problem arises for other YANG types it may be 241 indicative of poorly chosen YANG type values, and the YANG 242 definitions should be revised before applying document convention for 243 line wrapping defined in this document. 245 In the case of long line exceeding 73 characters, the following long 246 line wrapping conventions MUST be observed: 248 o Split long line in the authored work (e.g.,leaf node instance, 249 YANG data node instance containing metadata annotation attributes) 250 exceeding 73 characters limits with the backslash ("\") and use 251 backslash ("\")to indicate wrapping at the end of the line. The 252 broken line MUST be terminated with a backslash ("\") without the 253 addition of any additional space before the backslash and with no 254 further characters after the backslash. 256 o Any continuation lines or new line MUST align with the first line 257 and may chose be indented with two whitespace offset for 258 readability purposes. 260 o When a backslash appears in any line not used for split line, the 261 representation of this artwork MUST be arranged so that this 262 backslash is not the final character of a broken line. If this 263 backslash is the final character of a broken line, the line should 264 be split at the position one character before the final character 265 with the backslash ("\") . 267 Furthermore, whenever a document uses long line wrapping conventions 268 it MUST also include the following boilerplate text : 270 [!!! '\' line wrapping is for formatting only and adopt the conventions 271 shown in BCPXX [RFCYYYY]] 272 273 ....//Authored work 274 275 RFC Editor Note: Please replace XX and YYYY with the numbers assigned 276 for this document. 278 Figure 3 280 Figure 4 shows an example of Backslash appearing in the long line not 281 used for split line. 283 Punctuation is important. As 284 are line feeds.Some characters are special,e.g., the backslash\. 285 Don't forget. 287 Figure 4: An Example Leaf Node With a Complex String Value 289 Figure 5 shows a semantically equivalent representation of the 290 example. 292 Punctuation is important. As \ 293 are line feeds.Some characters are special,e.g., the backslash \.\ 294 Don't forget. 296 Figure 5 298 5.2. Line unwrapping 300 If line wrapping is done for formatting purposes, the line wrapping 301 in the authored work should be reversed back or unwrapped before the 302 authored work is fed into software component for validation or 303 carried in the wire. Therefore line unwrapping help remove backslash 304 and additional carriage return or line feed character and make 305 unwrapped authored work to be effectively compliant with the tool. 306 The line wrapping for formatting purpose is indicated by the above 307 boilerplate text in Figure 3. To unwrap line, the following 308 conventions must be observed: 310 o Consecutive split lines in the authored work with backslash at the 311 end of the line should be merged into one long line, the last 312 split line in Consecutive split lines should not be terminated 313 with backslash. 315 o If a backslash character ("\") doesn't appear at the end of the 316 line within authored work, it should not be stripped. 318 o If a backslash character ("\") appears at the end of the line 319 within authored work, it should be stripped. In the meanwhile, if 320 and only if it is immediately followed by a carriage return or 321 line feed character then all carriage return, line feed, and 322 whitespace characters should be stripped until the next character 323 is encountered. 325 5.3. Auto indentation and dedentation 327 Consistent indentation should be used for all authored work in the 328 I-D and RFCs, e.g., if a space or tab characters are used to index 329 the text in the long line during wraping process, the space and tab 330 characters used for indentation should be removed during unwrapping 331 process. If the new line or continuation line indented with a 332 whitespace offset of two characters during wrapping process, the 333 indentation with a whitespace offset of two characters should be 334 removed during unwrapping process. 336 6. Limitation and complexity 338 6.1. Limitations 340 All modules need to be extracted YANG modules from an Internet Draft 341 or RFC and then validated before submission in an Internet Draft. 342 However we don't have automation tool to extract authored work such 343 as YANG fragments or protocol message instance. To extract authored 344 work, the similar strings "" and "" MUST be 345 defined and populated to identify each authored work component, e.g., 346 the boilerplate text in Section 5 can be used to indicate the 347 begining of authored work. 349 Applying wrapping and unwrapping functionality to example YANG module 350 or YANG module extracted using existing tool also has limitation, 351 even introduce confusion, e.g., 353 1. The data definition description statement has long line exceeding 354 73 characters, it should be wrapped without using backslash as 355 termination point. 357 " 358 grouping link-ref { 359 description 360 "This grouping can be used to reference a link in a specific 361 network. Although it is not used in this module, it is 362 defined here for the convenience of augmenting modules."; 363 " 365 2. Another example is when a plus character ("+") is used to 366 concatenate two quoted string into one string, using backslash to 367 split the line Confuses with using a plus character ("+") to 368 split the line. 370 " 371 container dhcp-relay { 372 when "derived-from-or-self(../address-allocation-type, "+ 373 "'l3vpn-svc:provider-dhcp-relay')" { 374 description 375 "Only applies when provider is required to implement 376 DHCP relay function."; 377 } 378 " 380 6.2. Complexity 382 We can build tool to support auto wrap and auto indentation. However 383 if the tool is designed to understand various encodings, e.g., XML 384 encoding, JSON encoding or metadata annotation, it adds a lot of 385 complexity to build such tool, therefore the only choice to make tool 386 understand various encodings, is to build encoding specific tool 387 which doesn't scale well,e.g., if the tool understands metadata 388 annotation, we can decide where to insert backslash to split the 389 lines: either inserted between metadata Attributes or insert at any 390 place when the long line exceeding 73 characters limits. See more 391 complexity details in Appendix A. 393 7. Security Considerations 395 There is no direct security impact related to the documentation 396 convention for lines wrapping and indentation in authored work 397 described in this document. However, attempting to provide 398 representation of authored work using the documentation conventions 399 described in this document would have unpredictable results. The 400 risk here is that someone uses an example as a template for actual 401 authored work representation. The mandatory boilerplate text 402 provides a mitigation against this risk. 404 8. IANA Considerations 406 There are no IANA requests or assignments included in this document. 408 9. Acknowledgements 410 Thanks to Kent Watsen for discussions that kept us close to being on 411 the right track. Additional thanks to John Scudder for flagging some 412 nits, Martin Bjorklund, Charles Eckel, Robert Wilton and many others 413 for valuable comments and review, special thanks Xiongjie to help 414 support automation tool building. 416 10. Normative References 418 [I-D.ietf-netmod-rfc6087bis] 419 Bierman, A., "Guidelines for Authors and Reviewers of YANG 420 Data Model Documents", draft-ietf-netmod-rfc6087bis-20 421 (work in progress), March 2018. 423 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 424 Requirement Levels", BCP 14, RFC 2119, 425 DOI 10.17487/RFC2119, March 1997, 426 . 428 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 429 RFC 7950, DOI 10.17487/RFC7950, August 2016, 430 . 432 [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", 433 RFC 7951, DOI 10.17487/RFC7951, August 2016, 434 . 436 [RFC7952] Lhotka, L., "Defining and Using Metadata with YANG", 437 RFC 7952, DOI 10.17487/RFC7952, August 2016, 438 . 440 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 441 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 442 May 2017, . 444 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 445 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 446 . 448 [XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and 449 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth 450 Edition)", World Wide Web Consortium Recommendation REC- 451 xml-20081126, November 2008, 452 . 454 Appendix A. Representing XML and JSON Encodings of Metadata Annotations 456 [RFC7952] section 5.1 and section 5.2 provide an encoding rule for 457 metadata annotations in XML and JSON respectively. 459 When an example XML representation of a leaf node element that 460 includes metadata attributes results in a line being longer than the 461 maximum number of characters allowed in a line of an IETF document, 462 the value of the leaf node must be split across more than one line. 464 Where possible, all line breaks should be inserted between metadata 465 attributes. Continuation lines MUST align with the first line and 466 not be indented with any whitespace. The leading and trailing 467 whitespace of each line MUST be ignored. Figure 6 gives a XML 468 example. 470 When an example JSON representation of a leaf node element that 471 includes metadata attributes starting with the "@" character results 472 in a line being longer than the maximum number of characters allowed 473 in a line of an IETF document,the value of the leaf node must be 474 split across more than one line. Continuation lines MUST align with 475 the first line and indented with one whitespace character. The 476 leading and trailing whitespace of each line MUST be ignored. 477 Figure 7 gives a JSON example. 479 Whenever this documentation convention is used, the boilerplate text 480 shown in Figure 3 MUST be present in the document using the 481 convention. 483 485 ... 486 488 Figure 6: An XML Example Leaf Node With Metadata Split Across Lines 490 "cask": { 491 "@": { 492 "example-org-example-last-modified:last-modified":\ 493 "2015-09-16T10:27:35+02:00" 494 }, 495 ... 496 } 498 Figure 7: A JSON Example Leaf Node With Metadata Split Across Lines 500 Appendix B. Auto-wrapping tool code 502 We provide examples of python code for aspects of line wrapping and 503 unwrapping algorithms. There may be other implementation methods 504 that are faster in particular operating environments or have other 505 advantages. These implementation notes are for informational 506 purposes only and are meant to clarify the this specification for 507 line wrapping and unwrapping. 509 #!/usr/bin/env python2.7 510 # -*- coding: utf-8 -*- 511 """Qin Wu, 2018-06-02 512 Autowrapper.py uses Text Wrap Module as library and support auto wrap and auto indent 513 two functionalities. 514 lines with "\" in position 72 can be handled. 515 Open issue: note that space (" ") in position 73 hasn't be handled yet. 516 Text Wrap module provides two convenience functions, wrap() and fill(), as well as 517 TextWrapper, the class that does all the work, and a utility function dedent(). If 518 you're just wrapping or filling one or two text strings, the convenience functions 519 should be good enough; otherwise, you should use an instance of TextWrapper for 520 efficiency. 522 https://github.com/python/cpython/blob/2.7/Lib/textwrap.py 523 """ 524 import textwrap 525 import string, re 526 import argparse 527 import os.path 528 import sys, getopt 530 def indent(text, prefix, predicate=None): 531 """Adds 'prefix' to the beginning of selected lines in 'text'. 533 If 'predicate' is provided, 'prefix' will only be added to the lines 534 where 'predicate(line)' is True. If 'predicate' is not provided, 535 it will default to adding 'prefix' to all non-empty lines that do not 536 consist solely of whitespace characters. 537 """ 538 if predicate is None: 539 def predicate(line): 540 return line.strip() 542 def prefixed_lines(): 543 for line in text.splitlines(True): 544 yield (prefix + line if predicate(line) else line) 545 return ''.join(prefixed_lines()) 547 def auto_wrap(input_file, dst_file): 548 finput=open(input_file, "r") 549 alllines=finput.readlines() 550 finput.close() 551 foutput = 0 552 output_file = dst_file 553 foutput = open(output_file, 'a') 554 for eachline in alllines: 555 bc = textwrap.fill(eachline,73) 556 tmplines = bc.split('\n') 557 tmplen = len(tmplines) 558 if tmplen == 1 : 559 foutput.writelines(bc) 560 foutput.writelines('\n') 561 else : 562 i = 0 563 while i < tmplen-1 : 564 foutput.writelines(tmplines[i]) 565 foutput.writelines('\\') 566 foutput.writelines('\n') 567 i += 1 568 foutput.writelines(tmplines[tmplen-1]) 569 foutput.writelines('\n') 570 foutput.close 572 def auto_unwrap(input_file, dst_file) : 573 finput=open(input_file, "r") 574 alllines=finput.readlines() 575 finput.close() 576 foutput = 0 577 output_file = dst_file 578 foutput = open(output_file, 'a') 579 for eachline in alllines: 580 if eachline.endswith('\\\n') : 581 eachline = eachline.strip('\\\n') 582 foutput.writelines(eachline) 584 def auto_wrap_indent(input_file, dst_file,width): 585 finput=open(input_file, "r") 586 alllines=finput.readlines() 587 finput.close() 588 foutput = 0 589 flag_add = 0 590 pos = 0 591 output_file = dst_file 592 foutput = open(output_file, 'a') 593 for eachline in alllines: 594 pos = eachline.rstrip('\\\n').rfind('\\',0,width) 595 if (pos == width-1) : 596 bc = textwrap.fill(eachline,pos-1) 597 print("backslash appear at the end of the line, 598 the line is wrapped at the position one character 599 before the backslash") 600 else : 601 bc = textwrap.fill(eachline,73) 602 tmplines = bc.split('\n') 603 tmplen = len(tmplines) 604 if tmplen == 1 : 605 foutput.writelines(bc) 606 foutput.writelines('\n') 607 else : 608 flag_add = 0 609 i = 0 610 while i < tmplen-1 : 611 if(flag_add == 1) : 612 tmplines[i] = indent(tmplines[i], ' ') 613 foutput.writelines(tmplines[i]) 614 foutput.writelines('\\') 615 flag_add = 1 616 foutput.writelines('\n') 617 i += 1 618 if(flag_add == 1) : 619 tmplines[i] = indent(tmplines[i], ' ') 621 foutput.writelines(tmplines[tmplen-1]) 622 foutput.writelines('\n') 623 foutput.close 625 def auto_unwrap_dedent(input_file, dst_file) : 626 finput=open(input_file, "r") 627 alllines=finput.readlines() 628 finput.close() 629 foutput = 0 630 flag_del = 0 631 flag_enter = 0 632 output_file = dst_file 633 foutput = open(output_file, 'a') 634 for eachline in alllines: 635 if(flag_del == 1) : 636 eachline = eachline[2:] 637 if eachline.endswith('\\\n') : 638 flag_del = 1 639 eachline = eachline.strip('\\\n') 640 else : 641 flag_del = 0 642 foutput.writelines(eachline) 644 if __name__ == "__main__": 645 auto_wrap("in-1.txt","out-1.txt") 646 auto_unwrap("out-1.txt", "out-2.txt") 647 auto_wrap_indent("in-1.txt","out-1.txt",73) 648 auto_unwrap_dedent("out-1.txt", "out-2.txt") 650 Authors' Addresses 652 Qin Wu 653 Huawei 654 101 Software Avenue, Yuhua District 655 Nanjing, Jiangsu 210012 656 China 658 Email: bill.wu@huawei.com 660 Adrian Farrel 661 Juniper Networks 663 Email: afarrel@juniper.net 664 Benoit Claise 665 Cisco Systems, Inc. 666 De Kleetlaan 6a b1 667 1831 Diegem 668 Belgium 670 Phone: +32 2 704 5622 671 Email: bclaise@cisco.com