From thomas.morin@orange.com Tue Apr 3 07:57:03 2012 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D76EE11E80A6; Tue, 3 Apr 2012 07:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] 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 FhNEDXw7gRvs; Tue, 3 Apr 2012 07:57:02 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id C426411E809D; Tue, 3 Apr 2012 07:57:01 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E7CC4E302B6; Tue, 3 Apr 2012 16:58:38 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id DE596E30290; Tue, 3 Apr 2012 16:58:38 +0200 (CEST) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 16:57:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from 10.193.21.179 ([10.193.21.179]) by ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) via Exchange Front-End Server owa.rd.francetelecom.fr ([10.192.128.53]) with Microsoft Exchange Server HTTP-DAV ; Tue, 3 Apr 2012 14:56:59 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Organization: France Telecom Orange User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 Content-class: urn:content-classes:message Date: Tue, 3 Apr 2012 16:57:29 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RtgDir review: draft-ietf-netmod-routing-cfg Thread-Index: Ac0RqgVn6yk6dPPtT+u0hJkdRctO1A== References: From: To: , , , X-OriginalArrivalTime: 03 Apr 2012 14:57:00.0260 (UTC) FILETIME=[05C63240:01CD11AA] Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-netmod-routing-cfg X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 14:57:04 -0000 SGkgTGFkaXNsYXYsDQoNCihhIGZldyBjb21tZW50cyBiZWxvdykNCg0KMjAxMi0wMy0yMywgTGFk aXNsYXYgTGhvdGthOg0KPj4NCj4+IEl0IGlzIGFsc28gaW1wb3J0YW50IHRvIG5vdGUgdGhhdCB0 aGUgdXNlZnVsbmVzcyBvZiB0aGVzZSBzcGVjcyBpcw0KPj4gY29uZGl0aW9uZWQgKGEpIGJ5IHRo ZSBkZXZlbG9wbWVudCBvZiBZYW5nIG1vZHVsZXMgZm9yIGVhY2gNCj4+IHJlbGV2YW50IHJvdXRp bmcgcHJvdG9jb2wgKHdoaWNoIHNob3VsZCBiZSBmYWlybHkgZG9hYmxlIGFzc3VtaW5nDQo+PiB0 aGlzIGJhc2UgbW9kdWxlIGlzIGdlbmVyaWMgZW5vdWdoKSBhbmQgKGIpIGNvbmRpdGlvbmVkIGJ5 IHRoZQ0KPj4gZGV2ZWxvcG1lbnQgb2YgYWRkaXRpb25hbCBZYW5nIG1vZHVsZXMgYWxsb3dpbmcg dGhlIGRlc2NyaXB0aW9uIG9mDQo+PiBub24tdHJpdmlhbCBpbXBvcnQvZXhwb3J0IGZpbHRlcnMg YmV0d2VlbiByb3V0aW5nIHByb3RvY29scyBhbmQNCj4+IHJvdXRpbmcgdGFibGVzICh0aGlzIHBh cnQgYmVpbmcgcG9zc2libHkgaGFyZGVyIHRvIGFjaGlldmUsIHNpbmNlDQo+PiBpdCBtZWFucyBm aW5kaW5nIGEgY29tbW9uIGxhbmd1YWdlIGFibGUgdG8gZXhwcmVzcyB0aGUgdmFyaWV0eSBvZg0K Pj4gQUNMcy9wb2xpY2llcyB0aGF0IGNhbiBiZSBleHByZXNzZWQgb24gZGlmZmVyZW50IHJvdXRl ciBPU2VzDQo+PiB0b2RheSkuDQo+DQo+IEFic29sdXRlbHkuIFRoaXMgaXMgYSB1c3VhbCBkaWxl bW1hOiB3ZSBjYW4gZWl0aGVyIHRyeSB0byBkZXZlbG9wIGENCj4gZnVsbC1mbGVkZ2VkIHJvdXRl IGZpbHRlcmluZyBmcmFtZXdvcmsgYW5kIGV4cGVjdC9mb3JjZSBldmVyeWJvZHkgdG8NCj4gdXNl IGl0LCBvciBvcGVuIHRoZSBzcGFjZSBmb3IgbXVsdGlwbGUgY29tcGV0aW5nIGZyYW1ld29ya3Mu IFRoZQ0KPiBkcmFmdCBhbmQgdGhlIHJvdXRpbmcgbW9kdWxlIHRha2UgdGhlIGxhdHRlciBhcHBy b2FjaCwgYmVjYXVzZSB0aGUNCj4gbG9naWNzIG9mIGV4aXN0aW5nIGltcGxlbWVudGF0aW9ucyBk aWZmZXIgZnJvbSBlYWNoIG90aGVyDQo+IGNvbnNpZGVyYWJseSwgc28gaXQgaXMgbm90IHZlcnkg bGlrZWx5IHRvIGZpbmQgdGhlaXIgY29tbW9uDQo+IGRlbm9taW5hdG9yLiBJIHBsYW4gdG8gaW1w bGVtZW50IHRoZSByb3V0ZSBmaWx0ZXJpbmcgZnJhbWV3b3JrIG9mIHRoZQ0KPiBCSVJEIHJvdXRp bmcgZGFlbW9uIHdoaWNoIGl0IGlzIG1haW50YWluZWQgYnkgbXkgY29tcGFueS4NCg0KSXQgd291 bGQgYmUgbmljZSB0byBzZWUgbW9yZSB2ZW5kb3JzIGpvaW4gYW5kIHByb3Bvc2UgWWFuZyBtb2R1 bGVzIGZvciANCmZpbHRlcmluZy9yZWRpc3RyaWJ1dGlvbiA7IGV2ZW4gaWYgcmVzdHJpY3RlZCB0 byB0aGVpciBvd24gZmlsdGVyaW5nIA0Kc2VtYW50aWNzLCB0aGF0IHdvdWxkIGJlIGEgc3RhcnQu DQoNCg0KDQoNCj4+IENvbW1lbnRzOg0KPj4NCj4+IC0tLSBOb3RlIFdlbGwgLi4uDQo+Pg0KPj4g SSdtIGhvcGluZyB0aGlzIHJldmlldyB3aWxsIGJlIHJlbGV2YW50IGFuZCB1c2VmdWwuIEJ1dCwg a2VlcGluZyBpbg0KPj4gbWluZCB0aGF0IGRvaW5nIHRoaXMgcmV2aWV3IHdhcyBteSBmaXJzdCBl eHBvc3VyZSBhdCBZYW5nLCBzb21lDQo+PiBjb21tZW50cyBJJ20gbWFraW5nIGNvdWxkIHBvc3Np Ymx5IGJlIGNvbXBsZXRlbHkgb2ZmIHRyYWNrLCBhbmQNCj4+IHdoYXQgSSB0aGluayBJIHVuZGVy c3Rvb2QgY291bGQgYXMgd2VsbCBiZSwgcGFydGx5IG9yIGZ1bGx5LCB3cm9uZy4NCj4+IElmL3do ZW4gdGhpcyBoYXBwZW5zIHRvIGJlIHRoZSBjYXNlLCBJIGFwb2xvZ2l6ZTsganVzdCBiZSBmcmFu ayBhbmQNCj4+IGhvbmVzdCBhbmQgZXZlbnR1YWxseSB0ZWxsIG1lIHRvIGdvIGJhY2sgaG9tZSBh bmQgcmVhZCBhIGZldyBvdGhlcg0KPj4gc3BlY3MgYmVmb3JlIEkgY29tZSBiYWNrLi4uIDstKQ0K Pg0KPiBObywgSSBkb24ndCB0aGluayBpdCBpcyBuZWNlc3NhcnkuIDpeKSBBbmR5IEJpZXJtYW4g b25jZSBkZXNjcmliZWQNCj4gdGhlIHByb2JsZW0gd2UgYXJlIGZhY2luZyBoZXJlOg0KPg0KPiAi VGhlIGRvbWFpbiBleHBlcnRzIGRvbid0IHJlYWxseSBrbm93IHRoZSBkYXRhIG1vZGVsaW5nIHN0 dWZmLCBhbmQNCj4gdGhlIGRhdGEgbW9kZWxpbmcgZXhwZXJ0cyBkb24ndCByZWFsbHkga25vdyB0 aGUgZG9tYWluIHN0dWZmLiINCj4NCj4gSSBjZXJ0YWlubHkgaG9wZSB3ZSBjYW4gb2J0YWluIHNv dW5kIHJlc3VsdHMgdGhyb3VnaCBjb29wZXJhdGlvbg0KPiBiZXR3ZWVuIGJvdGggY2xhc3NlcyBv ZiBleHBlcnRzLg0KDQoNCjstKQ0KDQoNCj4NCj4+DQo+PiBUaGVyZSB3YXMgb25lIHNwZWNpZmlj IGRpZmZpY3VsdHkgZm9yIGRvaW5nIHRoaXMgcmV2aWV3OiBmb3INCj4+IHNvbWVvbmUgbGFja2lu ZyBYUGF0aCBmbHVlbmN5LCBpdCBpcyBoYXJkIHRvIHVuZGVyc3RhbmQgc29tZQ0KPj4gZGV0YWls cyBvZiB0aGUgWWFuZCBtb2R1bGVzLiBGb3IgaW5zdGFuY2UsIHRoZXJlIGlzIGEgY29tcGxleA0K Pj4gY29uZGl0aW9uIGZvciByb3V0aW5nLXByb3RvY29sL2Nvbm5lY3RlZC1yb3V0aW5nLXRhYmxl cywgYW5kIGl0DQo+PiB3b3VsZCBoYXZlIHJlbWFpbmVkIHRvdGFsbHkgb2JzY3VyZSB0byBtZSB3 aXRob3V0IHRoZSBlcnJvci1tZXNzYWdlDQo+PiB0aGF0IGlzIGFsc28gcHJvdmlkZWQgOyB0aGUg Y29ycmVzcG9uZGluZyBjb25zdHJhaW50IHdhcyBhbHNvDQo+PiBleHBsYWluZWQgaW4gdGhlIElu dHJvIG9mIHNlY3Rpb24gNCwgc28gdGhpcyBwYXJ0aWN1bGFyIGNhc2Ugd2FzIG9rDQo+PiAoc2Vl IG1vcmUgcHJlY2lzZSBjb21tZW50IGJlbG93KS4gQmV5b25kIHRoaXMgZXhhbXBsZSwgdGhlIHJl YWwNCj4+IGlzc3VlIGlzIHRoYXQgSSBjYW4ndCBrbm93IGlmIHRoZXJlIGlzIGFueSBvdGhlciBz aW1pbGFyIFhQYXRoDQo+PiBjb25zdHJhaW50IG9yIG90aGVyIGRldGFpbCB0aGF0IEkgbWlnaHQg aGF2ZSBtaXNzZWQuDQo+Pg0KPg0KPiBSRkMgNjA4NyByZXF1aXJlcyBhbGwgU3RhbmRhcmRzIFRy YWNrIG1vZHVsZXMgdG8gZGVzY3JpYmUgdGhlIHB1cnBvc2UNCj4gb2YgYWxsICdtdXN0JyBzdGF0 ZW1lbnRzIGluICdkZXNjcmlwdGlvbicuIEFjdHVhbGx5LCBzdWNoIGENCj4gZGVzY3JpcHRpb24g b2Z0ZW4gc2VlbXMgc3VwZXJmbHVvdXMgaWYgdGhlcmUgaXMgYW4gJ2Vycm9yLW1lc3NhZ2UnDQo+ IHN0YXRlbWVudC4NCg0KRWl0aGVyIHdheSwgaXQncyBzYW5lIHRvIGhhdmUgc29tZSB0ZXh0dWFs IGRlc2NyaXB0aW9uLg0KDQo+IEF0IGFueSByYXRlLCB0aGUgcHVycG9zZSBvZiBzdWNoIHN0YXRl bWVudCBzaG91bGQgYmUgcmVhc29uYWJseSBjbGVhcg0KPiBldmVuIHdpdGhvdXQgZGVjaXBoZXJp bmcgdGhlIFhQYXRoIGV4cHJlc3Npb25zLiBQbGVhc2UgbGV0IG1lIGtub3cgaWYNCj4gaXQgaXMg bm90IHRoZSBjYXNlIGFuZCBJIHdpbGwgdHJ5IHRvIGltcHJvdmUgdGhlIGRlc2NyaXB0aW9ucyBh bmQvb3INCj4gZXJyb3IgbWVzc2FnZXMuDQoNCkkgZGlkIG5vdCBkbyBhIGZ1bGwgcmV2aWV3IG9u IHRoaXMgYXNwZWN0IHlldCwgYnV0IGlmIHlvdSBkbyBpbmRlZWQgDQphcHBseSB0aGUgcnVsZSBh Ym92ZSwgdGhlbiBJIGV4cGVjdCB0aGlzIHdpbGwgYmUgZ29vZCBlbm91Z2guDQoNCg0KDQo+Pg0K Pj4gLS0gRG9jdW1lbnQgb3JnYW5pemF0aW9uDQo+Pg0KPj4gVGhlIGludGVyZmFjZSBwYXJhbWV0 ZXJzIGZvciBJUHY2IE5laWdoYm9yIERpc2NvdmVyeSB3b3VsZCBJIHRoaW5rDQo+PiBkZXNlcnZl IGJlaW5nIG1vdmVkIGluIGEgY29tcGFuaW9uIFlhbmcgbW9kdWxlLCB1bmxlc3MgdGhlcmUgaXMg YQ0KPj4gc3Ryb25nIHJlYXNvbiAoc3VjaCBhcyBhIGRlcGVuZGVuY3kpIHdoeSBpdCB3b3VsZCBi ZSBuZWVkZWQgdG8gYmUNCj4+IGtlcHQgaGVyZS4NCj4NCj4gT3RoZXIgSVB2NiBORCBwYXJhbWV0 ZXJzIGFyZSBkZWZpbmVkIGJ5IHRoZSAiaWV0Zi1pcCIgbW9kdWxlLiBJdCBtYXkNCj4gaW5kZWVk IGJlIHdvcnRoIHJlY29uc2lkZXJpbmcgdGhlIHN0cnVjdHVyZSBvZiB0aGUgImNvcmUiIG1vZHVs ZXMuDQoNCkFncmVlZC4NCg0KDQoNCg0KDQoNCg0KPg0KPj4NCj4+DQo+PiAtLS0gIEluZm9ybWF0 aW9uIG9uIHJvdXRlcw0KPj4NCj4+IFRoZSBZYW5nIG1vZHVsZSBsZXQncyB0aGUgb3BlcmF0b3Ig cmVhZCB0aGUgcm91dGluZyB0YWJsZXMuIEl0DQo+PiBsb29rcyBsaWtlIGEgdmVyeSB2YWxpZCBh bmQgdXNlZnVsIHRoaW5nIChhbmQgbm90IG5ldywgc2VlIFJGQzEyMTMNCj4+IE1JQikuDQo+Pg0K Pj4gSG93ZXZlciwgSSdtIHdvbmRlcmluZyBhYm91dCB0aGUgZm9sbG93aW5nIHBvaW50czoNCj4+ DQo+PiAtIHVzdWFsbHksIGEgcm91dGluZyB0YWJsZSBtYXkgaGF2ZSBtdWx0aXBsZSByb3V0ZXMg Zm9yIGEgc2FpZA0KPj4gZGVzdGluYXRpb24gYWRkcmVzcywgc29tZSBiZWluZyBwb3NzaWJseSBs ZXNzIHNwZWNpZmljIHRoYW4gb3RoZXJzLA0KPj4gb3IgaW5hY3RpdmUgZHVlIHRvIHZhcmlvdXMg cmVhc29ucyA6IGl0IGRpZCBub3QgaWRlbnRpZnkgaG93IHRoZXNlDQo+PiBzcGVjaWZpY2F0aW9u IGFsbG93IHRoZSBvcGVyYXRvciB0byBzZWUgYWxsIHJvdXRlcyBvZiBhIHJvdXRpbmcNCj4+IHRh YmxlIGZvciBhIHNhaWQgcHJlZml4LCBvciBhbGwgdGhlIG1vc3Qgc3BlY2lmaWMgcm91dGVzIGlu Y2x1ZGluZw0KPj4gdGhlIGluYWN0aXZlIG9uZXMsIG9yIGFsbCB0aGUgbW9zdCBzcGVjaWZpYyBh Y3RpdmVzIHJvdXRlcyB3aGVuDQo+PiB0aGVyZSBpcyBtb3JlIHRoYW4gb25lIChyZXF1aXJlZCBJ IHRoaW5rIGZvciBFQ01QIHN1cHBvcnQpLCBldGMuID8NCj4+IGl0IHNlZW1zIGl0IHdvdWxkIGJl IHdvcnRoIHRvIGV4dGVuZCB0aGUgZ2V0LXJvdXRlIFJQQyB0byBhbGxvdw0KPj4gZXhwcmVzc2lu ZyBhbGwgdGhlc2Uga2luZCBvZiBxdWVzdGlvbnMNCj4NCj4gVGhlICdnZXQtcm91dGUnIG1ldGhv ZCBkb2Vzbid0IHRyeSB0byBiZSB0ZXJyaWJseSBnZW5lcmFsIG9yDQo+IGV4dGVuc2libGUsIGl0 IGlzIG1haW5seSBpbnRlbmRlZCBhcyBhIHJlbWluZGVyIHRvIHJvdXRpbmcgZXhwZXJ0cw0KPiB0 aGF0IFlBTkcgYWxzbyBhbGxvd3MgZm9yIGRlZmluaW5nIG5ldyBSUEMgbWV0aG9kcy4gSSB0aGlu ayBpdCB3aWxsDQo+IGJlIGVhc2llciB0byBkZWNpZGUgd2hhdCBtZXRob2RzIGFyZSBuZWVkZWQg YXMgc29vbiBhcyB0aGVyZSBhcmUgZGF0YQ0KPiBtb2RlbHMgZm9yIHRoZSBtYWpvciByb3V0aW5n IHByb3RvY29scywgc3VjaCBhcyBPU1BGIG9yIEJHUC4NCg0KWW91IG1pZ2h0IHdhbnQgdG8gZmlu ZCBhIGJhbGFuY2UgYmV0d2VlbiBkb2luZyB0aGluZ3MgaW4gdGhlc2UgDQpzcGVjaWZpY2F0aW9u cyBhbmQgcHVudGluZyB0byBmdXR1cmUgd29yayBhbmQgbmV3IGV4dGVuc2lvbnMuDQoNCkl0IHNl ZW1zIHRvIG1lIHRoYXQsIGF0IHRoZSB2ZXJ5IGxlYXN0LCB0aGUgZ2V0LXJwYyBzaG91bGQgYWxs b3cgdG8gDQpyZXR1cm4gbW9yZSB0aGFuIG9uZSByb3V0ZSAoYWxsIGFjdGl2ZSBvbmVzKSBzbyBh cyB0byBiZSBjb21wYXRpYmxlIHdpdGggDQpFQ01QLiAgRmlsdGVyaW5nIGJldHdlZW4gYWN0aXZl IGFuZCBpbmFjdGl2ZSByb3V0ZXMgd291bGQgYmUgSSB0aGluayANCmZhaXJseSBnZW5lcmljIGFu ZCByZWxldmFudCB0byBhZGQgaW4gdGhlc2Ugc3BlY3MuDQoNCg0KDQo+PiAtIGFzc3VtaW5nIHRo YXQgaW4gc29tZSBjYXNlcyBkdW1waW5nIHdob2xlIHJvdXRpbmcgdGFibGVzIHdvdWxkDQo+PiBu b3QgYmUgZWZmaWNpZW50LCB3aWxsIHRoZXJlIGJlIGFuIGVmZmljaWVudCB3YXkgdG8gZ2V0IGFn Z3JlZ2F0ZQ0KPj4gaW5mb3JtYXRpb24gb24gYSByb3V0aW5nIHRhYmxlIDsgc3VjaCBhcyAiaG93 IG1hbnkgcm91dGVzIGluIHRoZQ0KPj4gcm91dGluZyB0YWJsZSIgPyBvciAiaG93IG1hbnkgaW5h Y3RpdmUgcm91dGVzIGluIHRoZSByb3V0aW5nIHRhYmxlIg0KPj4gPyAgImhvdyBtYW55IHJvdXRl cyBmb3IgcHJlZml4IHgueS56IiA/DQo+DQo+IFl1cCwgdGhpcyBzb3VuZHMgbGlrZSBhIHVzZWZ1 bCB0aGluZyB0byBoYXZlLiBQZXJoYXBzIGl0IG1pZ2h0IG1ha2UNCj4gc2Vuc2UgdG8gYWxzbyBo YXZlIGEgZ2VuZXJpYyBSUEMgcmV0dXJuaW5nIHRoZSBudW1iZXIgb2YgZW50cmllcyBpbiBhDQo+ IGxpc3Qgb3IgbGVhZi1saXN0Lg0KDQpBZ3JlZWQuDQoNCg0KPj4gLSB0aGUgdGVybSAiZGVzdGlu YXRpb24tYWRkcmVzcyIgY2hvc2VuIHRvIGRlc2lnbmF0ZSB0aGUgcGllY2Ugb2YNCj4+IGluZm9y bWF0aW9uIGJhc2VkIG9uIHdoaWNoIHRoZSBnZXQtcm91dGUgUlBDIHdvcmtzLCBpcyBwb3NzaWJs eSBub3QNCj4+IHN1aXRhYmxlIGZvciBhbGwgcm91dGluZyBwcm90b2NvbHMuIFRoZSBleGFtcGxl cyB0aGF0IEkgd291bGQgc2VlDQo+PiBhcmUgKGEpIE1QLUJHUCwgd2hlcmUgdGhlIHJvdXRpbmcg aW5mb3JtYXRpb24gKE5MUkkpIGNhbiBiZSBtb3N0bHkNCj4+IGFueXRoaW5nIChkZXBlbmRzIG9u IHRoZSBTQUZJKSwgYW5kIChiKSBtdWx0aWNhc3QsIHdoZXJlIHRoZQ0KPj4gcm91dGluZyBpbmZv cm1hdGlvbiBvbiB3aGljaCB0aGUgUElNIHByb3RvY29scyB3b3JrIGNhbiBiZSBhDQo+PiAoc291 cmNlLGdyb3VwKSB0dXBsZSwgcG9zc2libHkgYXVnbWVudGVkIHdpdGggZmxhZ3MNCj4NCj4gWWVz LCBzZWUgYWJvdmUuIERvIHlvdSBoYXZlIGFuIGlkZWEgaG93IHRvIGRlZmluZSBhIGdlbmVyYWwg bWV0aG9kDQo+IHdpdGhvdXQgaGF2aW5nIHRoZSBkYXRhIG1vZGVscyBmb3IgTVAtQkdQIG9yIG11 bHRpY2FzdCByb3V0aW5nPw0KDQpXZWxsLCB0aGUgYWJvdmUgY29tbWVudCB3YXMgbW9yZSBhYm91 dCB0aGUgdGVybSBjaG9zZW4gdGhhbiBhYm91dCBkYXRhIA0KbW9kZWxpbmcuIFdoeSBub3QganVz dCBjYWxsICJtYXRjaC1kYXRhIiB0aGUgcGllY2Ugb2YgaW5mb3JtYXRpb24gaW4gdGhlIA0Kcm91 dGVzIG9uIHdoaWNoIHRoZSBnZXQtcnBjIHdpbGwgdHJ5IHRvIG1hdGNoID8NCg0KDQo+PiAtIChy ZWxhdGVkIHRvIHRoZSBwcmV2aW91cyBwb2ludDopIDogSSdtIHVuY2xlYXIgaWYgdGhlc2Ugc3Bl Y3MNCj4+IGFsbG93IGEgZ2V0LXJvdXRlIHRvIG1hdGNoIG9uIGRpZmZlcmVudCBwb3J0aW9ucyBv ciBhdHRyaWJ1dGVzIG9mIGENCj4+IHJvdXRlcyAgKGVnLiBnZXQgcm91dGUgZm9yIHByZWZpeCBY IGFkdmVydGlzZWQgYnkgcGVlciBYLCBvciBoYXZpbmcNCj4+IGJlZW4gcmVhZHZlcnRpc2VkIGJ5 IEFTIFkuLi4pLi4uIEFzIEkgdW5kZXJzdGFuZCwgdGhlcmUgY2FuIGJlIHNvbWUNCj4+IEFGTi9T QUZJIHNwZWNpZmljIGV4dGVuc2lvbnMsIGJ1dCBubyBwZXItcHJvdG9jb2wgZXh0ZW5zaW9ucy4g SXMNCj4+IHRoaXMgYSBjb3JyZWN0IHVuZGVyc3RhbmRpbmcgPyBJZiBub3QsIHdvdWxkbid0IGl0 IG1ha2Ugc2Vuc2UgdG8NCj4+IG1ha2UgaXQgbW9yZSBleHRlbnNpYmxlID8NCj4NCj4gVGhlcmUg Y2FuIGJlIHBlci1wcm90b2NvbCBleHRlbnNpb25zLCB0b28sIGl0IGlzIGFsc28gZGVtb25zdHJh dGVkIGluDQo+IHRoZSBSSVAgZXhhbXBsZS4NCg0KDQpJIHVuZGVyc3RhbmQgaG93IHRoZSBSSVAg ZXhhbXBsZSBkb2VzIGV4dGVuZCB0aGUgaW5mb3JtYXRpb24gKnJldHVybmVkKiANCmJ5IGdldC1y b3V0ZS4gQnV0IEkgZG9uJ3QgZ2V0IGhvdyBhIHByb3RvY29sIGNhbiBleHRlbmQgdGhlIGluZm9y bWF0aW9uIA0Kb24gd2hpY2ggZ2V0LXJwYyBtYXRjaGVzID8gRm9yIGluc3RhbmNlLCBjYW4gSSBn ZXQtcm91dGUgdG8gZmluZCB0aGUgDQpyb3V0ZSBmb3Igd2hpY2ggdGFnID0gNDIgPyAodGhlb3Jl dGljYWwgZXhhbXBsZSwgSSdtIG5vdCBzYXlpbmcgdGhlcmUncyANCmEgdXNlIGZvciB0aGlzKQ0K DQoNCg0KPj4gLSB3aHkgcmVzdHJpY3QgdGhlIGdldC1yb3V0ZSBSUEMgdG8gb25seSBxdWVyeSB0 aGUgc3BlY2lhbC9kZWZhdWx0DQo+PiAiRklCIiByb3V0aW5nIHRhYmxlID8gaXQgd291bGQgc2Vl bSB1c2VmdWwgdG8gYmUgYWJsZSB0byBxdWVyeSBhbnkNCj4+IHJvdXRpbmcgdGFibGUuDQo+DQo+ IFRoaXMgY291bGQgYmUgZG9uZSBidXQgaXQgd291bGQgYnJpbmcgbmV3IGlzc3VlcyB0byBjb25z aWRlciAtDQo+IG11bHRpcGxlIGNhbmRpZGF0ZSByb3V0ZXMgZXRjLiBUaGUgJ2dldC1yb3V0ZScg bWV0aG9kIGlzIHN1cHBvc2VkIHRvDQo+IGFuc3dlciB0aGUgc2ltcGxlIHF1ZXN0aW9uOiAiV2hp Y2ggcm91dGUgd2lsbCBiZSB1c2VkIGZvciBmb3J3YXJkaW5nDQo+IHBhY2tldHMgdG8gZGVzdGlu YXRpb24gVy5YLlkuWj8iDQoNClR3byB0aGluZ3M6DQoNCi0gdGhlcmUgaXMgYSBzdHJvbmcsIGFu ZCBwb3NzaWJseSBkZWJhdGFibGUsIGh5cG90aGVzaXMgaGVyZTogdGhhdCB0aGUgDQpvcGVyYXRv cnMgdGhhdCByZWxpZXMgb24gTmV0Y29uZi9ZYW5nIHdpbGwgdXNlIHRoaXMgbW9kdWxlIHdpdGgg YXMgdGhlIA0Kb25seSBuZWVkIHRoZSBuZWVkIHRvIGtub3cgYWJvdXQgZm9yd2FyZGluZy4NCg0K LSB0aGUgIm11bHRpcGxlIGNhbmRpZGF0ZSByb3V0ZSIgaXNzdWUgaXMsIEkgdGhpbmssIHNvbWV0 aGluZyB0aGF0IG5lZWRzIA0KdG8gYmUgdGFrZW4gY2FyZSBvZiwgZXZlbiBmb3IgdGhlIEZJQiA7 IGlmIG9ubHkgYXMgdG8gdGFrZSBjYXJlIG9mIEVDTVAsIA0KYnV0IGFsc28gZm9yIHVzZS1jYXNl cyBzdWNoIGFzIElQRlJSICh3aGVyZSBtdWx0aXBsZSBuZXh0LWhvcHMgYXJlIGluIA0KdGhlIEZJ QiBmb3IgYSBzYWlkIHByZWZpeCwgc29tZSBvZiB0aGVtIHdpbGwgYmVjb21lIGFjdGl2ZSBvbmx5 IHdoZW4gYSANCmNlcnRhaW4gZmFpbHVyZSBhcmlzZSkNCg0KDQoNCj4+IC0tLSBSZWRpc3RyaWJ1 dGluZyByb3V0ZXMgZGlyZWN0bHkgYmV0d2VlbiByb3V0aW5nIHByb3RvY29scw0KPj4NCj4+IFRo ZXNlIHNwZWNpZmljYXRpb25zIG9ubHkgYWxsb3cgdGhlIGV4Y2hhbmdlIG9mIHJvdXRlcyBmcm9t IGENCj4+IHJvdXRpbmcgcHJvdG9jb2wgb3Igcm91dGluZyB0YWJsZSB0byBhIHJvdXRpbmcgdGFi bGUsIGJ1dCBub3QgZnJvbQ0KPj4gYSByb3V0aW5nIHByb3RvY29sIHRvIGFub3RoZXIgcm91dGlu ZyBwcm90b2NvbHMuIEhvd2V2ZXIsIHRoZQ0KPj4gbGF0dGVyIGlzIHNvbWV0aGluZyB1c2VkIGEg bG90IGluIHByYWN0aWNlIChlLmcuIGNvbnRyb2xsaW5nDQo+PiByZWRpc3RyaWJ1dGlvbiBiZXR3 ZWVuIHR3byBJR1AgYXJlYXMpLiBPZiBjb3Vyc2UsIGJ5IHVzaW5nIGFuDQo+PiBpbnRlcm1lZGlh dGUgcm91dGluZyB0YWJsZSB5b3UgY291bGQgYWNoaWV2ZSB0aGUgc2FtZSByZXN1bHQsIGJ1dA0K Pj4gZG9lc24ndCBpdCBsb29rIGxpa2UgZXh0cmEgb3ZlcmhlYWQgPw0KPg0KPiBTb21lIGltcGxl bWVudGF0aW9ucyAoSU9TLCBmb3IgZXhhbXBsZSkgcmVkaXN0cmlidXRlIHJvdXRlcyBiZXR3ZWVu DQo+IHByb3RvY29scyB3aGlsZSBvdGhlcnMgKEpVTk9TLCBCSVJEKSB1c2UgYW4gaW50ZXJtZWRp YXRlIHJvdXRpbmcNCj4gdGFibGUuIEJ1dCBhcyB5b3Ugc2F5LCB0aGUgZm9ybWVyIGFwcHJvYWNo IG1heSBiZSBlbXVsYXRlZCB3aXRoIHRoZQ0KPiBsYXR0ZXIuIEluIHRoZSBtb3N0IHR5cGljYWwg Y2FzZSB3aGVuIHR3byBwcm90b2NvbHMgYXJlIGNvbm5lY3RlZCB0bw0KPiB0aGUgc2FtZSAoZS5n LiBtYWluKSByb3V0aW5nIHRhYmxlLCBlYWNoIHByb3RvY29sIGNhbiB1c2UgYSBmaWx0ZXIgdG8N Cj4gcHVsbCB0aGUgcm91dGVzIG9yaWdpbmF0aW5nIGZyb20gdGhlIG90aGVyIHByb3RvY29sLg0K DQoNCkl0cyBvZnRlbiBiZXR0ZXIgd2hlbiBzaW1wbGUgdGhpbmdzIGNvdWxkIGJlIGRvYWJsZSBp biBhIHNpbXBsZSB3YXkuDQoNCldoYXQgYXJlIHRoZSBkcmF3YmFja3Mgb2YgYWxsb3dpbmcgcm91 dGVzIHRvIGJlIGV4Y2hhbmdlZCBkaXJlY3RseSANCmJldHdlZW4gcm91dGluZyBwcm90b2NvbHMg Pw0KDQooc2FpZCBvdGhlcndpc2U6IG5vdCBhbGxvd2luZyBkaXJlY3QgaW1wb3J0L2V4cG9ydCBi ZXR3ZWVuIHJvdXRpbmcgDQpwcm90b2NvbHMgbG9va3MgbGlrZSBhbiBhcmJpdHJhcnkgcmVzdHJp Y3Rpb247IHdoYXQgaXMgdGhlIGRyaXZlciBmb3IgDQppbnRyb2R1Y2luZyB0aGlzIGFyYml0cmFy eSByZXN0cmljdGlvbiA/IGlzIHRoaXMgcmVzdHJpY3Rpb24gd29ydGggdGhlIA0Kb3BlcmF0aW9u YWwgY29zdCAobW9yZSB3b3JrIHRvIGRvIHRvIGRvIHByb3RvY29sLXRvLXByb3RvY29sIA0KcmVk aXN0cmlidXRpb24sIG1vcmUgcm91dGluZyB0YWJsZSB0byBpbnN0YW50aWF0ZSkgID8NCg0KDQo+ PiAtLS0gTW9kaWZ5IHJvdXRlcyBiZWluZyByZWRpc3RyaWJ1dGVkDQo+Pg0KPj4gVGhlcmUgZG9l cyBub3Qgc2VlbSB0byBiZSBhbnkgd2F5IHRocm91Z2ggd2hpY2ggYSByb3V0ZSBtYXkgYmUNCj4+ IG1vZGlmaWVkL2F1Z21lbnRlZCBieSBhIGZpbHRlciB3aGVuIGV4cG9ydGVkIGZyb20gYSByb3V0 aW5nIHRhYmxlDQo+PiBvciBwcm90b2NvbCB0byBhbm90aGVyLiBJdCBzZWVtcyB0byBtZSB0aGF0 IHRoaXMgaXMgc29tZXRoaW5nIHRoYXQNCj4+IGlzIHVzZWQgYSBsb3QgaW4gcHJhY3RpY2UuDQo+ DQo+IE9mIGNvdXJzZSwgdGhpcyBpcyBqdXN0IGFub3RoZXIgdGFzayBmb3IgdGhlIGZ1dHVyZSBy b3V0ZSBmaWx0ZXJpbmcNCj4gZnJhbWV3b3JrKHMpLg0KDQpPaywgdGhlbiB0aGUgdGV4dCBpbiBw YXJhZ3JhcGggwqcxIG9mIHNlY3Rpb24gNC41IGlzIGdvb2QgZW5vdWdoDQoNCiAgICAgUm91dGUg ZmlsdGVycyBtYXkgYWxzbyBtYW5pcHVsYXRlIHJvdXRlcywgaS5lLiwgYWRkLCBkZWxldGUsIG9y IG1vZGlmeQ0KICAgICB0aGVpciBwcm9wZXJ0aWVzLg0KDQoNCg0KPj4gLS0tICBBcHBsaWNhYmls aXR5IHRvIFJGQzQzNjQNCj4+DQo+PiBBbGxvd2luZyBtdWx0aXBsZSAicm91dGVycyIgaXMgYSBn b29kIHN0YXJ0aW5nIHBvaW50IGZvciB1c2luZw0KPj4gdGhlc2Ugc3BlY3MgaW4gdGhlIGNvbnRl eHQgb2YgUkZDNDM2NCAoTVBMUy9CR1AgSVAgVlBOcykuIEhvd2V2ZXIsDQo+PiBpZiBJIHVuZGVy c3RhbmQgY29ycmVjdGx5IFlhbmcgc3ludGF4LCB0aGUgd2F5IHRoZSBmaWx0ZXJzIGFyZQ0KPj4g ZGVmaW5lZCB3b3VsZCBub3Qgd29yayBpbiB0aGUgY29udGV4dCBvZiBSRkM0MzY0LCB3aGVyZSBh IEJHUA0KPj4gcm91dGluZyBpbnN0YW5jZSBpbiB0aGUgbWFzdGVyICJyb3V0ZXIiIGV4cG9ydHMg c2VsZWN0ZWQgcm91dGVzIGluDQo+PiBlYWNoIG9mIHRoZSByb3V0aW5nIHRhYmxlIG9mIGVhY2gg VlBOIChWUkYpLiAgVGhlIFZSRiBhbHNvIGV4cG9ydA0KPj4gcm91dGVzIHRvIHRoZSBtYXN0ZXIg aW5zdGFuY2UuDQo+DQo+IFRoZSBkcmFmdCBzYXlzOiAiQWx0aG91Z2ggaXQgaXQgbm90IGVuZm9y Y2VkIGJ5IHRoZSBkYXRhIG1vZGVsLA0KPiBkaWZmZXJlbnQgcm91dGVyIGluc3RhbmNlcyBub3Jt YWxseSBkbyBub3QgaW50ZXJuYWxseSBzaGFyZSBhbnkNCj4gZGF0YS4iIFNvIHRoaXMgbWF5IGJl IGEgdXNlIGNhc2UgZm9yIHNoYXJpbmcgZGF0YSBhbW9uZyBkaWZmZXJlbnQNCj4gcm91dGVyIGlu c3RhbmNlcy4gVGhlcmUgaXMgbm90aGluZyBpbiB0aGUgZGF0YSBtb2RlbCAob3IgWUFORykNCj4g cHJldmVudGluZyB0aGlzLiBJIHdpbGwgYWxzbyByZWxheCB0aGUgY2l0ZWQgc2VudGVuY2UsIGlu IHRoZQ0KPiBmb2xsb3dpbmcgc2Vuc2U6ICJJbXBsZW1lbnRhdGlvbnMgbWF5IHNwZWNpZnkgdGhl IHJ1bGVzIGZvciBzaGFyaW5nDQo+IGRhdGEgYW1vbmcgcm91dGVyIGluc3RhbmNlcy4iDQoNClRo aXMgaXMgZ29vZCwgYnV0IG5vdCBlbm91Z2ggKHNlZSBiZWxvdykuDQoNCj4+IFRoZSB0d28gb2Jz dGFjbGVzIEkgd291bGQgc2VlIChJIG1pZ2h0IGJlIHdyb25nKSBhcmUgdGhlDQo+PiBmb2xsb3dp bmc6IC0gbm8gd2F5IHRvIG1vZGlmeSByb3V0ZXMgd2hpbGUgdGhleSBhcmUNCj4+IGltcG9ydGVk L2V4cG9ydGVkIDogdGhlIFJGQzQzNjQgdXNlLWNhc2Ugd291bGQgcmVxdWlyZSB0aGUgYWJpbGl0 eQ0KPj4gdG8gKGF0IGxlYXN0KSBhZGQvc3RyaXAgYXR0cmlidXRlcyB0by9mcm9tIHRoZSByb3V0 ZXMNCj4NCj4gRWFjaCBpbXBvcnQvZXhwb3J0IGlzIHN1YmplY3QgdG8gYSByb3V0ZSBmaWx0ZXIs IHdoaWNoIHNob3VsZCBiZSBhYmxlDQo+IHRvIHBlcmZvcm0gc3VjaCBtYW5pcHVsYXRpb25zLg0K DQpPay4NCg0KPj4gLSBubyB3YXkgdG8gcmVkaXN0cmlidXRlIHJvdXRlcyBiZXR3ZWVuIHJvdXRp bmcgdGFibGVzIG9mIGRpZmZlcmVudA0KPj4gInJvdXRlcnMiICh3aGF0IGxldCBtZSB0aGluayB0 aGlzIGNvbnN0cmFpbnQgZXhpc3RzIGlzIChhKSB0aGUNCj4+IGluYWJpbGl0eSB0byBuYW1lIGEg cm91dGVyIHdoZW4gZGVzaWduYXRpbmcgYSByb3V0aW5nLXRhYmxlIHRvDQo+PiBpbXBvcnQvZXhw b3J0IGZyb20vdG8sIGFuZCAoYikgdGhlIFhQYXRocyBmb3INCj4+IGNvbm5lY3RlZC1yb3V0aW5n LXRhYmxlcy9yb3V0aW5nLXRhYmxlL25hbWUgYW5kDQo+PiByZWNpcGllbnQtcm91dGluZy10YWJs ZXMgcmVjaXBpZW50LW5hbWUsIHdoaWNoIHNlZW1zIHRvIG5vdCBiZSBhYmxlDQo+PiB0byBwb2lu dCBoaWdoZXIgaW4gdGhlIGhpZXJhcmNoeSB0aGFuIHRoZSAncm91dGVyJyBvbiB3aGljaCB0aGV5 DQo+PiBhcmUgZGVmaW5lZCApDQo+DQo+IFRydWUsIHRoZSBjb25uZWN0ZWQgcm91dGluZyB0YWJs ZSBjdXJyZW50bHkgbXVzdCBiZSB3aXRoaW4gdGhlIHNhbWUNCj4gcm91dGVyIGluc3RhbmNlLiBT byB0aGlzIGNvbnN0cmFpbnQgc2hvdWxkIGJlIHJlbW92ZWQsIGFuZA0KPiBpbXBsZW1lbnRhdGlv bnMgdGhhdCBuZWVkIHN1Y2ggYW4gaXNvbGF0aW9uIHdpbGwgaGF2ZSB0byBzdGF0ZSBpdA0KPiBl eHBsaWNpdGx5Lg0KDQpBZ3JlZWQuDQoNCg0KPj4gLSB0aGUgY29uc3RyYWludCB0aGF0IGZvciBh IHNhaWQgcm91dGluZyBwcm90b2NvbHMgIkZvciBlYWNoDQo+PiBBRk4vU0FGSSBwYWlyIHRoZXJl IG1heSBiZSBhdCBtb3N0IG9uZSBjb25uZWN0ZWQgcm91dGluZyB0YWJsZS4iIC4NCj4+IEluIHRo ZSBSRkM0MzY0IGNhc2UsIHRoZSBnbG9iYWwgQkdQIHJvdXRpbmcgcHJvY2VzcyB3b3VsZCBwdXNo DQo+PiByb3V0ZXMgdG8gbXVsdGlwbGUgVlJGcy4NCj4NCj4gVGhpcyBpcyBtb3N0IGxpa2VseSBu b3QgYSBwcm9ibGVtIGJlY2F1c2UgYW55IG51bWJlciBvZiByZWNpcGllbnQNCj4gcm91dGluZyB0 YWJsZXMgY2FuIGJlIGNvbmZpZ3VyZWQgdG8gcmVjZWl2ZSAoZmlsdGVyZWQpIHJvdXRlcyBmcm9t DQo+IHRoZSBzaW5nbGUgcm91dGluZyB0YWJsZSB3aGljaCBpcyBjb25uZWN0ZWQgdG8gYSByb3V0 aW5nIHByb3RvY29sLA0KPiBjZi4gdGhlICJyZWNpcGllbnQtcm91dGluZy10YWJsZXMiIGxpc3Qu DQoNClVuZGVyc3Rvb2QsIHRoZXJlIGlzIGEgd2F5IHRvIG1ha2UgaXQgd29yaywgYnV0IHNlZSBk aXNjdXNzIGFib3ZlLCBpdCANCnNlZW1zIHRvIG1lIGFzIHBvc3NpYmx5IHVzZWxlc3Mgb3Zlcmhl YWQgdG8gYWx3YXkgbmVlZCBhbiBpbnRlcm1lZGlhdGUgDQpyb3V0aW5nIHRhYmxlIGluIHN1Y2gg Y2FzZXMuDQoNCg0KDQo+Pg0KPj4gLS0tIEVuYWJsaW5nL2Rpc2FibGluZyBhbiBpbnRlcmZhY2UN Cj4+DQo+PiBTb21ldGhpbmcgZG9uZSB2ZXJ5IG9mdGVuIG9uIGEgcm91dGVyIGNvbnNpc3RzIGlu IHB1dHRpbmcgYW4NCj4+IGludGVyZmFjZSAic2h1dGRvd24iIG9yICJpbmFjdGl2ZSIsIHByZXNl cnZpbmcgaXRzIGNvbmZpZ3VyYXRpb24NCj4+IGJ1dCBtYWtpbmcgaXQgaWdub3JlZCBieSB0aGUg cm91dGVyIGFuZCBrZWVwaW5nIHRoZSBsaW5rIGRvd24uDQo+PiBUaGVzZSBzcGVjaWZpY2F0aW9u cyBkb24ndCBzZWVtIHRvIHByb3ZpZGUgdGhpcy4gIElzIHRoaXMgc29tZXRoaW5nDQo+PiBhbHJl YWR5LCBvciBleHBlY3RlZCB0byBiZSwgcHJvdmlkZWQgYnkgYW5vdGhlciBZYW5nIGV4dGVuc2lv biA/DQo+DQo+IFRoZSAiaWV0Zi1pbnRlcmZhY2VzIiBtb2R1bGUgaGFzIHRoaXMgImVuYWJsZWQi IHN3aXRjaCwgdGhhdCB3aWxsDQo+IHNlcnZlciB0aGlzIHB1cnBvc2UuIFdlIGFyZSBhbHNvIGRp c2N1c3Npbmcgd2hlcmUgdG8gcHV0IHRoZQ0KPiAiaXMtcm91dGVyIiB0b2dnbGUgdGhhdCBlbmFi bGVzL2Rpc2FibGVzIGZvcndhcmRpbmcgb24gYW4gaW50ZXJmYWNlLg0KPg0KDQpPay4NCg0KDQo+ Pg0KPj4gSWYgc28sIGhvdyB3b3VsZCB0aGUgdHdvIGludGVyYWN0LCBpZiBmb3IgaW5zdGFuY2Us IGFuIGludGVyZmFjZSBpcw0KPj4gc2h1dGRvd24gaW4gdGhpcyBvdGhlciBtb2R1bGUgYnV0IHVz ZWQgaW4gdGhlIHJvdXRpbmcgbW9kdWxlID8NCj4NCj4gR29vZCBwb2ludCwgdGhpcyBoYXMgdG8g YmUgc3BlY2lmaWVkIGluIHRoZSBkcmFmdC4NCj4NCg0KT2ssIHdlIGFncmVlLg0KDQoNCj4+DQo+ PiAtLS0gRW5hYmxpbmcvRGlzYWJsaW5nIGEgcHJvdG9jb2wgb24gYW4gaW50ZXJmYWNlLCBvciBt b2RpZnlpbmcNCj4+IHByb3RvY29sIHBlci1pbnRlcmZhY2UgcGFyYW1ldGVycw0KPj4NCj4+IFNv bWV0aGluZyBkb25lIHZlcnkgb2Z0ZW4gb24gYSByb3V0ZXIgY29uc2lzdHMgaW4NCj4+IGVuYWJs aW5nL2Rpc2FibGluZyBhIHNhaWQgcHJvdG9jb2wgb24gYSBzYWlkIGludGVyZmFjZSwgb3IgbW9y ZQ0KPj4gZ2VuZXJhbGx5IG1vZGlmeWluZyBwYXJhbWV0ZXJzIGZvciBhIHNhaWQgcHJvdG9jb2wg b24gYSBzYWlkDQo+PiBpbnRlcmZhY2UgKHR5cGljYWwgZXhhbXBsZSBiZWluZyB0aGUgbWV0cmlj KS4gIEFzIEkgdW5kZXJzdGFuZCB0aGlzDQo+PiB3b3VsZCBiZSBhbGxvd2VkIGJ5IHRoZXNlIHNw ZWNzIGJ5IGhhdmluZyBhIG1vZHVsZSBleHRlbmRpbmcNCj4+IHByb3RvY29sIFggYXVnbWVudCBy b3V0aW5nL3JvdXRlci9pbnRlcmZhY2Ugd2l0aCBpdHMgb3duDQo+PiBwYXJhbWV0ZXJzLiAgSG93 ZXZlciwgSSdtIHdvbmRlcmluZyBpZiB0aGVzZSBwZXItcHJvdG9jb2wNCj4+IHBlci1pbnRlcmZh Y2UgcGFyYW1ldGVycyB3b3VsZG4ndCBiZSBiZXR0ZXIgcGxhY2VkIHVuZGVyIGVhY2gNCj4+IHJv dXRpbmcvcm91dGVyL3JvdXRpbmctcHJvdG9jb2xbWF0uDQo+DQo+IEl0IGlzIHVwIHRvIHRoZSBk ZXNpZ25lciBvZiB0aGUgcHJvdG9jb2wgZGF0YSBtb2RlbCwgYm90aCBvcHRpb25zIGFyZQ0KPiBw b3NzaWJsZS4gTWF5YmUgd2Ugc2hvdWxkIGdpdmUgc29tZSBndWlkZWxpbmVzLg0KPg0KPj4gVGhl IHJlYXNvbnMgSSBzZWUgYXJlIHRoZSBmb2xsb3dpbmc6ICogaW4gc29tZSBjYXNlcyBhIHNhaWQg cm91dGVyDQo+PiBtYXkgcnVuIG11bHRpcGxlIGluc3RhbmNlcyBvZiBhIHNhaWQgcHJvdG9jb2wg dHlwZSwgaW4gcGFyYWxsZWwsDQo+PiBhbmQgeW91IG1heSBuZWVkIHRvIGhhdmUgYSB3YXkgdG8g ZGlmZmVyZW50aWF0ZSBlbmFibGluZyBpbnN0YW5jZSBBDQo+PiBvZiBwcm90b2NvbCBYIGZyb20g aW5zdGFuY2UgQiBvZiBwcm90b2NvbCBYICogeW91IGNvdWxkIGV2ZW4gZmluZA0KPj4gdXNlIGNh c2VzIHdoZXJlIGEgbXVsdGlwbGUgaW5zdGFuY2VzIG9mIGEgc2FpZCBwcm90b2NvbCB0eXBlIHJ1 biBpbg0KPj4gcGFyYWxsZWwgb24gYSBzYWlkIGludGVyZmFjZSAoZWcuIG11bHRpIGluc3RhbmNl IElTSVMpICogbXkNCj4+IHVuZGVyc3RhbmRpbmcgb2YgdGhlIFlhbmcgbW9kdWxlIGlzIHRoYXQg dGhlIGN1cnJlbnQgc3RydWN0dXJlDQo+PiB3b3VsZCBub3QgYWxsb3cgYXVnbWVudGluZyBhIHNh aWQgaW50ZXJmYWNlIG11bHRpcGxlIHRpbWVzIGZvciBhDQo+PiBzYW1lIHBhcmFtZXRlciBvZiBh IHNhaWQgcHJvdG9jb2wgdHlwZS4NCj4NCj4gSWYgc29tZXRoaW5nIGxpa2UgdGhpcyBpcyBuZWNl c3NhcnksIG9uZSBjYW4gYXVnbWVudCBhbiBpbnRlcmZhY2UNCj4gY29uZmlndXJhdGlvbiB3aXRo IGEgbGlzdCB3aGVyZSBlYWNoIGVudHJ5IGNvcnJlc3BvbmRzIHRvIG9uZQ0KPiBpbnN0YW5jZSBv ZiB0aGUgcm91dGluZyBwcm90b2NvbC4NCg0KSGVyZSwgYWdhaW4sIHRoYXQgd291bGQgd29yaywg YnV0IGl0IGRvZXNuJ3QgbG9vayB0byBtZSBhcyB0aGUgc2ltcGxlc3QgDQphcHByb2FjaC4NCg0K VGhhbmtzLA0KDQotVGhvbWFzDQoNCg0K From lhotka@cesnet.cz Tue Apr 10 04:10:54 2012 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3D2D21F87DA; Tue, 10 Apr 2012 04:10:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6] 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 138c-FFPVQtp; Tue, 10 Apr 2012 04:10:49 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 69B6A21F87CC; Tue, 10 Apr 2012 04:10:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 7365E540DE3; Tue, 10 Apr 2012 13:10:47 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S4TryRw5neEf; Tue, 10 Apr 2012 13:10:35 +0200 (CEST) Received: from localhost (unknown [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 5E1405400FB; Tue, 10 Apr 2012 13:10:35 +0200 (CEST) From: Ladislav Lhotka To: thomas.morin@orange.com, rtg-ads@tools.ietf.org, rtg-dir@ietf.org, draft-ietf-netmod-routing-cfg.all@tools.ietf.org, netmod@ietf.org In-Reply-To: References: User-Agent: Notmuch/0.11+128~g6f388fa (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: thomas.morin@orange.com, rtg-ads@tools.ietf.org, rtg-dir@ietf.org, draft-ietf-netmod-routing-cfg.all@tools.ietf.org, netmod@ietf.org Date: Tue, 10 Apr 2012 13:10:34 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 13 Apr 2012 10:39:28 -0700 Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-netmod-routing-cfg X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 11:10:55 -0000 On Tue, 3 Apr 2012 16:57:29 +0200, wrote: ... > >> > >> --- Information on routes > >> > >> The Yang module let's the operator read the routing tables. It > >> looks like a very valid and useful thing (and not new, see RFC1213 > >> MIB). > >> > >> However, I'm wondering about the following points: > >> > >> - usually, a routing table may have multiple routes for a said > >> destination address, some being possibly less specific than others, > >> or inactive due to various reasons : it did not identify how these > >> specification allow the operator to see all routes of a routing > >> table for a said prefix, or all the most specific routes including > >> the inactive ones, or all the most specific actives routes when > >> there is more than one (required I think for ECMP support), etc. ? > >> it seems it would be worth to extend the get-route RPC to allow > >> expressing all these kind of questions > > > > The 'get-route' method doesn't try to be terribly general or > > extensible, it is mainly intended as a reminder to routing experts > > that YANG also allows for defining new RPC methods. I think it will > > be easier to decide what methods are needed as soon as there are data > > models for the major routing protocols, such as OSPF or BGP. >=20 > You might want to find a balance between doing things in these=20 > specifications and punting to future work and new extensions. Actually, there is also the generic "get" operation in NETCONF which allows= for querying state data and specifying various filters. This might be suff= icient for getting information from routing tables. On the other hand, we had a discussion with Martin Bj=C3=B6rklund in Paris = whether it is reasonable to expose routing tables as state data. The downsi= de is that if a client issues (perhaps inadvertently) a "get" without any f= ilters, the reply may contain the full BGP table and be therefore darn long= . I am not sure which alternative is better but if we decide not to expose = routing tables as state data, it will indeed be necessary to replicate the = functionality of "get" (including filters) for obtaining routes. =20=20=20 >=20 > It seems to me that, at the very least, the get-rpc should allow to=20 > return more than one route (all active ones) so as to be compatible with Yes, this is a good point. =20 > ECMP. Filtering between active and inactive routes would be I think=20 > fairly generic and relevant to add in these specs. Hmm, but the decision is based on parameters that are not defined in the ro= uting module - metrics, preferences etc. How can we specify the algorithm w= ithout knowing these? Also, in Paris I got another comment related to this, namely that some impl= ementations don't use a special forwarding table. It's true that e.g. Linux= selects the active route form a routing table on the fly (and uses a route= cache). So I am now considering the option of removing the forwarding tabl= e (FIB) from the spec. In that case the "get-route" would be an implementat= ion-independent way of learning the active route(s). ... >=20 >=20 > >> - (related to the previous point:) : I'm unclear if these specs > >> allow a get-route to match on different portions or attributes of a > >> routes (eg. get route for prefix X advertised by peer X, or having > >> been readvertised by AS Y...)... As I understand, there can be some > >> AFN/SAFI specific extensions, but no per-protocol extensions. Is > >> this a correct understanding ? If not, wouldn't it make sense to > >> make it more extensible ? > > > > There can be per-protocol extensions, too, it is also demonstrated in > > the RIP example. >=20 >=20 > I understand how the RIP example does extend the information *returned*=20 > by get-route. But I don't get how a protocol can extend the information=20 > on which get-rpc matches ? For instance, can I get-route to find the=20 > route for which tag =3D 42 ? (theoretical example, I'm not saying there's= =20 > a use for this) >=20 The "get-route" does not provide this possibility but it can be done using = the generic "get" operation with subtree filters. >=20 >=20 > >> - why restrict the get-route RPC to only query the special/default > >> "FIB" routing table ? it would seem useful to be able to query any > >> routing table. > > > > This could be done but it would bring new issues to consider - > > multiple candidate routes etc. The 'get-route' method is supposed to > > answer the simple question: "Which route will be used for forwarding > > packets to destination W.X.Y.Z?" >=20 > Two things: >=20 > - there is a strong, and possibly debatable, hypothesis here: that the=20 > operators that relies on Netconf/Yang will use this module with as the=20 > only need the need to know about forwarding. I am not sure I understand this point but I definitely assume that other (p= rotocol-specific) means for querying the routing system will be defined in = other modules. >=20 > - the "multiple candidate route" issue is, I think, something that needs= =20 > to be taken care of, even for the FIB ; if only as to take care of ECMP,= =20 > but also for use-cases such as IPFRR (where multiple next-hops are in=20 > the FIB for a said prefix, some of them will become active only when a=20 > certain failure arise) Yes, I agree. >=20 >=20 >=20 > >> --- Redistributing routes directly between routing protocols > >> > >> These specifications only allow the exchange of routes from a > >> routing protocol or routing table to a routing table, but not from > >> a routing protocol to another routing protocols. However, the > >> latter is something used a lot in practice (e.g. controlling > >> redistribution between two IGP areas). Of course, by using an > >> intermediate routing table you could achieve the same result, but > >> doesn't it look like extra overhead ? > > > > Some implementations (IOS, for example) redistribute routes between > > protocols while others (JUNOS, BIRD) use an intermediate routing > > table. But as you say, the former approach may be emulated with the > > latter. In the most typical case when two protocols are connected to > > the same (e.g. main) routing table, each protocol can use a filter to > > pull the routes originating from the other protocol. >=20 >=20 > Its often better when simple things could be doable in a simple way. >=20 > What are the drawbacks of allowing routes to be exchanged directly=20 > between routing protocols ? >=20 > (said otherwise: not allowing direct import/export between routing=20 > protocols looks like an arbitrary restriction; what is the driver for=20 > introducing this arbitrary restriction ? is this restriction worth the=20 > operational cost (more work to do to do protocol-to-protocol=20 > redistribution, more routing table to instantiate) ? Two reasons: 1. Allowing the exchanges between both routing tables and protocols would m= ake the system even=20 more complicated. 2. Routing protocols will mostly be defined elsewhere, so it seems to me it= is better to keep=20 their interface to the protocol-independent part as simple as possible. And it needn't really be any more complicated: an implementation may decide= to reserve a routing table exclusively for each routing instance and in th= is case there will be effectively no difference between the two cases. Yes,= there is some overhead, but some implementations use this approach (a sing= le routing table connected to each protocol instance) and I see no way how = this can be emulated if the only option was to exchange routes between prot= ocols.=20=20 Client sofware can certainly let the user pretend the exchange happens betw= een routing protocols. ... =20 > >> - the constraint that for a said routing protocols "For each > >> AFN/SAFI pair there may be at most one connected routing table." . > >> In the RFC4364 case, the global BGP routing process would push > >> routes to multiple VRFs. > > > > This is most likely not a problem because any number of recipient > > routing tables can be configured to receive (filtered) routes from > > the single routing table which is connected to a routing protocol, > > cf. the "recipient-routing-tables" list. >=20 > Understood, there is a way to make it work, but see discuss above, it=20 > seems to me as possibly useless overhead to alway need an intermediate=20 > routing table in such cases. I don't think it's a viable approach to provide all existing alternatives d= irectly in the same data model (I am old enough to remember the original PL= /1 programming language). The important point is that it is doable. Thanks, Lada --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Tue Apr 10 04:19:58 2012 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C72B021F861A; Tue, 10 Apr 2012 04:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.105 X-Spam-Level: X-Spam-Status: No, score=-103.105 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-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 0KTs-HIZ-2kI; Tue, 10 Apr 2012 04:19:58 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id A8F0D21F8610; Tue, 10 Apr 2012 04:19:57 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id F1EC620C21; Tue, 10 Apr 2012 13:19:56 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ucymrjOhjFBL; Tue, 10 Apr 2012 13:19:56 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8A3EA20C20; Tue, 10 Apr 2012 13:19:56 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B7D5A1E5C163; Tue, 10 Apr 2012 13:19:56 +0200 (CEST) Date: Tue, 10 Apr 2012 13:19:56 +0200 From: Juergen Schoenwaelder To: thomas.morin@orange.com, rtg-ads@tools.ietf.org, rtg-dir@ietf.org, draft-ietf-netmod-routing-cfg.all@tools.ietf.org, netmod@ietf.org Message-ID: <20120410111956.GA24800@elstar.local> Mail-Followup-To: thomas.morin@orange.com, rtg-ads@tools.ietf.org, rtg-dir@ietf.org, draft-ietf-netmod-routing-cfg.all@tools.ietf.org, netmod@ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Fri, 13 Apr 2012 10:39:28 -0700 Subject: Re: [RTG-DIR] [netmod] RtgDir review: draft-ietf-netmod-routing-cfg X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 11:19:58 -0000 On Tue, Apr 10, 2012 at 01:10:34PM +0200, Ladislav Lhotka wrote: > On Tue, 3 Apr 2012 16:57:29 +0200, wrote: > > ... > > > >> > > >> --- Information on routes > > >> > > >> The Yang module let's the operator read the routing tables. It > > >> looks like a very valid and useful thing (and not new, see RFC1213 > > >> MIB). > > >> > > >> However, I'm wondering about the following points: > > >> > > >> - usually, a routing table may have multiple routes for a said > > >> destination address, some being possibly less specific than others, > > >> or inactive due to various reasons : it did not identify how these > > >> specification allow the operator to see all routes of a routing > > >> table for a said prefix, or all the most specific routes including > > >> the inactive ones, or all the most specific actives routes when > > >> there is more than one (required I think for ECMP support), etc. ? > > >> it seems it would be worth to extend the get-route RPC to allow > > >> expressing all these kind of questions > > > > > > The 'get-route' method doesn't try to be terribly general or > > > extensible, it is mainly intended as a reminder to routing experts > > > that YANG also allows for defining new RPC methods. I think it will > > > be easier to decide what methods are needed as soon as there are data > > > models for the major routing protocols, such as OSPF or BGP. > > > > You might want to find a balance between doing things in these > > specifications and punting to future work and new extensions. > > Actually, there is also the generic "get" operation in NETCONF which allows for querying state data and specifying various filters. This might be sufficient for getting information from routing tables. > > On the other hand, we had a discussion with Martin Björklund in Paris whether it is reasonable to expose routing tables as state data. The downside is that if a client issues (perhaps inadvertently) a "get" without any filters, the reply may contain the full BGP table and be therefore darn long. I am not sure which alternative is better but if we decide not to expose routing tables as state data, it will indeed be necessary to replicate the functionality of "get" (including filters) for obtaining routes. If NETCONF's is considered unusable in practice since it can return huge amounts of data if not used carefully, then IMHO needs to be fixed or deprecated. I think it is backwards to not model operational state because an unfiltered operation may not be a good idea. That said, how to best model operational state seems to remain a somewhat unresolved issue. /js (as contributor) -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From gih@apnic.net Mon Apr 30 14:00:45 2012 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EFB821F877F for ; Mon, 30 Apr 2012 14:00:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.605 X-Spam-Level: X-Spam-Status: No, score=-101.605 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RELAY_IS_203=0.994, 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 5EkZoKd2ASfA for ; Mon, 30 Apr 2012 14:00:44 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id E34F721F877A for ; Mon, 30 Apr 2012 14:00:42 -0700 (PDT) Received: from dhcp140.potaroo.net (eth143.act.adsl.internode.on.net [203.16.208.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 0DC31B6854; Tue, 1 May 2012 07:00:40 +1000 (EST) From: Geoff Huston Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 1 May 2012 07:00:37 +1000 Message-Id: <6EDB6C6A-A8C5-45EE-9FD3-D92D2AD9282D@apnic.net> To: rtg-ads@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Cc: rtg-dir@ietf.org, draft-ietf-mboned-mcaddrdoc.all@tools.ietf.org Subject: [RTG-DIR] RtgDir review: draft-ietf-mboned-mcaddrdoc-03.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 21:00:45 -0000 Hello, I have been selected as the Routing Directorate reviewer for this draft. = The Routing Directorate seeks to review all routing or routing-related = drafts as they pass through IETF last call and IESG review, and = sometimes on special request. The purpose of the review is to provide = assistance to the Routing ADs. For more information about the Routing = Directorate, please see = http://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it = would be helpful if you could consider them along with any other IETF = Last Call comments that you receive, and strive to resolve them through = discussion or by updating the draft. Document: draft-ietf-mboned-mcaddrdoc-03.txt=20 Reviewer: Geoff Huston Review Date: 2 May 2012=20 IETF LC End Date: not known=20 Intended Status: Informational Summary: I have some minor concerns about this document that I think should be = resolved before publication. Comments: The draft is clear and readily understandably - quality is good and = no changes are suggested here. Major Issues:=20 No major issues found. Minor Issues: 1. Section 2, First paragraph reads: "For Any-Source Multicast (ASM), the IPv4 multicast addresses allocated for documentation purposes are 233.252.0.0 - 233.252.0.255 (233.252.0.0/24)." But the IANA Multicast registry = (http://www.iana.org/assignments/multicast-addresses/multicast-addresses.x= ml) says: AD-HOC Block III (233.252.0.0-233.255.255.255 (233.252/14)) 233.252.0.0-233.252.0.255 MCAST-TEST-NET [IANA] 2010-01-20 = 2010-01-20 =20 i.e. the IANA registry does NOT say that this address block has been = allocated for documentation. Indeed, it appears (by virtue of its name = MCAST-TEST-NET) to be already assigned for test purposes. In IPv4 and IPv6 unicast we have deliberately split documentation and = test addresses. It would be useful to either understand why this split = is not appropriate here, or why this draft does not request a block for = IPv4 ASM in the say way that it is already requesting a block for IPv6. = This reviewer is of the personal view that a separate assignment would = be appropriate here, in a comparable fashion to that being proposed for = IPv6 ASM. 2. IANA Considerations Obviously the reviewr is anticipating that the 2 TBD IANA assignments = will be nade prior to publication. =20 Nits: none found (but this reviewer is the first to admit that he is not a = good proof reader!) -- Geoff Huston