From loa@pi.nu Fri Mar 15 15:43:09 2013 Return-Path: X-Original-To: xml2rfc-dev@ietfa.amsl.com Delivered-To: xml2rfc-dev@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56CCC11E80BF for ; Fri, 15 Mar 2013 15:43:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.831 X-Spam-Level: X-Spam-Status: No, score=-100.831 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kpjv8cQTeTW8 for ; Fri, 15 Mar 2013 15:43:08 -0700 (PDT) Received: from mail.pi.nu (unknown [195.206.248.139]) by ietfa.amsl.com (Postfix) with ESMTP id 07D3021F8861 for ; Fri, 15 Mar 2013 15:43:06 -0700 (PDT) Received: from [130.129.133.99] (unknown [130.129.133.99]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.pi.nu (Postfix) with ESMTPSA id 1EBA2823B5; Fri, 15 Mar 2013 23:43:02 +0100 (CET) Message-ID: <5143A3FA.2050201@pi.nu> Date: Fri, 15 Mar 2013 23:43:06 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: xml2rfc-dev@ietf.org References: <08615E9C-C58B-4815-98F3-12D2C1F12F7A@gmail.com> In-Reply-To: <08615E9C-C58B-4815-98F3-12D2C1F12F7A@gmail.com> X-Forwarded-Message-Id: <08615E9C-C58B-4815-98F3-12D2C1F12F7A@gmail.com> Content-Type: multipart/mixed; boundary="------------010605040109000904020601" X-Mailman-Approved-At: Fri, 15 Mar 2013 18:43:42 -0700 Cc: Kireeti Kompella , Adrian Farrel Subject: [xml2rfc-dev] Problem compiling with the xml beta version - Fwd: special purpose labels X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion about particulars of xml2rfc development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 22:43:09 -0000 This is a multi-part message in MIME format. --------------010605040109000904020601 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Folks, I've included two files - draft-kompella-mpls-special-purpose-labels-02.xml - draft-kompella-mpls-special-purpose-labels-02.txt We are updating a number of RFCs, and uses the "updates" element in the RFC-header. Compiling with the beta version gives us a long long row that disappears way beyond the right hand side of the the file as shown in the .txt file. The long row also prevents uploading with the submit tool. Using the old xml2rfc version works just fine. /Loa -------- Original Message -------- Subject: special purpose labels Date: Thu, 14 Mar 2013 19:28:02 -0400 From: Kireeti Kompella To: Loa Andersson , "adrian@olddog.co.uk Farrel" CC: Kireeti Kompella (resending -- correct address for Adrian) Sat with Loa, hammered out the following changes: 0) changed draft title, affiliations of Loa and me. 1) add a section describing RFCs updated. 2) added clarification that the extension label only affects the immediately following label. 3) clarified IANA: - set aside the existing special purpose labels in the extended space - if a new special purpose label in the old space is defined, it MUST say if it needs to be reserved in the extended space as well Question: should there be verbiage that new special purpose labels should only be allocated from the old space if they are processed in the data plane? Kireeti --------------010605040109000904020601 Content-Type: application/xml; name="draft-kompella-mpls-special-purpose-labels-02.xml" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="draft-kompella-mpls-special-purpose-labels-02.xml" PD94bWwgdmVyc2lvbj0iMS4wIj8+DQo8IURPQ1RZUEUgcmZjIFNZU1RFTSAicmZjMjYyOS5k dGQiPg0KPD9yZmMgdG9jPSJ5ZXMiPz4NCjxyZmMgaXByPSJ0cnVzdDIwMDkwMiIgY2F0ZWdv cnk9InN0ZCIgdXBkYXRlcz0nMzAzMiwgMzAzOCwgMzIwOSwgMzgxMSwNCjQxODIsIDQ5Mjgs IDUzMzEsIDU1ODYsIDU5MjEsIA0KNTk2MCwgNjM5MSwgNjQ3OCwgNjc5MCc+DQogIDxmcm9u dD4NCiAgICA8dGl0bGUgYWJicmV2PSdTcGVjaWFsIFB1cnBvc2UgTVBMUyBMYWJlbHMnPg0K ICAgICAgQWxsb2NhdGluZyBhbmQgUmV0aXJpbmcgU3BlY2lhbCBQdXJwb3NlIE1QTFMgTGFi ZWxzDQogICAgPC90aXRsZT4NCg0KICAgIDxhdXRob3IgaW5pdGlhbHM9IksuIiBzdXJuYW1l PSJLb21wZWxsYSIgZnVsbG5hbWU9IktpcmVldGkgS29tcGVsbGEiPg0KICAgICAgPG9yZ2Fu aXphdGlvbj5KdW5pcGVyIE5ldHdvcmtzPC9vcmdhbml6YXRpb24+DQogICAgICA8YWRkcmVz cz4NCgk8cG9zdGFsPg0KCSAgPHN0cmVldD4xMTMzIElubm92YXRpb24gV2F5PC9zdHJlZXQ+ DQoJICA8Y2l0eT5TdW5ueXZhbGU8L2NpdHk+DQoJICA8cmVnaW9uPkNBPC9yZWdpb24+DQoJ ICA8Y29kZT45NDA4OTwvY29kZT4NCgkgIDxjb3VudHJ5PlVTPC9jb3VudHJ5Pg0KCTwvcG9z dGFsPg0KCTxlbWFpbD5raXJlZXRpLmtvbXBlbGxhQGdtYWlsLmNvbTwvZW1haWw+DQogICAg ICA8L2FkZHJlc3M+DQogICAgPC9hdXRob3I+DQoNCiAgICA8YXV0aG9yIGluaXRpYWxzPSJM LiIgc3VybmFtZT0nQW5kZXJzc29uJyBmdWxsbmFtZT0nTG9hIEFuZGVyc3Nvbic+DQogICAg ICA8b3JnYW5pemF0aW9uPkh1YXdlaTwvb3JnYW5pemF0aW9uPg0KICAgICAgPGFkZHJlc3M+ DQoJPGVtYWlsPmxvYUBtYWlsMDEuaHVhd2VpLmNvbTwvZW1haWw+DQogICAgICA8L2FkZHJl c3M+DQogICAgPC9hdXRob3I+DQoNCiAgICA8YXV0aG9yIGluaXRpYWxzPSJBLiIgc3VybmFt ZT0nRmFycmVsJyBmdWxsbmFtZT0nQWRyaWFuIEZhcnJlbCc+DQogICAgICA8b3JnYW5pemF0 aW9uPkp1bmlwZXIgTmV0d29ya3M8L29yZ2FuaXphdGlvbj4NCiAgICAgIDxhZGRyZXNzPg0K CTxlbWFpbD5hZHJpYW5Ab2xkZG9nLmNvLnVrPC9lbWFpbD4NCiAgICAgIDwvYWRkcmVzcz4N CiAgICA8L2F1dGhvcj4NCg0KICAgIDxkYXRlIHllYXI9IjIwMTIiLz4NCiAgICA8YXJlYT5S b3V0aW5nPC9hcmVhPg0KICAgIDxrZXl3b3JkPk1QTFMsIHJlc2VydmVkIGxhYmVsPC9rZXl3 b3JkPg0KDQogICAgPGFic3RyYWN0Pg0KICAgICAgPHQ+DQoJU29tZSBNUExTIGxhYmVscyBo YXZlIGJlZW4gYWxsb2NhdGVkIGZvciBzcGVjaWZpYyBwdXJwb3Nlcy4gIEENCglibG9jayBv ZiBsYWJlbHMgKDAtMTUpIGhhcyBiZWVuIHNldCBhc2lkZSB0byB0aGlzIGVuZCwgYW5kIGFy ZQ0KCWNvbW1vbmx5IGNhbGxlZCAicmVzZXJ2ZWQgbGFiZWxzIi4gIFRoZXkgd2lsbCBiZSBj YWxsZWQNCgkic3BlY2lhbCBwdXJwb3NlIGxhYmVscyIgaW4gdGhpcyBkb2N1bWVudC4gIEFz IHRoZXJlIGFyZSBvbmx5DQoJMTYgb2YgdGhlc2UgbGFiZWxzLCBjYXV0aW9uIGlzIG5lZWRl ZCBpbiB0aGUgYWxsb2NhdGlvbiBvZiBuZXcNCglzcGVjaWFsIHB1cnBvc2UgbGFiZWxzLCB5 ZXQgYXQgdGhlIHNhbWUgdGltZSBhbGxvdyBmb3J3YXJkDQoJcHJvZ3Jlc3Mgd2hlbiBvbmUg aXMgY2FsbGVkIGZvci4gIFRoaXMgbWVtbyBkZWZpbmVzIHNvbWUNCglwcm9jZWR1cmVzIHRv IGZvbGxvdyBpbiB0aGUgYWxsb2NhdGlvbiBhbmQgcmV0aXJlbWVudCBvZg0KCXNwZWNpYWwg cHVycG9zZSBsYWJlbHMsIGFzIHdlbGwgYXMgYSBtZXRob2QgdG8gZXh0ZW5kIHRoZQ0KCXNw ZWNpYWwgcHVycG9zZSBsYWJlbCBzcGFjZS4gIEZpbmFsbHksIHRoaXMgbWVtbyByZW5hbWVz IHRoZQ0KCUlBTkEgcmVnaXN0cnkgZm9yIHRoZXNlIGxhYmVscyB0byAiU3BlY2lhbCBQdXJw b3NlIE1QTFMgTGFiZWwNCglWYWx1ZXMiLCBhbmQgY3JlYXRlcyBhIG5ldyBvbmUgY2FsbGVk IHRoZSAiRXh0ZW5kZWQgU3BlY2lhbA0KCVB1cnBvc2UgTVBMUyBMYWJlbCBWYWx1ZXMiIHJl Z2lzdHJ5Lg0KICAgICAgPC90Pg0KICAgIDwvYWJzdHJhY3Q+DQogIDwvZnJvbnQ+DQoNCiAg PG1pZGRsZT4NCiAgICA8c2VjdGlvbiB0aXRsZT0iSW50cm9kdWN0aW9uIiBhbmNob3I9J2lu dHJvJz4NCiAgICAgIDx0Pg0KCVRoZSBzcGVjaWZpY2F0aW9uIG9mIHRoZSBMYWJlbCBTdGFj ayBFbmNvZGluZyBmb3INCglNdWx0aS1Qcm90b2NvbCBMYWJlbCBTd2l0Y2hpbmcgKE1QTFMp IDx4cmVmIHRhcmdldD0nUkZDMzAzMicvPg0KCWRlZmluZWQgZm91ciBzcGVjaWFsIHB1cnBv c2UgbGFiZWwgdmFsdWVzICgwIHRvIDMpLCBhbmQgc2V0DQoJYXNpZGUgdmFsdWVzIDQgdGhy b3VnaCAxNSBmb3IgZnV0dXJlIHVzZS4gIFRoZXNlIGxhYmVscyBoYXZlDQoJc3BlY2lhbCBz aWduaWZpY2FuY2UgaW4gYm90aCB0aGUgY29udHJvbCBhbmQgdGhlIGRhdGEgcGxhbmUuDQoJ U2luY2UgdGhlbiwgdGhyZWUgZnVydGhlciB2YWx1ZXMgaGF2ZSBiZWVuIGFsbG9jYXRlZCAo dmFsdWVzDQoJNywgMTMsIGFuZCAxNCBpbiA8eHJlZiB0YXJnZXQ9J1JGQzY3OTAnLz4sIDx4 cmVmDQoJdGFyZ2V0PSdSRkM1NTg2Jy8+IGFuZCA8eHJlZiB0YXJnZXQ9J1JGQzM0MjknLz4s DQoJcmVzcGVjdGl2ZWx5KSwgbGVhdmluZyBuaW5lIHVuYXNzaWduZWQgdmFsdWVzIGZyb20g dGhlDQoJb3JpZ2luYWwgc3BhY2Ugb2Ygc2l4dGVlbi4NCiAgICAgIDwvdD4NCiAgICAgIDx0 Pg0KCVdoaWxlIHRoZSBhbGxvY2F0aW9uIG9mIHRocmVlIG91dCBvZiB0aGUgcmVtYWluaW5n IHR3ZWx2ZQ0KCXNwZWNpYWwgcHVycG9zZSBsYWJlbCB2YWx1ZXMgaW4gdGhlIHNwYWNlIG9m IGFib3V0IDEyIHllYXJzIGlzDQoJbm90IGluIGl0c2VsZiBhIGNhdXNlIGZvciBjb25jZXJu LCB0aGUgc2NhcmNpdHkgb2Ygc3BlY2lhbA0KCXB1cnBvc2UgbGFiZWxzIGlzLiAgRnVydGhl cm1vcmUsIG1hbnkgb2YgdGhlIHNwZWNpYWwgcHVycG9zZQ0KCWxhYmVscyByZXF1aXJlIHNw ZWNpYWwgcHJvY2Vzc2luZyBieSBmb3J3YXJkaW5nIGhhcmR3YXJlLA0KCWNoYW5nZXMgdG8g d2hpY2ggYXJlIG9mdGVuIGV4cGVuc2l2ZSwgYW5kIHNvbWV0aW1lcw0KCWltcG9zc2libGUu ICBUaHVzLCBkb2N1bWVudGluZyBhIG5ld2x5IGFsbG9jYXRlZCBzcGVjaWFsDQoJcHVycG9z ZSBsYWJlbCB2YWx1ZSBpcyBpbXBvcnRhbnQuDQogICAgICA8L3Q+DQogICAgICA8dD4NCglU aGlzIG1lbW8gb3V0bGluZXMgc29tZSBvZiB0aGUgaXNzdWVzIGluIGFsbG9jYXRpbmcgYW5k DQoJcmV0aXJpbmcgc3BlY2lhbCBwdXJwb3NlIGxhYmVsIHZhbHVlcywgYW5kIGRlZmluZXMg bWVjaGFuaXNtcw0KCXRvIGFkZHJlc3MgdGhlc2UuICBUaGlzIG1lbW8gYWxzbyBleHRlbmRz IHRoZSBzcGFjZSBvZiBzcGVjaWFsDQoJcHVycG9zZSBsYWJlbHMuDQogICAgICA8L3Q+DQoN CiAgICAgIDxzZWN0aW9uIGFuY2hvcj0iY29udiIgdGl0bGU9IkNvbnZlbnRpb25zIHVzZWQi Pg0KCTx0Pg0KCSAgVGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFVSVJF RCIsICJTSEFMTCIsDQoJICAiU0hBTEwgTk9UIiwgIlNIT1VMRCIsICJTSE9VTEQgTk9UIiwg IlJFQ09NTUVOREVEIiwgIk1BWSIsDQoJICBhbmQgIk9QVElPTkFMIiBpbiB0aGlzIGRvY3Vt ZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcw0KCSAgZGVzY3JpYmVkIGluIDx4cmVmIHRh cmdldD0iUkZDMjExOSIvPi4NCgk8L3Q+DQogICAgICA8L3NlY3Rpb24+DQogICAgPC9zZWN0 aW9uPg0KDQogICAgPHNlY3Rpb24gdGl0bGU9J1F1ZXN0aW9ucyc+DQogICAgICA8dD4NCglJ biByZS1hcHByYWlzaW5nIE1QTFMgc3BlY2lhbCBwdXJwb3NlIGxhYmVscywgdGhlIGZvbGxv d2luZw0KCXF1ZXN0aW9ucyBjb21lIHRvIG1pbmQ6DQoJPGxpc3Qgc3R5bGU9J251bWJlcnMn Pg0KCSAgPHQ+DQoJICAgIFdoYXQgYWxsb2NhdGlvbiBwb2xpY2llcyBzaG91bGQgYmUgYXBw bGllZCBieSBJQU5BIGZvciB0aGUNCgkgICAgYWxsb2NhdGlvbiBvZiBzcGVjaWFsIHB1cnBv c2UgbGFiZWxzPyAgU2hvdWxkIEVhcmx5DQoJICAgIEFsbG9jYXRpb24gPHhyZWYgdGFyZ2V0 PSdSRkM0MDIwJy8+IGJlIGFsbG93ZWQ/ICBTaG91bGQNCgkgICAgdGhlcmUgYmUgbGFiZWxz IGZvciBFeHBlcmltZW50YWwgVXNlIG9yIFByaXZhdGUgVXNlIDx4cmVmDQoJICAgIHRhcmdl dD0nUkZDNTIyNicvPj8NCgkgIDwvdD4NCgkgIDx0Pg0KCSAgICBXaGF0IGRvY3VtZW50YXRp b24gaXMgcmVxdWlyZWQgZm9yIHNwZWNpYWwgcHVycG9zZSBsYWJlbHMNCgkgICAgYWxsb2Nh dGVkIGhlbmNlZm9ydGg/DQoJICA8L3Q+DQoJICA8dD4NCgkgICAgU2hvdWxkIGEgc3BlY2lh bCBwdXJwb3NlIGxhYmVsIGV2ZXIgYmUgcmV0aXJlZD8gIFdoYXQNCgkgICAgY3JpdGVyaWEg YXJlIHJlbGV2YW50IGhlcmU/ICBDYW4gYSByZXRpcmVkIHNwZWNpYWwgcHVycG9zZQ0KCSAg ICBsYWJlbCBldmVyIGJlIHJlLWFsbG9jYXRlZCBmb3IgYSBkaWZmZXJlbnQgcHVycG9zZT8g IFdoYXQNCgkgICAgcHJvY2VkdXJlcyBhbmQgdGltZSBmcmFtZXMgYXJlIGFwcHJvcHJpYXRl Pw0KCSAgPC90Pg0KCSAgPHQ+DQoJICAgIFRoZSBzcGVjaWFsIHB1cnBvc2UgbGFiZWwgdmFs dWUgb2YgMyAodGhlICJJbXBsaWNpdCBOdWxsDQoJICAgIExhYmVsIiwgPHhyZWYgdGFyZ2V0 PSdSRkMzMDMyJy8+KSBpcyBvbmx5IHVzZWQgaW4NCgkgICAgc2lnbmFsaW5nLCBuZXZlciBp biB0aGUgZGF0YSBwbGFuZS4gIENvdWxkIGl0IChhbmQgc2hvdWxkDQoJICAgIGl0KSBiZSB1 c2VkIGluIHRoZSBkYXRhIHBsYW5lPyAgSWYgc28sIGhvdyBhbmQgZm9yIHdoYXQNCgkgICAg cHVycG9zZT8NCgkgIDwvdD4NCgkgIDx0Pg0KCSAgICBXaGF0IGlzIGEgZmVhc2libGUgbWVj aGFuaXNtIHRvIGV4dGVuZCB0aGUgc3BhY2Ugb2YNCgkgICAgc3BlY2lhbCBwdXJwb3NlIGxh YmVscywgc2hvdWxkIHRoaXMgYmVjb21lIG5lY2Vzc2FyeT8NCgkgIDwvdD4NCgk8L2xpc3Q+ DQogICAgICA8L3Q+DQogICAgPC9zZWN0aW9uPg0KDQogICAgPHNlY3Rpb24gdGl0bGU9J0Fu c3dlcnMnPg0KICAgICAgPHQ+DQoJVGhpcyBzZWN0aW9uIHByb3ZpZGVzIGFuc3dlcnMgdG8g dGhlIHF1ZXN0aW9ucyBwb3NlZCBpbiB0aGUNCglwcmV2aW91cyBzZWN0aW9uLg0KCTxsaXN0 IHN0eWxlPSdudW1iZXJzJz4NCgkgIDx0Pg0KCSAgICA8bGlzdCBzdHlsZT0nbGV0dGVycyc+ DQoJICAgICAgPHQ+DQoJCUFsbG9jYXRpb24gb2Ygc3BlY2lhbCBwdXJwb3NlIE1QTFMgbGFi ZWxzIGlzIHZpYQ0KCQkiU3RhbmRhcmRzIEFjdGlvbiIuDQoJICAgICAgPC90Pg0KCSAgICAg IDx0Pg0KCQlUaGUgSUFOQSByZWdpc3RyeSB3aWxsIGJlIHJlbmFtZWQgIlNwZWNpYWwgUHVy cG9zZQ0KCQlNUExTIExhYmVscyIuDQoJICAgICAgPC90Pg0KCSAgICAgIDx0Pg0KCQlFYXJs eSBhbGxvY2F0aW9uIG1heSBiZSBhbGxvd2VkIG9uIGEgY2FzZS1ieS1jYXNlDQoJCWJhc2lz Lg0KCSAgICAgIDwvdD4NCgkgICAgICA8dD4NCgkJVGhlIGN1cnJlbnQgc3BhY2Ugb2YgMTYg c3BlY2lhbCBwdXJwb3NlIGxhYmVscyBpcyB0b28NCgkJc21hbGwgZm9yIHNldHRpbmcgYXNp ZGUgdmFsdWUgZm9yIGV4cGVyaW1lbnRhbCBvcg0KCQlwcml2YXRlIHVzZS4gIEhvd2V2ZXIs IHRoZSBleHRlbmRlZCBzcGVjaWFsIHB1cnBvc2UNCgkJbGFiZWxzIHJlZ2lzdHJ5IGNyZWF0 ZWQgYnkgdGhpcyBkb2N1bWVudCBoYXMgZW5vdWdoDQoJCXNwYWNlLCBhbmQgdGhpcyBkb2N1 bWVudCBkZWZpbmVzIGEgcmFuZ2UgZm9yDQoJCWV4cGVyaW1lbnRhbCB1c2UuDQoJICAgICAg PC90Pg0KCSAgICA8L2xpc3Q+DQoJICA8L3Q+DQoJICA8dD4NCgkgICAgQSBTdGFuZGFyZHMg VHJhY2sgUkZDIG11c3QgYWNjb21wYW55IGEgcmVxdWVzdCBmb3INCgkgICAgYWxsb2NhdGlv biBvZiBzcGVjaWFsIHB1cnBvc2UgbGFiZWxzLCBhcyBwZXIgPHhyZWYNCgkgICAgdGFyZ2V0 PSdSRkM1MjI2Jy8+Lg0KCSAgPC90Pg0KCSAgPHQ+DQoJICAgIFRoZSByZXRpcmVtZW50IG9m IGEgc3BlY2lhbCBwdXJwb3NlIE1QTFMgbGFiZWwgdmFsdWUgbXVzdA0KCSAgICBmb2xsb3cg YSBzdHJpY3QgYW5kIHdlbGwtZG9jdW1lbnRlZCBwcm9jZXNzLiBUaGlzIGlzDQoJICAgIG5l Y2Vzc2FyeSBzaW5jZSB3ZSBtdXN0IGF2b2lkIG9ycGhhbmluZyB0aGUgdXNlIG9mIHRoaXMN CgkgICAgbGFiZWwgdmFsdWUgaW4gZXhpc3RpbmcgZGVwbG95bWVudHMuICBUaGlzIHByb2Nl c3MgaXMNCgkgICAgZGV0YWlsZWQgaW4gPHhyZWYgdGFyZ2V0PSdkZXByZWNhdGUnLz4uDQoJ ICA8L3Q+DQoJICA8dD4NCgkgICAgVGhlIHVzZSBvZiB0aGUgImltcGxpY2l0IG51bGwgbGFi ZWwiIChsYWJlbCAzKSBpbiB0aGUgZGF0YQ0KCSAgICBwbGFuZSBtYXkgYmUgYWxsb3dlZCwg c3ViamVjdCB0byBhcHByb3ZhbCBieSB0aGUgTVBMUyBXRywNCgkgICAgYW5kIGFuIGFjY29t cGFueWluZyBTdGFuZGFyZHMgVHJhY2sgUkZDIHRoYXQgZGV0YWlscyB0aGUNCgkgICAgdXNl IG9mIHRoZSBsYWJlbCwgYW5kIGEgZGlzY3Vzc2lvbiBvZiBwb3NzaWJsZSBzb3VyY2VzIG9m DQoJICAgIGNvbmZ1c2lvbiBiZXR3ZWVuIHNpZ25hbGluZyBhbmQgZGF0YSBwbGFuZSwgYW5k IG1pdGlnYXRpb24NCgkgICAgdGhlcmVvZi4NCgkgIDwvdD4NCgkgIDx0Pg0KCSAgICBUaGUg c3BlY2lhbCBwdXJwb3NlIGxhYmVsICh0aGUgImV4dGVuc2lvbiIgbGFiZWwpIGlzIHRvIGJl DQoJICAgIHNldCBhc2lkZSBmb3IgdGhlIHB1cnBvc2Ugb2YgZXh0ZW5kaW5nIHRoZSBzcGFj ZSBvZg0KCSAgICBzcGVjaWFsIHB1cnBvc2UgbGFiZWxzLiAgRnVydGhlciBkZXRhaWxzIGFy ZSBkZXNjcmliZWQgaW4NCgkgICAgPHhyZWYgdGFyZ2V0PSdlc3BtbCcvPi4NCgkgIDwvdD4N Cgk8L2xpc3Q+DQogICAgICA8L3Q+DQogICAgICA8dD4NCglBIGZ1cnRoZXIgcXVlc3Rpb24g dG8gYmUgc2V0dGxlZCBpbiB0aGlzIHJlZ2FyZCBpcyB3aGV0aGVyIGENCgkicmVndWxhciIg c3BlY2lhbCBwdXJwb3NlIGxhYmVsIHJldGFpbnMgaXRzIG1lYW5pbmcgaWYgaXQNCglmb2xs b3dzIHRoZSBleHRlbnNpb24gbGFiZWw7IHNlZSA8eHJlZiB0YXJnZXQ9J2VzcG1sJy8+Lg0K ICAgICAgPC90Pg0KDQogICAgICA8c2VjdGlvbiB0aXRsZT0nRXh0ZW5kZWQgU3BlY2lhbCBQ dXJwb3NlIE1QTFMgTGFiZWwgVmFsdWVzJw0KCSAgICAgICBhbmNob3I9J2VzcG1sJz4NCgk8 dD4NCgkgIEFuIGV4dGVuc2lvbiBsYWJlbCBNVVNUIGJlIGZvbGxvd2VkIGJ5IGFub3RoZXIg bGFiZWwgTCAoYW5kDQoJICB0aHVzIE1VU1QgaGF2ZSB0aGUgYm90dG9tLW9mLXN0YWNrIGJp dCBjbGVhcikuICBMIE1VU1QgYmUNCgkgIGludGVycHJldGVkIGFzIGFuICJleHRlbmRlZCBz cGVjaWFsIHB1cnBvc2UgbGFiZWwiIGZyb20gYQ0KCSAgbmV3IHJlZ2lzdHJ5IGNyZWF0ZWQg YnkgdGhpcyBkb2N1bWVudCAoc2VlIDx4cmVmDQoJICB0YXJnZXQ9J0lBTkEnLz4pLiAgV2hl dGhlciBvciBub3QgTCBoYXMgdGhlIGJvdHRvbS1vZi1zdGFjaw0KCSAgYml0IHNldCBkZXBl bmRzIG9uIHdoZXRoZXIgb3RoZXIgbGFiZWxzIGZvbGxvdyBMLiBPbmx5IEwgaXMNCgkgIGlu dGVycHJldGVkIGFzIGFuIGV4dGVuZGVkIHNwZWNpYWwgcHVycG9zZSBsYWJlbDsgbGFiZWxz DQoJICBmb2xsb3dpbmcgTCBhcmUgaW50ZXJwcmV0ZWQgYXMgbm9ybWFsLg0KCTwvdD4NCgk8 dD4NCgkgIElBTkEgaXMgYXNrZWQgdG8gc2V0IGFzaWRlIGxhYmVsIHZhbHVlIDE1IGFzIHRo ZSBleHRlbnNpb24NCgkgIGxhYmVsLg0KCTwvdD4NCgk8dD4NCgkgIFRoZSBmaXJzdCAxNiB2 YWx1ZXMgb2YgdGhlIGV4dGVuZGVkIHNwZWNpYWwgcHVycG9zZSBsYWJlbA0KCSAgcmVnaXN0 cnkgYXJlIGR1cGxpY2F0ZWQgZnJvbSB0aGUgcHJlLWV4aXN0aW5nIHNwZWNpYWwNCgkgIHB1 cnBvc2UgbGFiZWwgcmVnaXN0cnkuICBUaGlzIGluY2x1ZGVzIHRoZSBwcmV2aW91c2x5DQoJ ICBhbGxvY2F0ZWQgdmFsdWVzICgwLTMsIDcsIDEzLCBhbmQgMTQpLCB0aGUgZXh0ZW5zaW9u IGxhYmVsDQoJICB2YWx1ZSAoMTUpIGFsbG9jYXRlZCBieSB0aGlzIGRvY3VtZW50LCBhbmQg dGhlIHJlbWFpbmluZw0KCSAgdW5hbGxvY2F0ZWQgdmFsdWVzICg0LTYgYW5kIDgtMTIpLiAg QW55IG9mIHRoZXNlIHZhbHVlcw0KCSAgcHJlc2VudCBhcyBhbiBleHRlbmRlZCBzcGVjaWFs IHB1cnBvc2UgbGFiZWwgTVVTVCBiZQ0KCSAgaW50ZXJwcmV0ZWQgZXhhY3RseSBhcyBpdCB3 b3VsZCBpZiBpdCB3YXMgcHJlc2VudGVkIGFzIGENCgkgIHNwZWNpYWwgcHVycG9zZSBsYWJl bC4gIEluIHBhcnRpY3VsYXIsIGFuIGFyYml0cmFyeSBzdHJpbmcNCgkgIG9mIGNvbnNlY3V0 aXZlIGV4dGVuc2lvbiBsYWJlbHMgaXMgbGVnYWwsIGFuZCBzZW1hbnRpY2FsbHkNCgkgIGVx dWl2YWxlbnQgdG8gYSBzaW5nbGUgZXh0ZW5zaW9uIGxhYmVsIChub3RlIHRoYXQgdGhpcw0K CSAgc3RyaW5nIG9mIGV4dGVuc2lvbiBsYWJlbHMgTVVTVCBiZSBmb2xsb3dlZCBieSBhbiBl eHRlbmRlZA0KCSAgc3BlY2lhbCBwdXJwb3NlIGxhYmVsIHRoYXQgaXMgbm90IHRoZSBleHRl bnNpb24gbGFiZWwpLg0KCTwvdD4NCiAgICAgIDwvc2VjdGlvbj4NCg0KICAgICAgPHNlY3Rp b24gdGl0bGU9J1Byb2Nlc3MgZm9yIFJldGlyaW5nIFNwZWNpYWwgUHVycG9zZSBMYWJlbHMn DQoJICAgICAgIGFuY2hvcj0nZGVwcmVjYXRlJz4NCgk8dD4NCgkgIDxsaXN0IHN0eWxlPSds ZXR0ZXJzJz4NCgkgICAgPHQ+DQoJICAgICAgQSBsYWJlbCB2YWx1ZSB0aGF0IGhhcyBiZWVu IGFzc2lnbmVkIGZyb20gdGhlICJTcGVjaWFsDQoJICAgICAgUHVycG9zZSBNUExTIExhYmVs IFZhbHVlcyIgbWF5IGJlIGRlcHJlY2F0ZWQgYnkgSUVURg0KCSAgICAgIGNvbnNlbnN1cyB3 aXRoIHJldmlldyBieSB0aGUgTVBMUyB3b3JraW5nIGdyb3VwIChvcg0KCSAgICAgIGRlc2ln bmF0ZWQgZXhwZXJ0cyBpZiB0aGUgd29ya2luZyBncm91cCBvciBhIHN1Y2Nlc3Nvcg0KCSAg ICAgIGRvZXMgbm90IGV4aXN0KS4gIEFuIFJGQyB3aXRoIGF0IGxlYXN0IEluZm9ybWF0aW9u YWwNCgkgICAgICBzdGF0dXMgaXMgcmVxdWlyZWQuDQoJICAgICAgPHZzcGFjZSBibGFua0xp bmVzPScxJyAvPg0KCSAgICAgIFRoZSBSRkMgd2lsbCBkaXJlY3QgdGhlIElBTkEgdG8gbWFy ayB0aGUgbGFiZWwgdmFsdWUgYXMNCgkgICAgICAiZGVwcmVjYXRlZCIgaW4gdGhlIHJlZ2lz dHJ5LCBidXQgd2lsbCBub3QgcmVsZWFzZSBpdCBhdA0KCSAgICAgIHRoaXMgc3RhZ2UuDQoJ ICAgICAgPHZzcGFjZSBibGFua0xpbmVzPScxJyAvPg0KCSAgICAgIERlcHJlY2F0aW5nIG1l YW5zIHRoYXQgbm8gZnVydGhlciBzcGVjaWZpY2F0aW9ucyB1c2luZw0KCSAgICAgIHRoZSBk ZXByZWNhdGVkIHZhbHVlIHdpbGwgYmUgZG9jdW1lbnRlZC4NCgkgICAgICA8dnNwYWNlIGJs YW5rTGluZXM9JzEnIC8+DQoJICAgICAgQXQgdGhlIHNhbWUgdGltZSB0aGlzIGlzIGFuIGlu ZGljYXRpb24gdG8gdmVuZG9ycyBub3QgdG8NCgkgICAgICBpbmNsdWRlIGRlcHJlY2F0ZWQg dmFsdWUgaW4gbmV3IGltcGxlbWVudGF0aW9ucyBhbmQgdG8NCgkgICAgICBvcGVyYXRvcnMg dG8gYXZvaWQgaW5jbHVkaW5nIGl0IGluIG5ldyBkZXBsb3ltZW50cy4NCgkgICAgPC90Pg0K CSAgICA8dD4NCgkgICAgICAxMiBtb250aHMgYWZ0ZXIgdGhlIFJGQyBkZXByZWNhdGluZyB0 aGUgbGFiZWwgdmFsdWUgaXMNCgkgICAgICBwdWJsaXNoZWQsIGFuIElFVEYtd2lkZSBzdXJ2 ZXkgbWF5IGJlIGNvbmR1Y3RlZCB0bw0KCSAgICAgIGRldGVybWluZSBpZiB0aGUgZGVwcmVj YXRlZCBsYWJlbCB2YWx1ZSBpcyBzdGlsbCBpbiB1c2UuDQoJICAgICAgSWYgdGhlIHN1cnZl eSBpbmRpY2F0ZXMgdGhhdCB0aGUgZGVwcmVjYXRlZCBsYWJlbCB2YWx1ZQ0KCSAgICAgIGlz IGluIHVzZSwgdGhlIHN1cnZleSBtYXkgYmUgcmVwZWF0ZWQgYWZ0ZXIgYSBmdXJ0aGVyIDYN CgkgICAgICBtb250aHMuDQoJICAgIDwvdD4NCgkgICAgPHQ+DQoJICAgICAgMjQgbW9udGhz IGFmdGVyIHRoZSBSRkMgdGhhdCBkZXByZWNhdGVkIHRoZSBsYWJlbCB2YWx1ZQ0KCSAgICAg IHdhcyBwdWJsaXNoZWQgYW5kIGlmIHRoZSBzdXJ2ZXkgaW5kaWNhdGVzIHRoYXQNCgkgICAg ICBkZXByZWNhdGVkIGxhYmVsIHZhbHVlIGlzIG5vdCBpbiB1c2UsIHB1YmxpY2F0aW9uIG1h eSBiZQ0KCSAgICAgIHJlcXVlc3RlZCBvZiBhbiBJRVRGIFN0YW5kYXJkcyBUcmFjayBJbnRl cm5ldC1EcmFmdCB0aGF0DQoJICAgICAgcmV0aXJlcyB0aGUgZGVwcmVjYXRlZCB0aGUgbGFi ZWwgdmFsdWUuICBUaGlzIGRvY3VtZW50DQoJICAgICAgd2lsbCByZXF1ZXN0IElBTkEgdG8g cmVsZWFzZSB0aGUgbGFiZWwgdmFsdWUgZm9yIGZvcg0KCSAgICAgIGZ1dHVyZSB1c2UgYW5k IGFzc2lnbm1lbnQuDQoJICAgIDwvdD4NCgkgIDwvbGlzdD4NCgk8L3Q+DQogICAgICA8L3Nl Y3Rpb24+DQogICAgPC9zZWN0aW9uPg0KDQogICAgPHNlY3Rpb24gdGl0bGU9J1VwZGF0ZWQg UkZDcyc+DQogICAgICA8dD4NCglUaGUgZm9sbG93aW5nIFJGQ3MgY29udGFpbiByZWZlcmVu Y2VzIHRvIHRoZSB0ZXJtICJyZXNlcnZlZA0KCWxhYmVscyI6IDx4cmVmIHRhcmdldD0nUkZD MzAzMicvPiAoIk1QTFMgTGFiZWwgU3RhY2sNCglFbmNvZGluZyIpLCA8eHJlZiB0YXJnZXQ9 J1JGQzMwMzgnLz4gKCJWQ0lEIE5vdGlmaWNhdGlvbiBmb3INCglMRFAiKSwgPHhyZWYgdGFy Z2V0PSdSRkMzMjA5Jy8+ICgiRXh0ZW5zaW9ucyB0byBSU1ZQIGZvciBMU1ANCglUdW5uZWxz IiksIDx4cmVmIHRhcmdldD0nUkZDMzgxMScvPiAoIk1QTFMgVEMgTUlCIiksIDx4cmVmDQoJ dGFyZ2V0PSdSRkM0MTgyJy8+ICgiUmVtb3ZpbmcgYSBSZXN0cmljdGlvbiBvbiB0aGUgdXNl IG9mDQoJTVBMUyIpLCA8eHJlZiB0YXJnZXQ9J1JGQzQ5MjgnLz4gKCJBdm9pZGluZyBFQ01Q IFRyZWF0bWVudCBpbg0KCU1QTFMgTmV0d29ya3MiKSwgPHhyZWYgdGFyZ2V0PSdSRkM1MzMx Jy8+LCA8eHJlZg0KCXRhcmdldD0nUkZDNTU4NicvPiAoIkctQUNoIGFuZCBHQUwiKSwgPHhy ZWYgdGFyZ2V0PSdSRkM1OTIxJy8+DQoJKCJNUExTIFRyYW5zcG9ydCBQcm9maWxlIEZyYW1l d29yayIpLCA8eHJlZiB0YXJnZXQ9J1JGQzU5NjAnLz4NCgkoIk1QTFMtVFAgRGF0YSBQbGFu ZSBBcmNoaXRlY3R1cmUiKSwgPHhyZWYgdGFyZ2V0PSdSRkM2NzkwJy8+DQoJKCJNUExTIEVu dHJvcHkgTGFiZWxzIiksIDx4cmVmIHRhcmdldD0nUkZDNjM5MScvPiAoIkZBVC1QVyIpLA0K CWFuZCA8eHJlZiB0YXJnZXQ9J1JGQzY0NzgnLz4gKCJQc2V1ZG93aXJlIFN0YXR1cyBmb3Ig U3RhdGljDQoJUHNldWRvd2lyZXMiKS4gIEFsbCBzdWNoIHJlZmVyZW5jZXMgc2hvdWxkIGJl IHJlYWQgYXMgInNwZWNpYWwNCglwdXJwb3NlIGxhYmVscyIuDQogICAgICA8L3Q+DQogICAg PC9zZWN0aW9uPg0KDQogICAgPHNlY3Rpb24gdGl0bGU9J0lBTkEgQ29uc2lkZXJhdGlvbnMn DQoJICAgICBhbmNob3I9J0lBTkEnPg0KICAgICAgPHQ+DQoJVGhpcyBkb2N1bWVudCByZXF1 ZXN0cyBJQU5BIHRvIG1ha2UgdGhlIGZvbGxvd2luZyBjaGFuZ2VzIGFuZA0KCWFkZGl0aW9u cyB0byBpdHMgcmVnaXN0cmF0aW9uIG9mIE1QTFMgTGFiZWxzLg0KCTxsaXN0IHN0eWxlPSdu dW1iZXJzJz4NCgkgIDx0Pg0KCSAgICBDaGFuZ2UgdGhlIG5hbWUgb2YgdGhlICJNdWx0aXBy b3RvY29sIExhYmVsIFN3aXRjaGluZw0KCSAgICBBcmNoaXRlY3R1cmUgKE1QTFMpIExhYmVs IFZhbHVlcyIgcmVnaXN0cnkgdG8gdGhlICJTcGVjaWFsDQoJICAgIFB1cnBvc2UgTVBMUyBM YWJlbCBWYWx1ZXMiLg0KCSAgPC90Pg0KCSAgPHQ+DQoJICAgIENoYW5nZSB0aGUgYWxsb2Nh dGlvbnMgcG9saWN5IGZvciB0aGUgIlNwZWNpYWwgUHVycG9zZSBNUExTDQoJICAgIExhYmVs IFZhbHVlcyIgcmVnaXN0cnkgdG8gU3RhbmRhcmRzIEFjdGlvbi4NCgkgIDwvdD4NCgkgIDx0 Pg0KCSAgICBOb3RlOiBhbnkgbmV3IGFsbG9jYXRpb24gZnJvbSB0aGUgU3BlY2lhbCBQdXJw b3NlIE1QTFMNCgkgICAgTGFiZWwgVmFsdWVzIHJlZ2lzdHJ5IE1VU1QgYmUgYWxzbyBzYXkg d2hldGhlciB0aGUgc2FtZQ0KCSAgICB2YWx1ZSBuZWVkcyB0byBiZSByZXNlcnZlZCBpbiB0 aGUgRXh0ZW5kZWQgU3BlY2lhbCBQdXJwb3NlDQoJICAgIE1QTFMgTGFiZWwgVmFsdWVzIHJl Z2lzdHJ5Lg0KCSAgPC90Pg0KCSAgPHQ+DQoJICAgIEFzc2lnbiBsYWJlbCAxNSBmcm9tIHRo ZSAiU3BlY2lhbCBQdXJwb3NlIE1QTFMgTGFiZWwgVmFsdWVzIg0KCSAgICByZWdpc3RyeSwg bmFtaW5nIGl0IHRoZSAiZXh0ZW5zaW9uIGxhYmVsIiwgYW5kIGNpdGluZyB0aGlzDQoJICAg IGRvY3VtZW50IGFzIHRoZSByZWZlcmVuY2UuDQoJICA8L3Q+DQoJICA8dD4NCgkgICAgQ3Jl YXRlIGEgbmV3IHJlZ2lzdHJ5IGNhbGxlZCB0aGUgIkV4dGVuZGVkIFNwZWNpYWwgUHVycG9z ZQ0KCSAgICBNUExTIExhYmVsIFZhbHVlcyIgcmVnaXN0cnkuICBUaGUgcmFuZ2VzIGFuZCBh bGxvY2F0aW9uDQoJICAgIHBvbGljaWVzIGZvciB0aGlzIHJlZ2lzdHJ5IGFyZSBhcyBmb2xs b3dzICh1c2luZw0KCSAgICB0ZXJtaW5vbG9neSBmcm9tIDx4cmVmIHRhcmdldD0nUkZDNTIy NicvPikuICBFYXJseQ0KCSAgICBhbGxvY2F0aW9uIGZvbGxvd2luZyB0aGUgcG9saWN5IGRl ZmluZWQgaW4gPHhyZWYNCgkgICAgdGFyZ2V0PSdSRkM0MDIwJy8+IGlzIGFsbG93ZWQgb25s eSBmb3IgdGhvc2UgdmFsdWVzDQoJICAgIGFzc2lnbmVkIGJ5IFN0YW5kYXJkcyBBY3Rpb24u DQoJICA8L3Q+DQoJPC9saXN0Pg0KICAgICAgPC90Pg0KICAgICAgPHRleHR0YWJsZSBhbmNo b3I9J2FsbG9jLXBvbCc+DQogICAgICAgIDx0dGNvbCBhbGlnbj0nbGVmdCcgd2lkdGg9JzMw JSc+UmFuZ2U8L3R0Y29sPg0KICAgICAgICA8dHRjb2wgYWxpZ249J2xlZnQnPkFsbG9jYXRp b24gUG9saWN5PC90dGNvbD4NCiAgICAgICAgPGM+MCwgMSwgMiwgMywgNywgMTMsIDE0LCAx NTwvYz4NCgk8Yz4NCgkgIFJlc2VydmVkLiAgTm90IHRvIGJlIGFsbG9jYXRlZC4NCgkgIE1l YW5pbmcgaXMgZGVmaW5lZCBieSB2YWx1ZXMgaW4gdGhlICJTcGVjaWFsDQoJICBQdXJwb3Nl IE1QTFMgTGFiZWwgVmFsdWVzIiByZWdpc3RyeS4NCgk8L2M+DQoJPGM+NCwgNSwgNiwgOCwg OSwgMTAsIDExLCAxMjwvYz4NCgk8Yz5TdGFuZGFyZHMgQWN0aW9uIChzZWUgTm90ZSk8L2M+ DQogICAgICAgIDxjPjE2IC0gMTA0ODU1OTwvYz4gPGM+U3RhbmRhcmRzIEFjdGlvbjwvYz4N CiAgICAgICAgPGM+MTA0ODU2MCAtIDEwNDg1NzU8L2M+IDxjPkV4cGVyaW1lbnRhbDwvYz4N CiAgICAgIDwvdGV4dHRhYmxlPg0KICAgIDwvc2VjdGlvbj4NCg0KICA8c2VjdGlvbiB0aXRs ZT0nU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMnPg0KICAgIDx0Pg0KICAgICAgVGhpcyBkb2N1 bWVudCBkb2VzIG5vdCBtYWtlIGEgbGFyZ2UgY2hhbmdlIHRvIHRoZSBvcGVyYXRpb24gb2YN CiAgICAgIHRoZSBNUExTIGRhdGEgcGxhbmUgYW5kIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25z IGFyZSBsYXJnZWx5DQogICAgICB1bmNoYW5nZWQgZnJvbSB0aG9zZSBzcGVjaWZpZWQgaW4g dGhlIE1QTFMgYXJjaGl0ZWN0dXJlIDx4cmVmDQogICAgICB0YXJnZXQ9J1JGQzMwMzEnLz4g YW5kIGluIHRoZSBNUExTIGFuZCBHTVBMUyBTZWN1cml0eSBGcmFtZXdvcmsNCiAgICAgIDx4 cmVmIHRhcmdldD0nUkZDNTkyMCcvPi4NCiAgICA8L3Q+DQogICAgPHQ+DQogICAgICBIb3dl dmVyLCBpdCBzaG91bGQgYmUgbm90ZWQgdGhhdCBpbmNyZWFzaW5nIHRoZSBsYWJlbCBzdGFj ayBjYW4NCiAgICAgIGNhdXNlIHBhY2tldCBmcmFnbWVudGF0aW9uIGFuZCBtYXkgYWxzbyBt YWtlIHBhY2tldHMNCiAgICAgIHVucHJvY2Vzc2FibGUgYnkgc29tZSBpbXBsZW1lbnRhdGlv bnMuICBUaGlzIGRvY3VtZW50IHByb3ZpZGVzIGENCiAgICAgIHByb3RvY29sLWxlZ2FsIHdh eSB0byBhcmJpdHJhcmlseSBpbmNyZWFzZSB0aGUgbGFiZWwgc3RhY2sgYW5kDQogICAgICBz byBtaWdodCBwcm92aWRlIGEgd2F5IHRvIGF0dGFjayBzb21lIG5vZGVzIGluIGEgbmV0d29y ayB3aXRob3V0DQogICAgICB2aW9sYXRpbmcgdGhlIHByb3RvY29sIHJ1bGVzLg0KICAgIDwv dD4NCiAgPC9zZWN0aW9uPg0KICA8L21pZGRsZT4NCg0KICA8YmFjaz4NCiAgICA8cmVmZXJl bmNlcyB0aXRsZT0nTm9ybWF0aXZlIFJlZmVyZW5jZXMnPg0KICAgICAgPD9yZmMgaW5jbHVk ZT0ncmVmZXJlbmNlLlJGQy4yMTE5Jz8+DQogICAgICA8P3JmYyBpbmNsdWRlPSdyZWZlcmVu Y2UuUkZDLjMwMzEnPz4NCiAgICAgIDw/cmZjIGluY2x1ZGU9J3JlZmVyZW5jZS5SRkMuMzAz Mic/Pg0KICAgICAgPD9yZmMgaW5jbHVkZT0ncmVmZXJlbmNlLlJGQy4zMDM4Jz8+DQogICAg ICA8P3JmYyBpbmNsdWRlPSdyZWZlcmVuY2UuUkZDLjMyMDknPz4NCiAgICAgIDw/cmZjIGlu Y2x1ZGU9J3JlZmVyZW5jZS5SRkMuMzgxMSc/Pg0KICAgICAgPD9yZmMgaW5jbHVkZT0ncmVm ZXJlbmNlLlJGQy40MDIwJz8+DQogICAgICA8P3JmYyBpbmNsdWRlPSdyZWZlcmVuY2UuUkZD LjQxODInPz4NCiAgICAgIDw/cmZjIGluY2x1ZGU9J3JlZmVyZW5jZS5SRkMuNDkyOCc/Pg0K ICAgICAgPD9yZmMgaW5jbHVkZT0ncmVmZXJlbmNlLlJGQy41MjI2Jz8+DQogICAgICA8P3Jm YyBpbmNsdWRlPSdyZWZlcmVuY2UuUkZDLjUzMzEnPz4NCiAgICAgIDw/cmZjIGluY2x1ZGU9 J3JlZmVyZW5jZS5SRkMuNTkyMCc/Pg0KICAgICAgPD9yZmMgaW5jbHVkZT0ncmVmZXJlbmNl LlJGQy41OTIxJz8+DQogICAgICA8P3JmYyBpbmNsdWRlPSdyZWZlcmVuY2UuUkZDLjU5NjAn Pz4NCiAgICAgIDw/cmZjIGluY2x1ZGU9J3JlZmVyZW5jZS5SRkMuNjM5MSc/Pg0KICAgICAg PD9yZmMgaW5jbHVkZT0ncmVmZXJlbmNlLlJGQy42NDc4Jz8+DQogICAgICA8P3JmYyBpbmNs dWRlPSdyZWZlcmVuY2UuUkZDLjY3OTAnPz4NCiAgICA8L3JlZmVyZW5jZXM+DQogICAgPHJl ZmVyZW5jZXMgdGl0bGU9J0luZm9ybWF0aW9uYWwgUmVmZXJlbmNlcyc+DQogICAgICA8P3Jm YyBpbmNsdWRlPSdyZWZlcmVuY2UuUkZDLjM0MjknPz4NCiAgICAgIDw/cmZjIGluY2x1ZGU9 J3JlZmVyZW5jZS5SRkMuNTU4Nic/Pg0KICAgIDwvcmVmZXJlbmNlcz4NCiAgPC9iYWNrPg0K DQo8L3JmYz4NCg0K --------------010605040109000904020601 Content-Type: text/plain; charset=windows-1252; name="Attached Message Part" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Attached Message Part" --------------010605040109000904020601 Content-Type: text/plain; charset=windows-1252; name="draft-kompella-mpls-special-purpose-labels-02.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-kompella-mpls-special-purpose-labels-02.txt" Network Working Group K. Kompella Internet-Draft Juniper Networks Updates: 3032, 3038, 3209, 3811, 4182, 4928, 5331, 5586, 592L. Andersson Intended status: Standards Track Huawei A. Farrel Juniper Networks 2012 Allocating and Retiring Special Purpose MPLS Labels Abstract Some MPLS labels have been allocated for specific purposes. A block of labels (0-15) has been set aside to this end, and are commonly called "reserved labels". They will be called "special purpose labels" in this document. As there are only 16 of these labels, caution is needed in the allocation of new special purpose labels, yet at the same time allow forward progress when one is called for. This memo defines some procedures to follow in the allocation and retirement of special purpose labels, as well as a method to extend the special purpose label space. Finally, this memo renames the IANA registry for these labels to "Special Purpose MPLS Label Values", and creates a new one called the "Extended Special Purpose MPLS Label Values" registry. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents Kompella, et al. Expires [Page 1] Internet-Draft Special Purpose MPLS Labels 2012 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Conventions used . . . . . . . . . . . . . . . . . . . . 3 2. Questions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Answers . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Extended Special Purpose MPLS Label Values . . . . . . . 4 3.2. Process for Retiring Special Purpose Labels . . . . . . . 5 4. Updated RFCs . . . . . . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 7.2. Informational References . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction The specification of the Label Stack Encoding for Multi-Protocol Label Switching (MPLS) [RFC3032] defined four special purpose label values (0 to 3), and set aside values 4 through 15 for future use. These labels have special significance in both the control and the data plane. Since then, three further values have been allocated (values 7, 13, and 14 in [RFC6790], [RFC5586] and [RFC3429], respectively), leaving nine unassigned values from the original space of sixteen. While the allocation of three out of the remaining twelve special purpose label values in the space of about 12 years is not in itself a cause for concern, the scarcity of special purpose labels is. Furthermore, many of the special purpose labels require special processing by forwarding hardware, changes to which are often expensive, and sometimes impossible. Thus, documenting a newly allocated special purpose label value is important. This memo outlines some of the issues in allocating and retiring special purpose label values, and defines mechanisms to address these. This memo also extends the space of special purpose labels. Kompella, et al. Expires [Page 2] Internet-Draft Special Purpose MPLS Labels 2012 1.1. Conventions used The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Questions In re-appraising MPLS special purpose labels, the following questions come to mind: 1. What allocation policies should be applied by IANA for the allocation of special purpose labels? Should Early Allocation [RFC4020] be allowed? Should there be labels for Experimental Use or Private Use [RFC5226]? 2. What documentation is required for special purpose labels allocated henceforth? 3. Should a special purpose label ever be retired? What criteria are relevant here? Can a retired special purpose label ever be re-allocated for a different purpose? What procedures and time frames are appropriate? 4. The special purpose label value of 3 (the "Implicit Null Label", [RFC3032]) is only used in signaling, never in the data plane. Could it (and should it) be used in the data plane? If so, how and for what purpose? 5. What is a feasible mechanism to extend the space of special purpose labels, should this become necessary? 3. Answers This section provides answers to the questions posed in the previous section. 1. a. Allocation of special purpose MPLS labels is via "Standards Action". b. The IANA registry will be renamed "Special Purpose MPLS Labels". c. Early allocation may be allowed on a case-by-case basis. Kompella, et al. Expires [Page 3] Internet-Draft Special Purpose MPLS Labels 2012 d. The current space of 16 special purpose labels is too small for setting aside value for experimental or private use. However, the extended special purpose labels registry created by this document has enough space, and this document defines a range for experimental use. 2. A Standards Track RFC must accompany a request for allocation of special purpose labels, as per [RFC5226]. 3. The retirement of a special purpose MPLS label value must follow a strict and well-documented process. This is necessary since we must avoid orphaning the use of this label value in existing deployments. This process is detailed in Section 3.2. 4. The use of the "implicit null label" (label 3) in the data plane may be allowed, subject to approval by the MPLS WG, and an accompanying Standards Track RFC that details the use of the label, and a discussion of possible sources of confusion between signaling and data plane, and mitigation thereof. 5. The special purpose label (the "extension" label) is to be set aside for the purpose of extending the space of special purpose labels. Further details are described in Section 3.1. A further question to be settled in this regard is whether a "regular" special purpose label retains its meaning if it follows the extension label; see Section 3.1. 3.1. Extended Special Purpose MPLS Label Values An extension label MUST be followed by another label L (and thus MUST have the bottom-of-stack bit clear). L MUST be interpreted as an "extended special purpose label" from a new registry created by this document (see Section 5). Whether or not L has the bottom-of-stack bit set depends on whether other labels follow L. Only L is interpreted as an extended special purpose label; labels following L are interpreted as normal. IANA is asked to set aside label value 15 as the extension label. The first 16 values of the extended special purpose label registry are duplicated from the pre-existing special purpose label registry. This includes the previously allocated values (0-3, 7, 13, and 14), the extension label value (15) allocated by this document, and the remaining unallocated values (4-6 and 8-12). Any of these values present as an extended special purpose label MUST be interpreted exactly as it would if it was presented as a special purpose label. In particular, an arbitrary string of consecutive extension labels is Kompella, et al. Expires [Page 4] Internet-Draft Special Purpose MPLS Labels 2012 legal, and semantically equivalent to a single extension label (note that this string of extension labels MUST be followed by an extended special purpose label that is not the extension label). 3.2. Process for Retiring Special Purpose Labels a. A label value that has been assigned from the "Special Purpose MPLS Label Values" may be deprecated by IETF consensus with review by the MPLS working group (or designated experts if the working group or a successor does not exist). An RFC with at least Informational status is required. The RFC will direct the IANA to mark the label value as "deprecated" in the registry, but will not release it at this stage. Deprecating means that no further specifications using the deprecated value will be documented. At the same time this is an indication to vendors not to include deprecated value in new implementations and to operators to avoid including it in new deployments. b. 12 months after the RFC deprecating the label value is published, an IETF-wide survey may be conducted to determine if the deprecated label value is still in use. If the survey indicates that the deprecated label value is in use, the survey may be repeated after a further 6 months. c. 24 months after the RFC that deprecated the label value was published and if the survey indicates that deprecated label value is not in use, publication may be requested of an IETF Standards Track Internet-Draft that retires the deprecated the label value. This document will request IANA to release the label value for for future use and assignment. 4. Updated RFCs The following RFCs contain references to the term "reserved labels": [RFC3032] ("MPLS Label Stack Encoding"), [RFC3038] ("VCID Notification for LDP"), [RFC3209] ("Extensions to RSVP for LSP Tunnels"), [RFC3811] ("MPLS TC MIB"), [RFC4182] ("Removing a Restriction on the use of MPLS"), [RFC4928] ("Avoiding ECMP Treatment in MPLS Networks"), [RFC5331], [RFC5586] ("G-ACh and GAL"), [RFC5921] ("MPLS Transport Profile Framework"), [RFC5960] ("MPLS-TP Data Plane Architecture"), [RFC6790] ("MPLS Entropy Labels"), [RFC6391] ("FAT- PW"), and [RFC6478] ("Pseudowire Status for Static Pseudowires"). All such references should be read as "special purpose labels". Kompella, et al. Expires [Page 5] Internet-Draft Special Purpose MPLS Labels 2012 5. IANA Considerations This document requests IANA to make the following changes and additions to its registration of MPLS Labels. 1. Change the name of the "Multiprotocol Label Switching Architecture (MPLS) Label Values" registry to the "Special Purpose MPLS Label Values". 2. Change the allocations policy for the "Special Purpose MPLS Label Values" registry to Standards Action. 3. Note: any new allocation from the Special Purpose MPLS Label Values registry MUST be also say whether the same value needs to be reserved in the Extended Special Purpose MPLS Label Values registry. 4. Assign label 15 from the "Special Purpose MPLS Label Values" registry, naming it the "extension label", and citing this document as the reference. 5. Create a new registry called the "Extended Special Purpose MPLS Label Values" registry. The ranges and allocation policies for this registry are as follows (using terminology from [RFC5226]). Early allocation following the policy defined in [RFC4020] is allowed only for those values assigned by Standards Action. +-----------------+-------------------------------------------------+ | Range | Allocation Policy | +-----------------+-------------------------------------------------+ | 0, 1, 2, 3, 7, | Reserved. Not to be allocated. Meaning is | | 13, 14, 15 | defined by values in the "Special Purpose MPLS | | | Label Values" registry. | | | | | 4, 5, 6, 8, 9, | Standards Action (see Note) | | 10, 11, 12 | | | | | | 16 - 1048559 | Standards Action | | | | | 1048560 - | Experimental | | 1048575 | | +-----------------+-------------------------------------------------+ Table 1 6. Security Considerations Kompella, et al. Expires [Page 6] Internet-Draft Special Purpose MPLS Labels 2012 This document does not make a large change to the operation of the MPLS data plane and security considerations are largely unchanged from those specified in the MPLS architecture [RFC3031] and in the MPLS and GMPLS Security Framework [RFC5920]. However, it should be noted that increasing the label stack can cause packet fragmentation and may also make packets unprocessable by some implementations. This document provides a protocol-legal way to arbitrarily increase the label stack and so might provide a way to attack some nodes in a network without violating the protocol rules. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001. [RFC3038] Nagami, K., Katsube, Y., Demizu, N., Esaki, H., and P. Doolan, "VCID Notification over ATM link for LDP", RFC 3038, January 2001. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC3811] Nadeau, T. and J. Cucchiara, "Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management", RFC 3811, June 2004. [RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of Standards Track Code Points", BCP 100, RFC 4020, February 2005. [RFC4182] Rosen, E., "Removing a Restriction on the use of MPLS Explicit NULL", RFC 4182, September 2005. [RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal Cost Multipath Treatment in MPLS Networks", BCP 128, RFC 4928, June 2007. Kompella, et al. Expires [Page 7] Internet-Draft Special Purpose MPLS Labels 2012 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream Label Assignment and Context-Specific Label Space", RFC 5331, August 2008. [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010. [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. Berger, "A Framework for MPLS in Transport Networks", RFC 5921, July 2010. [RFC5960] Frost, D., Bryant, S., and M. Bocci, "MPLS Transport Profile Data Plane Architecture", RFC 5960, August 2010. [RFC6391] Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan, J., and S. Amante, "Flow-Aware Transport of Pseudowires over an MPLS Packet Switched Network", RFC 6391, November 2011. [RFC6478] Martini, L., Swallow, G., Heron, G., and M. Bocci, "Pseudowire Status for Static Pseudowires", RFC 6478, May 2012. [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and L. Yong, "The Use of Entropy Labels in MPLS Forwarding", RFC 6790, November 2012. 7.2. Informational References [RFC3429] Ohta, H., "Assignment of the 'OAM Alert Label' for Multiprotocol Label Switching Architecture (MPLS) Operation and Maintenance (OAM) Functions", RFC 3429, November 2002. [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic Associated Channel", RFC 5586, June 2009. Authors' Addresses Kompella, et al. Expires [Page 8] Internet-Draft Special Purpose MPLS Labels 2012 Kireeti Kompella Juniper Networks 1133 Innovation Way Sunnyvale, CA 94089 US Email: kireeti.kompella@gmail.com Loa Andersson Huawei Email: loa@mail01.huawei.com Adrian Farrel Juniper Networks Email: adrian@olddog.co.uk Kompella, et al. Expires [Page 9] --------------010605040109000904020601 Content-Type: text/plain; charset=windows-1252; name="Attached Message Part" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Attached Message Part" --------------010605040109000904020601-- From abegen@cisco.com Tue Mar 19 08:54:53 2013 Return-Path: X-Original-To: xml2rfc-dev@ietfa.amsl.com Delivered-To: xml2rfc-dev@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76D0021F8D35 for ; Tue, 19 Mar 2013 08:54:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FVlyD+jmVNnM for ; Tue, 19 Mar 2013 08:54:52 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1904021F85ED for ; Tue, 19 Mar 2013 08:54:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=966; q=dns/txt; s=iport; t=1363708492; x=1364918092; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=iIMneuOddTUmb1KFGeqfn9nzfoO2app67ERtgvpQpMs=; b=RgNj1TXpKiF+TRji1dZ9GBaKwf3TZyhkGWhDSK47xZl//PjXRtqO5ZsL vh0tow3wGpJ8rYuqHq1jCHYPSph7SF7x4P5FzPIMc/8pZTodKlTCHXTTb oBAlvTjpwxXWyS7zysET2yWp1efTzvSI1YhLJuRggq2lNCbDcfmcKa8gQ U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8FAFKJSFGtJV2Z/2dsb2JhbABDhDSDJke8b2hvFm0HgiYBBCMRVwEiAgYgAgQwFQoIBBuIDAGhB45VgkCQGoEjjTqCZTJhA6JKhReDCoIo X-IronPort-AV: E=Sophos;i="4.84,872,1355097600"; d="scan'208";a="189122694" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP; 19 Mar 2013 15:54:51 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r2JFsp4s007462 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 19 Mar 2013 15:54:51 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Tue, 19 Mar 2013 10:54:51 -0500 From: "Ali C. Begen (abegen)" To: "xml2rfc-dev@ietf.org" Thread-Topic: boilerplate errors Thread-Index: AQHOJLoWRfcuNHBpr0G7u25ODtXGdg== Date: Tue, 19 Mar 2013 15:54:27 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.61.103.35] Content-Type: text/plain; charset="utf-8" Content-ID: <194E6C208050144F9099B8997A3B0F92@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 19 Mar 2013 08:56:26 -0700 Subject: [xml2rfc-dev] boilerplate errors X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion about particulars of xml2rfc development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 15:54:53 -0000 SSBhbSB0cnlpbmcgdG8gY29tcGlsZSBteSB4bWwgZmlsZSBhdDogaHR0cDovL3htbC5yZXNvdXJj ZS5vcmcvIChUaGUgZm9ybQ0Kb24gdGhlIHRvcCkNCg0KQnV0LCB0aGUgcmVzdWx0aW5nIGRyYWZ0 IGRvZXMgbm90IHBhc3MgdGhlIGlkbml0cyBjaGVjay4gUGFydGljdWxhcmx5LCBpdA0KdGVsbHMg bWUgdGhlIGZvbGxvd2luZzoNCg0KICAqKiBGb3VuZCBuZXcgSUVURiBUcnVzdCBQcm92aXNpb25z IG9mIDEyIFNlcCAyMDA5IGJvaWxlcnBsYXRlLCB3aGljaCBpcw0KICAgICBmaW5lLCBidXQgKmFs c28qIGZvdW5kIG9sZCBib2lsZXJwbGF0ZSBmcm9tIFJGQyAyMDI2LCBTZWN0aW9uIDEwLjREIG9u DQogICAgIGxpbmUgMjcuDQoNCg0KQXMgc3VnZ2VzdGVkLCBJIGFtIHVzaW5nIGlwcj0idHJ1c3Qy MDA5MDIiIChoYXZlIGJlZW4gZG9pbmcgc28gZm9yIHNldmVyYWwNCnllYXJzIGJ1dCBJIHN0YXJ0 ZWQgaGF2aW5nIHRoaXMgcHJvYmxlbSB3aXRoIHRoaXMgY29udmVydG9yIHNpbmNlIGxhc3QNCndl ZWspLg0KDQpJcyB0aGlzIHNvbWV0aGluZyBJIGFtIGRvaW5nIHdyb25nIG9yIGlzIGl0IGEgYnVn IGluIHRoZSBjb252ZXJ0ZXI/DQoNCldoZW4gSSB1c2UgdGhlIG9sZCBjb252ZXJ0ZXIsIGlkbml0 cyBkb2VzIG5vdCBjb21wbGFpbg0KKGh0dHA6Ly94bWwucmVzb3VyY2Uub3JnL29sZC5odG1sKQ0K DQpIZWxwPw0KLWFjYmVnZW4NCg0K From dwing@cisco.com Fri Mar 22 17:15:19 2013 Return-Path: X-Original-To: xml2rfc-dev@ietfa.amsl.com Delivered-To: xml2rfc-dev@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF1F321F9011 for ; Fri, 22 Mar 2013 17:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.399 X-Spam-Level: X-Spam-Status: No, score=-110.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5E0Ry-yv8Qj for ; Fri, 22 Mar 2013 17:15:19 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 63E2321F9009 for ; Fri, 22 Mar 2013 17:15:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=362; q=dns/txt; s=iport; t=1363997719; x=1365207319; h=from:content-transfer-encoding:subject:message-id:date: to:mime-version; bh=6CJ9qrXTRw4tEKMafaKpNou6lei/25VVGQ77wOC5AKY=; b=Gkecon1RpnkiAYfgf4d6ZwnwlbXWs/X0scDTzwHxtGftDTTYvRXwN4Z8 qnFaTsxS7yPqdp7B2AdvLaM3HPoe0kCgkvf9wmcdf/6LlZBxTQrISk6N1 ZbnkTjZ7TM/3jP2IIZ7uMGMDaPkU65FpRpviYtSyTeTI2qgihS564rihD g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQJAA/zTFGrRDoJ/2dsb2JhbABDh2q9cAQEgWoWdIJliiMNoQegdI1ygUOCSWEDiHeNbYEfj2WDKhw X-IronPort-AV: E=Sophos;i="4.84,895,1355097600"; d="scan'208";a="76472878" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 23 Mar 2013 00:15:19 +0000 Received: from sjc-vpn6-1343.cisco.com (sjc-vpn6-1343.cisco.com [10.21.125.63]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r2N0FIT0001391 for ; Sat, 23 Mar 2013 00:15:19 GMT From: Dan Wing Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <504B7A3A-1AD3-4DA8-8284-9B9A692040B0@cisco.com> Date: Fri, 22 Mar 2013 17:15:18 -0700 To: xml2rfc-dev@ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) X-Mailman-Approved-At: Fri, 22 Mar 2013 19:40:01 -0700 Subject: [xml2rfc-dev] private RFC, xml2rfc 2.4.1 X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion about particulars of xml2rfc development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 00:15:20 -0000 The directive which worked in xml2rfc 1.* is apparently ignored in 2.4.1. I don't see = a bug against this in = http://trac.tools.ietf.org/tools/xml2rfc/trac/report/1, and also didn't = see anything in the closed tickets. Is this a known bug, or is there a = new way to cause the Status and Copyright to be skipped? -d From wyaacov@gmail.com Thu Mar 28 14:16:46 2013 Return-Path: X-Original-To: xml2rfc-dev@ietfa.amsl.com Delivered-To: xml2rfc-dev@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 429EB21F905F for ; Thu, 28 Mar 2013 14:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aCHu8lP5sJU3 for ; Thu, 28 Mar 2013 14:16:45 -0700 (PDT) Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) by ietfa.amsl.com (Postfix) with ESMTP id 886BE21F8FD1 for ; Thu, 28 Mar 2013 14:16:43 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id y10so1974702wgg.14 for ; Thu, 28 Mar 2013 14:16:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=ZGesgSlAJq2InXBwUZFRadMFdjWmv8wD9qU5gUITG+I=; b=W9gRLdtJOg1DGWluJ+5Wpb6qCuvDaldnSR6h8HM1cigDauFV8nxjhhnwz2I6cuB2Fr Zio0EMIa0LjBQZeU8/SgRxt+xB1wYk6B+Z0r+gWfz93IExEFzhYXMFY5Ki1Eru3xyriD oN6B6DbgGAVwKmIjIQJO4kIoC+EkY/0rulU+iKzoKIH/PhMTx/kmqXW5KzIa3HgD7ci1 2m0Odb6fCNd3FhQdQLEiWgfmOKisnJSWbLWXUu4Hz2C7jfKqmlx4I2xTiyrKNT+aXwFG kceoHz28Xt2qxCj3g2FEKrV7J9ZRE9LLTRdXqW8MflsxLLvpnIoD9IGE65h2Kh1QVGQc JO7g== MIME-Version: 1.0 X-Received: by 10.194.10.129 with SMTP id i1mr183475wjb.21.1364505402670; Thu, 28 Mar 2013 14:16:42 -0700 (PDT) Received: by 10.194.13.104 with HTTP; Thu, 28 Mar 2013 14:16:42 -0700 (PDT) Date: Thu, 28 Mar 2013 23:16:42 +0200 Message-ID: From: Yaacov Weingarten To: xml2rfc-dev@ietf.org Content-Type: multipart/alternative; boundary=047d7b5d5bd8d208d804d902abff X-Mailman-Approved-At: Fri, 29 Mar 2013 02:36:28 -0700 Subject: [xml2rfc-dev] Problem with new xml2rfc version X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion about particulars of xml2rfc development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 21:16:46 -0000 --047d7b5d5bd8d208d804d902abff Content-Type: text/plain; charset=ISO-8859-1 Hi, I just translated an I-D using the latest xml2rfc page based on the latest version and encountered the following problem: I used the "—" constant in my XML file in a few places [and "&ndash" in others]. While &ndash was translated correctly to a short '-' character, &mdash was translated to the string "-\u002D"! Is this an intended behavior? (please note that I am not currently subscribed to the mailing list - so I would appreciate being copied on any replies to this message) -- Thanx and BR, yaacov *Still looking for new opportunity* --047d7b5d5bd8d208d804d902abff Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

I just translated an I-D using the = latest xml2rfc page based on the latest version and encountered the followi= ng problem:

I used the "&mdash;" con= stant in my XML file in a few places [and "&ndash" in others]= . While &ndash was translated correctly to a short '-' characte= r, &mdash was translated to the string "-\u002D"!

Is this an intended behavior? (please note that I am no= t currently subscribed to the mailing list - so I would appreciate being co= pied on any replies to this message)

--
Thanx and BR,
yaacov

Still= looking for new opportunity
--047d7b5d5bd8d208d804d902abff-- From wyaacov@gmail.com Thu Mar 28 14:36:02 2013 Return-Path: X-Original-To: xml2rfc-dev@ietfa.amsl.com Delivered-To: xml2rfc-dev@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7309221F8E9E for ; Thu, 28 Mar 2013 14:36:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e98t8FS175gs for ; Thu, 28 Mar 2013 14:36:02 -0700 (PDT) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id C3B3B21F8E84 for ; Thu, 28 Mar 2013 14:36:01 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id r5so5670871wey.39 for ; Thu, 28 Mar 2013 14:36:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=xUnRj65o2IIVmWovapjqkZB1hKpje3/Q3OEjGwb2nZA=; b=A8cKHDXgYN8RHk/hxHjDgSHa851fUhCaX8EeI3Uf3DkOHI6TDUDqi0QBCnQklq0gQE xwmMp3UBiTc5W3fsqI3jksbaXVNGxrv7WB+FKu6o5tFkz5bSQY2kvjg7HtcFHys0pyp2 vShHD3zkZ4hyKzeQasf7zULO1zkHM9q3NvFzsw84ZUwvr4q1CxZBFgyvJ/+/KqnopaWY H3+Mdv/kmykZLA2whD6JMXpGH+T2j7nEzi+iLhRryhh6OpYb7AcOBOfSI6gt2aBPSXHM EylNEofGfqy4Na9zElIf9USyCio8UNUUXqFnXmx4vY9j19tGAnPFflFJGdK3mNuDsNas MYUw== MIME-Version: 1.0 X-Received: by 10.194.10.129 with SMTP id i1mr254992wjb.21.1364506560813; Thu, 28 Mar 2013 14:36:00 -0700 (PDT) Received: by 10.194.13.104 with HTTP; Thu, 28 Mar 2013 14:36:00 -0700 (PDT) Date: Thu, 28 Mar 2013 23:36:00 +0200 Message-ID: From: Yaacov Weingarten To: xml2rfc-dev@ietf.org Content-Type: multipart/alternative; boundary=047d7b5d5bd8d9dfdd04d902f0c0 X-Mailman-Approved-At: Fri, 29 Mar 2013 02:36:28 -0700 Subject: [xml2rfc-dev] Problem with texttables X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion about particulars of xml2rfc development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 21:36:02 -0000 --047d7b5d5bd8d9dfdd04d902f0c0 Content-Type: text/plain; charset=ISO-8859-1 Hi, In continuation to my previous message - there was an additional "problem" that I encountered in translating my XML file: I used two tables that defined a "width" for the columns using a percentage. While this worked fairly well with the previous version, the new version seemed to ignore the percentages and just create columns based on the size for the text. In addition, the new version seems to leave more empty lines after a texttable. As before, I would note that I am not subscribed to the list and would appreciate being copied on any responses to the message. -- Thanx and BR, yaacov *Still looking for new opportunity* --047d7b5d5bd8d9dfdd04d902f0c0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

In continuation to my previous mess= age - there was an additional "problem" that I encountered in tra= nslating my XML file:=A0
I used two tables that defined a "w= idth" for the columns using a percentage. =A0While this worked fairly = well with the previous version, the new version seemed to ignore the percen= tages and just create columns based on the size for the text.
In addition, the new version seems to leave more empty lines after a t= exttable.

As before, I would note that I am not su= bscribed to the list and would appreciate being copied on any responses to = the message.

--
Thanx and BR,
yaacov
<= br>
Still looking for new opportunity
--047d7b5d5bd8d9dfdd04d902f0c0--